Desarrollador·a Backend

EspañaIntermedio

Preguntas frecuentes sobre la contratación para el puesto de Desarrollador·a Backend, y los errores que más la hacen fracasar.

Errores comunes al contratar para este puesto

  1. Confundir Backend y Full-stack en el brief inicial

    Un·a Backend y un·a Full-stack no cubren la misma necesidad. La persona Backend pasa entre el 80 y el 100 por ciento del tiempo en API, base de datos, jobs asíncronos y observabilidad. Si busca alguien que también entregue UI, contratar un perfil Backend produce frustración o features de frontend mal acabadas. Si su necesidad real es un·a Full-stack con orientación backend, dígalo de forma explícita en la oferta; no maquille un puesto Full-stack como Backend para atraer perfiles especialistas (los perderá a los 6 meses).

  2. Sobrevalorar los fundamentos algorítmicos para un puesto de producto

    Un·a Backend en pyme casi nunca necesita reimplementar un árbol B o resolver un problema de grafo ponderado. Las pruebas tipo LeetCode filtran a los perfiles académicos en detrimento de los operativos que sí saben mantener un servicio en producción. Prefiera ejercicios que se parezcan al día a día: añadir un endpoint con restricción de concurrencia, refactorizar una consulta N+1, depurar una race condition, diseñar una cola de mensajes.

  3. Saltarse el ejercicio de diseño de sistema para ahorrar tiempo

    Para un puesto backend mid-level, el diseño de sistema es la etapa más predictiva del rendimiento futuro. Una pyme que se salta esta etapa para ganar una semana en el plazo de contratación suele incorporar a alguien que programa limpio pero que no sabe anticipar las trampas distribuidas (consistencia, idempotencia, observabilidad, degradación elegante) y acumulará deuda operativa durante 18 meses. El coste de una mala contratación backend es muy superior a 60 minutos de diseño de sistema en entrevista.

  4. Ignorar la fit con la stack y el ecosistema

    Un·a Backend sólido·a en Node o Python no se vuelve productivo·a de inmediato en Go o Java sin 4-8 semanas de adaptación, y viceversa. La fit de stack pesa mucho más que la seniority absoluta para un·a mid-level. Indique con precisión su stack en la oferta (lenguaje, framework, base de datos, infraestructura, observabilidad); filtrará de forma natural los perfiles mal encajados. Si su stack es rara (Elixir, Rust, Clojure), asuma la escasez del vivero y cace de forma activa; no cuente con las ofertas pasivas solas.

  5. Subestimar el coste de la guardia y el on-call

    Un·a Backend en pyme participa de forma casi sistemática en la guardia u on-call. Una rotación mal encuadrada (frecuencia demasiado alta, alertas ruidosas, ausencia de runbooks, sin compensación) provoca burnout en 6-12 meses y rotación. Anuncie con claridad su esquema de guardias en la oferta, su ritmo, su compensación (económica o en descansos) y el estado real de su observabilidad. Las personas candidatas con experiencia preguntan por este tema en entrevista; prepárese para responder con honestidad.

Preguntas frecuentes

¿Cuál es el salario de un·a Desarrollador·a Backend en una pyme española?
La horquilla de referencia para un·a Desarrollador·a Backend de nivel intermedio (3 a 7 años de experiencia) en pyme española se sitúa entre 40 y 62 mil euros brutos anuales (mediana en torno a 50 mil). Madrid y Barcelona en entorno SaaS B2B, fintech o scale-up tiran hacia arriba (58-78 mil), sobre todo en stacks Go, Java o Kotlin con componente distribuida. El resto del territorio y los sectores tradicionales tiran hacia abajo. Los perfiles con expertise demostrable en observabilidad, rendimiento o seguridad aplicativa suman habitualmente entre 5 y 8 mil euros sobre la mediana. Este puesto no suele tener variable estructural en pyme; algunas scale-ups ofrecen phantom shares o stock options como complemento.
¿Cuál es la diferencia entre Backend, Full-stack y DevOps o SRE?
La persona Backend diseña y mantiene la API, la base de datos, los jobs asíncronos y la observabilidad aplicativa; vive en el código aplicativo. La persona Full-stack cubre backend y frontend a un nivel intermedio-avanzado; en pyme joven suele ser el perfil por defecto. La persona DevOps o SRE posee la infraestructura (Kubernetes, CI/CD, monitoring de infra, fiabilidad); vive en el código de infraestructura y en los pipelines. Una persona Backend puede tocar la infraestructura pero no la posee. Para una pyme de menos de 10 desarrolladores·as, el arbitraje típico: 1 o 2 Full-stack antes del primer·a Backend especialista, que llega cuando la complejidad del producto o la volumetría lo justifican.
¿Cuánto tiempo lleva contratar a un·a Desarrollador·a Backend en España?
Cuente con 45 a 75 días entre la publicación de la oferta y la firma para un perfil mid-level. El mercado backend español sigue tenso en 2025-2026, sobre todo en stacks modernas con componente distribuida (Go, Kotlin, Rust, Elixir). Los plazos se alargan en agosto y en torno a las navidades. Reducir el plazo por debajo de los 45 días suele implicar sacrificar la etapa de diseño de sistema o las referencias, lo que degrada considerablemente la calidad de la contratación para este puesto.
¿Qué stack técnica pedir para un puesto Backend en 2026?
Depende de su stack existente; no imponga una stack que no usa. Para una pyme que arranca, las opciones más seguras son: Python (Django o FastAPI) o Node (NestJS) sobre PostgreSQL para la productividad, Go para el rendimiento y la simplicidad operativa, Java o Kotlin si tiene contexto enterprise. Evite mezclar demasiados lenguajes backend en un equipo pequeño (coste de contexto). Pida sobre todo fundamentos sólidos (transacciones, concurrencia, observabilidad) por encima de la moda del momento; esos fundamentos resisten a los cambios de stack.
¿Es necesaria una titulación específica para contratar a un·a Desarrollador·a Backend?
No. El mercado tech español acepta ampliamente perfiles autodidactas o procedentes de bootcamps (Ironhack, Le Wagon Madrid, 4Geeks, Adalab) cuando suman 3-5 años de producción sólida sobre un servicio backend. La titulación (ingeniería informática, máster) tranquiliza en perfiles junior pero pierde peso a partir de los 5 años de experiencia. Evalúe sobre el código, el diseño de sistema y la calidad del diagnóstico de incidentes, no sobre el pedigrí académico.
¿Hay que hacer prueba técnica siempre?
Sí, pero corta (2-3 horas máximo) y realista. Una prueba técnica bien diseñada sigue siendo el mejor predictor del desempeño futuro, por delante de la titulación y del pedigrí, siempre que se combine con una etapa de diseño de sistema separada. Evite las pruebas algorítmicas académicas sin relación con el día a día (LeetCode hard); prefiera ejercicios parecidos al oficio: añadir un endpoint con restricción de concurrencia, refactorizar una consulta N+1, depurar una race condition simulada. Acote el tiempo esperado de forma explícita y acepte soluciones incompletas pero bien argumentadas.
Actualizado
Cubra este puesto con JoinSourcing, filtrado y entrevistas en un solo lugar.
Contratar

Hablar con Join