Desarrollador·a Backend
Descripción de puesto, salario, sourcing, 15 preguntas de entrevista y plan 30/60/90 para contratar un·a Desarrollador·a Backend en pymes españolas.
Compilado por el equipo de Join a partir de datos públicos y de nuestra experiencia en contratación.
Actualizado
De un vistazo
- Salario mediano 50.000 € 40.000 € – 62.000 €
- Plazo de contratación 45–75 días
- Experiencia 3–7 años
Cómo contratar a un·a Desarrollador·a Backend para su pyme
Antes de redactar la oferta, plantéese tres preguntas de encuadre. Determinan qué perfil busca realmente y evitan las confusiones de puesto frecuentes en pyme tech española.
Pregunta 1: ¿Backend, Full-stack o DevOps? Los tres roles se tocan pero no se sustituyen. La persona Backend vive en el código aplicativo: API, base de datos, jobs asíncronos, observabilidad aplicativa. La persona Full-stack cubre backend y frontend a un nivel intermedio-avanzado; suele ser el perfil por defecto en pyme joven (menos de 10 desarrolladores·as). La persona DevOps o SRE posee la infraestructura: Kubernetes, CI/CD, monitoring de infra, fiabilidad. Si su necesidad real es un·a Full-stack con orientación backend, dígalo; no maquille el puesto para atraer perfiles especialistas (los perderá a los 6 meses). Si su necesidad es estabilizar la infraestructura y los despliegues, busque un·a DevOps, no un·a Backend.
Pregunta 2: ¿Cuál es su stack y qué nivel de complejidad de sistema soporta? 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. La fit de stack pesa más que la seniority absoluta para un·a mid-level. Sea explícito·a con 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 a través de comunidades de nicho; no cuente con las ofertas pasivas solas.
Pregunta 3: ¿Qué complejidad de sistema soporta realmente su producto? Un·a Backend en pyme early-stage que sirve 100 peticiones por segundo sobre una stack Django más Postgres tiene un puesto muy distinto de un·a Backend en scale-up que gestiona 10.000 peticiones por segundo con cola de mensajes, caché distribuida y latencia p99 crítica. Encuadre con honestidad cuáles son sus restricciones (volumen, latencia, criticidad, observabilidad actual) en la oferta y la entrevista. Las personas candidatas con experiencia preguntan por este tema; quien descubre la realidad después de incorporarse se marcha en los primeros 12 meses.
Si las tres respuestas convergen hacia un·a Backend a jornada completa (y no a un·a Full-stack o un·a DevOps), pase al modelo de oferta a continuación.
Modelo de descripción de puesto
Desarrollador·a Backend: servicios y datos en pyme
[Nombre de empresa], pyme B2B del sector [sector] con sede en [ciudad], [X] personas en plantilla y [X] M€ de facturación, busca incorporar un·a Desarrollador·a Backend al equipo técnico de [X] personas.
Misión
Diseñar, desarrollar y mantener los servicios backend del producto (API, base de datos, jobs asíncronos, observabilidad aplicativa), en autonomía sobre los temas familiares y en colaboración sobre las decisiones estructurantes. La persona reporta a la [Tech Lead / CTO / Dirección Técnica].
Responsabilidades
- Entregar funcionalidades backend de principio a fin: comprensión de la necesidad de producto, diseño técnico, implementación, tests, despliegue, observabilidad y seguimiento en producción.
- Diseñar y hacer evolucionar las API internas y externas (REST, GraphQL o gRPC según el contexto) con atención a la coherencia, la idempotencia y la retrocompatibilidad.
- Mantener y evolucionar el esquema de base de datos: migraciones seguras, optimización de las consultas críticas, decisiones de indexación.
- Participar en las decisiones de arquitectura del propio ámbito (elección de biblioteca, refactor, diseño de un nuevo servicio o cola de mensajes).
- Participar en la guardia u on-call: diagnóstico de incidentes, mitigación, post-mortem compartido, acción sistémica de prevención.
- Mantener la calidad del código: revisión de las PRs de las personas compañeras, aplicación de convenciones, refactor al paso cuando proceda.
- Documentar las decisiones técnicas importantes (ADR) y las zonas de complejidad no trivial.
- Colaborar con producto, diseño, frontend o directamente con dirección en los briefs; cuestionar de forma constructiva las restricciones inviables o contraproducentes.
Perfil
- Imprescindible: [3 a 7] años de experiencia profesional en desarrollo backend; dominio sólido de al menos un lenguaje backend moderno (Node, Python, Go, Ruby, Java, Kotlin o equivalente) y de al menos una base de datos relacional (Postgres, MySQL); experiencia de ownership de un servicio en producción (despliegue, monitoring, gestión de incidentes).
- Valorable: familiaridad con nuestra stack [lenguaje y framework, base de datos, infraestructura, observabilidad]; experiencia en pyme o scale-up (alta autonomía); expertise en un tema concreto (observabilidad, rendimiento, seguridad aplicativa, colas de mensajes, search); contribuciones a open source o side projects públicos.
- Excluyente: ninguna experiencia de ownership en producción en autonomía; rechazo a participar en la guardia o a tocar la observabilidad; ausencia total de práctica de tests automatizados.
Qué ofrecemos
- Retribución bruta anual: fijo [40-62] mil euros según experiencia. Sin variable estructural; eventualmente phantom shares o stock options según la fase de la sociedad.
- Modalidad: [jornada completa, híbrido 2-3 días por semana en oficina, base en [ciudad] / remote-friendly].
- Guardia: [ritmo, compensación económica o en descansos, runbooks y observabilidad existente].
- Beneficios: [seguro médico, ticket restaurante, cheque transporte, días adicionales de vacaciones, política de teletrabajo, presupuesto de material, presupuesto de formación y conferencias].
- Stack: [a completar: lenguaje y framework, base de datos, cola de mensajes, infraestructura, CI/CD, observabilidad].
Banda salarial
Salario fijo bruto anual
Salario bruto anual de referencia para un·a Desarrollador·a Backend de nivel intermedio (3 a 7 años de experiencia profesional) en pymes españolas. Madrid y Barcelona en entorno SaaS B2B, fintech o scale-up tiran hacia arriba (58-78 mil euros), sobre todo en stacks Go, Java o Kotlin con componente distribuida. Resto del territorio y sectores tradicionales tiran hacia abajo (35-45 mil euros). Los perfiles con expertise demostrable en observabilidad, rendimiento o seguridad aplicativa suman habitualmente entre 5 y 8 mil euros sobre la mediana. Los puestos de backend en España rara vez incluyen retribución variable estructural; algunas scale-ups ofrecen phantom shares o stock options.
Fuentes: INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software) ; InfoJobs, Estado del Mercado Laboral en España 2025 ; Honeypot State of Software Engineering Spain 2025
Dónde captar este perfil
-
LinkedIn
Recruiter Lite desde 170 € al mes; 200-400 € al mes adicionales para Job SlotsCanal con mayor profundidad para perfiles backend en España, sobre todo en Madrid y Barcelona. El sourcing activo (Recruiter Lite más InMails personalizados) bate con claridad a las ofertas pasivas: los buenos perfiles backend con 3-7 años de experiencia están casi siempre en puesto y no consultan el feed de empleo. Filtre con precisión por stack (Go más PostgreSQL más Kubernetes rinde mucho mejor que backend senior), seniority y tamaño de empresa previa. Personalice el primer mensaje citando un proyecto o una stack concreta; los InMails genéricos se quedan por debajo del 5 por ciento de tasa de respuesta.
-
InfoJobs
Oferta destacada desde 199 € por publicación; packs multioferta desde 450 €El portal con mayor volumen de candidaturas activas en España, especialmente fuerte fuera de Madrid y Barcelona (Valencia, Sevilla, Zaragoza, Bilbao) y en pyme tradicional con stack mainstream (Java, .NET, PHP moderno). Genera volumen, no siempre señal: filtre con CV semiestructurado y una prueba técnica breve antes de invertir tiempo en la fase de cribado. Menos eficaz para stacks de nicho (Rust, Elixir, Clojure) o para entornos scale-up con cultura técnica fuerte. Útil como complemento de LinkedIn cuando se busca cubrir un puesto rápido.
-
Tecnoempleo y Manfred
Tecnoempleo desde 250 € por oferta; Manfred sin coste de publicación, comisión por contrataciónTecnoempleo concentra una audiencia tech española muy específica (sobre todo backend, devops, datos), con tráfico orgánico recurrente sobre stacks Java, .NET, Python y cloud. Manfred funciona como reverse recruiting: la persona candidata publica un perfil detallado (stack, expectativa salarial, intereses) y la empresa solicita la conversación; muy eficaz para perfiles senior que ya no usan LinkedIn de forma activa. Complementos útiles para huir del ruido de los portales generalistas, sobre todo cuando se busca encaje fino de stack o seniority real.
Manual de evaluación
El puesto de Desarrollador·a Backend se evalúa en cinco etapas. El ejercicio de diseño de sistema (etapa 4) es el más predictivo para este puesto: es donde se revela la capacidad de razonar sobre restricciones distribuidas, persistencia y observabilidad, que una pyme necesita para no acumular deuda operativa durante 18 meses.
-
Etapa 1: Lectura del CV
Busque coherencia de stack y profundidad real en backend: un·a perfil etiquetado·a como backend que ha pasado el 80 por ciento de su tiempo en UI no es el·la candidato·a buscado·a. Indicios fuertes: ownership de un servicio en producción (despliegue, monitoring, incidentes), exposición seria a una base de datos relacional, presencia de palabras clave concretas (Postgres, Redis, colas de mensajes, OpenTelemetry, profiling). Estabilidad mínima de 18-24 meses por puesto. Un·a autodidacta con 4 años de ownership en producción vale más que un·a recién egresado·a de escuela puntera con 2 años de tickets cerrados sin contexto real.
-
Etapa 2: Phone screen (30 min)
Tres preguntas dirigidas: (1) Describa el servicio backend más complejo del que ha sido responsable; QPS, tamaño de datos, restricciones, (2) Describa un incidente de producción que pilotó; síntoma, diagnóstico, resolución y seguimiento, (3) ¿Por qué un cambio ahora? Salida: go o no-go en 5 minutos de debrief, no más. En esta fase evite las preguntas técnicas tipo trampa; busque la solidez del recorrido en producto.
-
Etapa 3: Entrevista técnica (60-90 min)
Pair programming sobre un ejercicio acotado (45-60 min) parecido al día a día: añadir un endpoint con restricción de concurrencia, refactor de una consulta N+1, depurar una race condition simulada. Después 15-30 min de preguntas y respuestas sobre las decisiones técnicas. Evalúe el razonamiento en voz alta, la capacidad de pedir aclaraciones y el instinto sobre las trampas de producción (idempotencia, timeouts, reintentos, aislamiento transaccional).
-
Etapa 4: Ejercicio de diseño de sistema (60 min)
Discusión de arquitectura sobre un caso concreto próximo a su producto: diseño de un sistema de webhooks fiables, una cola de procesamiento asíncrono, un endpoint de búsqueda o un pipeline de agregación. Evalúe la clarificación de restricciones (QPS, latencia objetivo, volumetría, criticidad), los arbitrajes explícitos (síncrono frente a asíncrono, push frente a pull, consistencia fuerte frente a eventual), la mentalidad de observabilidad desde el diseño (métricas, logs estructurados, trazas, alertas) y el reconocimiento honesto de las zonas de incertidumbre. Es la etapa más predictiva para este puesto.
-
Etapa 5: Referencias (verificación estructurada)
Llame a dos referencias: un·a antiguo·a tech lead o manager directo y un·a antiguo·a compañero·a de backend. Plantee a ambas las mismas cuatro preguntas: ¿En qué destaca más?, ¿Para qué contrataría a una persona complementaria?, ¿Volvería a contratarle mañana y por qué?, ¿Un ejemplo concreto de decisión técnica difícil tomada en autonomía? La cuarta pregunta es la que revela el verdadero indicio de autonomía en un puesto de backend.
Preguntas de entrevista estructuradas
-
Conductual Depuración y observabilidad Describa el incidente de producción más serio que pilotó. ¿Cuál fue el síntoma, el diagnóstico, la resolución y el seguimiento sistémico?
Lo que revela una buena respuestaMétodo estructurado: reproducción u observación directa, formulación de hipótesis, validación con logs, métricas o experimentación dirigida. Honestidad sobre la duración y las falsas pistas. Bonus: la persona candidata cita la causa raíz (no solo el hotfix) y la medida preventiva aplicada después (post-mortem, alerta añadida, test de regresión). Las respuestas tipo reinicié el servicio y todo volvió a la normalidad sin diagnóstico revelan debilidad en investigación.
-
Conductual Diseño de sistemas Describa una decisión de arquitectura importante que tomó en su último puesto. ¿Por qué era difícil y cómo la resolvió?
Lo que revela una buena respuestaCapacidad de estructurar una decisión bajo incertidumbre: clarificación de restricciones, alternativas evaluadas, arbitrajes explícitos entre simplicidad y flexibilidad futura, consulta a las partes implicadas, validación posterior. Bonus: la persona candidata menciona una decisión sobre la que cambiaría hoy o un ADR escrito para el equipo. Quienes describen una decisión obvia con perspectiva nunca llegaron a arbitrar de verdad.
-
Conductual Rendimiento y medición Cuénteme una vez en la que su solución inicial no aguantó bajo la carga real. ¿Cómo diagnosticó y corrigió?
Lo que revela una buena respuestaHumildad frente a las hipótesis iniciales: la persona candidata reconoce el límite, mide antes de actuar (profiling, métricas, carga real frente a sintética), arbitra entre optimización local y rediseño. Bonus: identifica en retrospectiva la señal que podría haber leído antes. Quienes afirman no haber tenido nunca un problema de carga mienten o no han servido tráfico real.
-
Situacional Seguridad aplicativa Descubre una vulnerabilidad de seguridad (inyección SQL, secret en claro en un repo, IDOR en un endpoint) en una code review de un·a colega senior. ¿Cómo reacciona?
Lo que revela una buena respuestaCapacidad de señalar una debilidad sin bloquear: comentario factual en la PR (aquí está el riesgo concreto, esta es una propuesta de solución), corrección propuesta, escalado al·a la tech lead o al equipo de seguridad si la PR se mergea pese al comentario. Quienes lo dejan pasar porque la otra persona es senior muestran falta de coraje técnico, crítico en un puesto de backend.
-
Situacional Comunicación con producto Una persona PM le pide añadir un endpoint de búsqueda full-text sobre la base. Usted estima 3 semanas; la persona PM lo quiere en 1. ¿Cómo reacciona?
Lo que revela una buena respuestaClarificación de la necesidad real antes de negociar el plazo: qué volumen de datos, qué latencia aceptable, qué funcionalidades realmente imprescindibles (filtros, scoring, resaltado). Propuesta de opciones explícitas: MVP vía ILIKE de Postgres en 1 semana más indexación real en V2, o recorte de alcance. Las respuestas del tipo lo hago en 1 semana si trabajo el fin de semana son una bandera roja.
-
Situacional Pragmatismo y priorización Se incorpora a un servicio backend con deuda operativa alta: sin métricas, despliegues manuales, alertas silenciosas, tests de integración rotos desde hace 6 meses. ¿Cuál es su plan a 30 días?
Lo que revela una buena respuestaDiagnóstico primero, no la revolución total: priorización por riesgo operativo. Típicamente: (1) observabilidad mínima para ver antes de actuar (métricas básicas, logs estructurados, dashboard de incidentes), (2) asegurar el pipeline de despliegue (rollback rápido, un entorno de staging fiable), (3) reverdecer los tests críticos en las zonas de negocio sensibles, (4) plan más largo para el resto. Validación explícita con el equipo y la persona tech lead antes de avanzar.
-
Caso práctico Diseño de sistemas Diseño: queremos un sistema de webhooks fiables hacia los clientes; entrega garantizada, orden razonable, gestión de clientes lentos o no disponibles. ¿Cómo lo diseña?
Lo que revela una buena respuestaAclaraciones antes de proponer: volumen esperado, criticidad, restricciones de latencia, SLA prometido a los clientes. Arquitectura coherente: cola de mensajes persistente, reintentos exponenciales acotados, dead-letter queue, idempotencia en el receptor, firma HMAC, aislamiento de clientes lentos (rate-limit o worker dedicado). Observabilidad: tasa de éxito por cliente, latencia p99, tamaño de la cola. Bonus: reconoce zonas de incertidumbre (prototiparía Kafka frente a RabbitMQ frente a SQS según el volumen real antes de comprometerme). Quienes se meten en el código sin clarificar revelan debilidad de diseño.
-
Caso práctico Depuración y observabilidad Debug: su API devuelve un 500 en el 1 al 2 por ciento de las peticiones en hora punta. Los logs aplicativos no muestran nada evidente. ¿Cómo investiga?
Lo que revela una buena respuestaMétodo estructurado: (1) elevar temporalmente el nivel de log y activar el tracing en los endpoints afectados, (2) correlacionar con métricas (latencia p99, tamaño de payload, conexiones de base de datos, memoria, GC), (3) buscar un patrón (hora, tipo de petición, usuario·a concreto·a, ratio sobre un pod determinado), (4) hipótesis ordenadas: pool de base de datos saturado, timeout aguas arriba, race condition, OOM, panic no recuperada. Quienes se precipitan con seguro es la base de datos sin investigar revelan sesgo.
-
Caso práctico Rendimiento y medición Rendimiento: una consulta de listado da 4 segundos p95 con 200 ms de p50. Tiene 1 semana para bajar el p95 por debajo de 800 ms. ¿Plan de acción?
Lo que revela una buena respuestaMedir antes de optimizar: EXPLAIN ANALYZE sobre la consulta, profiling en aplicación, comprobación del pool de conexiones. Identificar el cuello de botella real: índice ausente, N+1, payload enorme, serialización costosa, lock de tabla. Jerarquizar por esfuerzo por impacto. Las respuestas tipo añado Redis delante sin diagnóstico revelan reflejo de optimización prematura. Bonus: la persona candidata nota que una brecha p50 frente a p95 tan fuerte sugiere un comportamiento por caso (usuario·a con dataset grande, lock ocasional) más que una lentitud uniforme.
-
Técnica Fundamentos backend Diferencia práctica entre una transacción de base de datos (con nivel de aislamiento REPEATABLE READ o SERIALIZABLE) y un lock aplicativo distribuido (Redis, Zookeeper). ¿Cuándo usar uno y no el otro?
Lo que revela una buena respuestaTransacción de base de datos: atomicidad e isolation gestionadas por la base, acotadas a una sola DB; isolation fuerte al precio de conflictos visibles (serialization failures a reintentar en el lado aplicativo). Lock aplicativo: coordinación entre procesos o instancias cuando la coordinación supera una sola base (microservicios, deduplicación de jobs, leader election). Riesgos distintos: deadlock frente a lock perdido si cae quien lo retiene (de ahí los TTL y el fencing token). Quienes no distinguen los dos mecanismos crean race conditions en producción.
-
Técnica Fundamentos backend Idempotencia de un endpoint que crea un recurso (por ejemplo, un pago). ¿Cómo la implementa en concreto con PostgreSQL más un servicio stateless?
Lo que revela una buena respuestaComprensión clara: la persona cliente envía una clave de idempotencia (cabecera HTTP), el servidor la persiste junto con la petición y la respuesta, y toda petición posterior con la misma clave devuelve la respuesta almacenada sin volver a ejecutar el efecto. Detalles esperados: restricción UNIQUE sobre la clave en la base, manejo del conflicto (devolver la respuesta cacheada, no un 409), TTL razonable (24-48 horas típico), interacción limpia con la transacción de negocio (idealmente la misma transacción o compensación). Quienes responden compruebo si ya existe antes de insertar crean una race condition clásica.
-
Técnica Calidad del código Estrategia de tests en un servicio backend: pirámide, tipos, lo que realmente mide. Describa el arbitraje en su último proyecto.
Lo que revela una buena respuestaComprensión de la pirámide: muchos unitarios sobre la lógica de negocio, menos integraciones acotadas a las fronteras (base de datos, colas, APIs externas), pocos end-to-end. Distinción entre cobertura y utilidad: 90 por ciento sobre código trivial vale menos que 60 por ciento sobre la lógica de negocio crítica. Bonus: la persona candidata cita una vez en que un test evitó una regresión real, o un tipo de bug que los tests no atrapan (race conditions, problemas de configuración en producción). Quienes responden testeo al 100 por ciento sin matizar muestran un juicio débil.
-
Valores Coachability ¿Cómo recibe una code review crítica sobre código del que estaba convencido·a de haber hecho bien?
Lo que revela una buena respuestaApertura: capacidad de separar el código del ego personal. Bonus: la persona candidata cita una vez en que cambió de opinión gracias a una review y explica qué le hizo cambiar. Quienes describen sobre todo haber explicado su lógica a la persona reviewer en lugar de escucharla muestran una debilidad de coachability crítica para un puesto donde la calidad del código es compartida.
-
Valores Mentoría y transmisión ¿Qué papel juega en la transmisión técnica a perfiles junior o a las nuevas incorporaciones?
Lo que revela una buena respuestaPostura de mentoría activa: pair programming, reviews pedagógicas (no solo ok merge), documentación de las decisiones importantes (ADR), compartir en reuniones de equipo o en lunch and learn. En pyme con equipo backend pequeño (3-8 personas), la capacidad de transmisión es esencial para la pervivencia del código. Quienes responden ayudo cuando me piden sin más precisión muestran una postura pasiva.
-
Valores Comunicación con producto ¿Cómo trabaja con una persona PM o una de frontend? Describa una vez en la que devolvió un brief de producto con cuestionamientos.
Lo que revela una buena respuestaPostura de partenariado: cuestionamiento constructivo basado en la viabilidad, la complejidad o el coste operativo a largo plazo (la persona backend vive con los esquemas y los contratos de API que expone). Propuesta de alternativas. Bonus: la persona candidata cita un caso en el que aceptó el brief inicial tras conversarlo. Quienes describen a las personas PM o frontend como gente que no entiende la complejidad técnica revelan debilidad en juego de equipo.
Cómo reconocer a un·a excelente Sales Manager
| Competencia | Por debajo | En el nivel | Por encima |
|---|---|---|---|
| Solidez técnica backend | Tropieza con los fundamentos (HTTP, transacciones, asincronía, concurrencia). Elige por costumbre o por moda más que por adecuación. Difícil de cargar en un nuevo lenguaje backend. | Domina la stack actual en autonomía. Comprende los fundamentos lo suficiente para depurar en profundidad. Sabe aprender un nuevo lenguaje o framework backend en 4-8 semanas de forma productiva. | Referente técnico en su stack y capaz de saltar a otra stack backend en pocas semanas. Anticipa trampas clásicas (race conditions, fugas de conexiones, degradación por locks). Construye abstracciones útiles, no prematuras. |
| Diseño de sistemas | Se mete en el código sin clarificar las restricciones (volumen, latencia, criticidad). Sobre-diseña (microservicios para un MVP) o infra-diseña (monolito spaghetti de 50 mil líneas). Difícil de hacer arbitrar entre simplicidad y escalabilidad. | Clarifica la necesidad antes de programar. Pragmático·a en los arbitrajes síncrono frente a asíncrono, push frente a pull, consistencia fuerte frente a eventual. Reconoce sus zonas de incertidumbre y propone un POC dirigido cuando es pertinente. | Diseña sistemas que envejecen bien: abstracciones justas, dependencias mínimas, fronteras de negocio claras, observabilidad desde el diseño. Forma al equipo en pensamiento sistémico y escribe ADRs legibles por las nuevas incorporaciones. |
| Observabilidad y depuración | Diagnostica por prueba y error sin modelo mental. No instrumenta el código en producción (logs anémicos, sin métricas de negocio, alertas silenciosas). Reacciona al incidente, no anticipa nada. | Método de depuración estructurado: reproducción, hipótesis, validación con logs o métricas. Añade la observabilidad necesaria al paso. Sabe pilotar un incidente de producción sin pánico. | Piensa observabilidad desde el diseño: SLI y SLO definidos, dashboards legibles, alertas con sentido (sin ruido), post-mortems honestos. Reconstruye el histórico de un incidente a partir de logs o trazas y propone una acción sistémica. |
| Seguridad aplicativa | Sin conciencia de los riesgos comunes (OWASP Top 10, secrets en claro, IDOR, deserialización). Programa sin validación de entrada sistemática. Considera la seguridad como un problema ajeno. | Conoce los principales riesgos aplicativos y los evita por defecto: consultas parametrizadas, validación en servidor, gestión sana de los secrets (vault o variables de entorno), revisión de PR con ojo de seguridad. Sabe señalar una vulnerabilidad en código ajeno. | Referencia de seguridad en el equipo: revisión de modelos de amenazas, elección de bibliotecas criptográficas seguras, gestión de dependencias vulnerables (monitoreo de CVE), tests de seguridad automatizados en CI. Coordina con el equipo de seguridad o la persona DPO en temas sensibles. |
| Calidad e higiene del código | Sin estrategia de testing clara; añade tests para subir cobertura. Código mal estructurado (funciones de 300 líneas, números mágicos, duplicación). Reviews superficiales. | Pirámide de tests pertinente sobre la lógica de negocio. Código legible con nombrado claro y funciones cortas. Reviews estructuradas con feedback accionable. Refactoriza al paso cuando es pertinente. | Referente de calidad en el equipo: convenciones documentadas, automatización de controles (linters, type checkers, CI). Reviews pedagógicas que hacen progresar a los perfiles junior. Sabe decir no a código que pasa los tests pero envejecerá mal. |
| Comunicación con producto | Explica mal su trabajo a una persona PM o de dirección. Postura defensiva (es demasiado complejo) o de oposición sistemática. Comunica mal plazos y riesgos. | Sabe explicar un arbitraje técnico a una persona PM en lenguaje claro. Cuestiona los briefs de forma constructiva y propone alternativas. Comunica plazos y riesgos de manera transparente. | Puente entre el backend y las demás funciones. Modera debates técnicos de producto, divulga arbitrajes y negocia alcances de forma transparente. Escribe especificaciones técnicas legibles para personas no técnicas. |
Plan de 30/60/90 días
Día 30
- Setup completo del entorno local y primer despliegue (PR trivial) validado en producción
- Lectura y comprensión del código de los 3 servicios backend más críticos de la stack de negocio
- Primer 1:1 documentado con la persona tech lead sobre convenciones, deuda operativa identificada y prioridades
- Primera PR sustantiva (corrección de bug o endpoint pequeño) revisada y mergeada
Día 60
- Entrega en autonomía de un endpoint o de un job backend completo (diseño, implementación, tests, observabilidad, despliegue)
- Primera review de PR de un·a compañero·a con feedback estructurado, no solo clic en aprobar
- Primera guardia u on-call con gestión de al menos un incidente (diagnóstico, mitigación, post-mortem compartido)
- Documentación o ADR redactado sobre una zona tocada recientemente
Día 90
- Entrega regular (1 a 2 PRs por semana) con calidad validada por el equipo en review
- Primera decisión técnica de arquitectura en autonomía sobre un tema ambiguo (refactor, elección de biblioteca, diseño de un componente nuevo)
- Mentoría informal de un·a junior o nueva incorporación (pair programming, reviews pedagógicas)
- Balance formal con la persona tech lead: rampa validada, plan de progresión sobre 1-2 ejes prioritarios (por ejemplo observabilidad o diseño de sistemas)
Errores comunes al contratar para este puesto
-
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).
-
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.
-
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.
-
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.
-
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.