Salario de Desarrollador·a Backend y preguntas de entrevista
En España, el salario mediano de un puesto de Desarrollador·a Backend es de 50.000 € brutos al año; la mitad central de los salarios está entre 40.000 € y 62.000 €.
De un vistazo
- Salario mediano50.000 €
- Plazo de contratación45–75 días
- Experiencia3–7 años
Salario de Desarrollador·a Backend en España
Salario fijo bruto anual
- Percentil 25
- 40.000 €
- Mediana
- 50.000 €
- Percentil 75
- 62.000 €
| Nivel | Percentil 25 | Mediana | Percentil 75 |
|---|---|---|---|
| Junior | 21.000 € | 26.000 € | 32.000 € |
| Intermedio | 40.000 € | 50.000 € | 62.000 € |
| Senior | 46.000 € | 58.000 € | 70.000 € |
Para referencia: el Salario Mínimo Interprofesional (SMI) en España es de 1.221 € brutos al mes en 14 pagas desde el 1 de enero de 2026. (BOE-A-2026-3815: Real Decreto 126/2026, de 18 de febrero, por el que se fija el salario mínimo interprofesional para 2026)
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
Cómo contratar a un·a Desarrollador·a Backend para su pyme
Antes de redactar la oferta, plantéate 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, dilo; no maquille el puesto para atraer perfiles especialistas (los perderá a los 6 meses). Si su necesidad es estabilizar la infraestructura y los despliegues, busca un·a DevOps, no un·a Backend.
Pregunta 2: ¿Cuál es tu 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. Sé explícito·a con tu stack en la oferta (lenguaje, framework, base de datos, infraestructura, observabilidad); filtrará de forma natural los perfiles mal encajados. Si tu stack es rara (Elixir, Rust, Clojure), asume la escasez del vivero y caza de forma activa a través de comunidades de nicho; no cuentes 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), consulta el modelo listo para usar en la sección Descripción del puesto, más abajo.
Plantilla de descripción del puesto de Desarrollador·a Backend
[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].
¿Buscas a alguien para este puesto? Job Studio convierte la plantilla en una oferta lista para publicar, con banda salarial sugerida y formulario de candidatura.
Preguntas de entrevista para Desarrollador·a Backend
15 preguntas estructuradas, agrupadas por tipo. Cada una indica la competencia que evalúa; despliégala para ver qué revela una buena respuesta.
Conductual 3
Describe el incidente de producción más serio que pilotaste. ¿Cuál fue el síntoma, el diagnóstico, la resolución y el seguimiento sistémico?
Depuración y observabilidadLo que revela una buena respuesta
Mé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.
Describe una decisión de arquitectura importante que tomaste en tu último puesto. ¿Por qué era difícil y cómo la resolviste?
Diseño de sistemasLo que revela una buena respuesta
Capacidad 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.
Cuéntame una vez en la que tu solución inicial no aguantó bajo la carga real. ¿Cómo diagnosticaste y corregiste?
Rendimiento y mediciónLo que revela una buena respuesta
Humildad 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 3
Descubres 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 reaccionas?
Seguridad aplicativaLo que revela una buena respuesta
Capacidad 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.
Una persona PM te pide añadir un endpoint de búsqueda full-text sobre la base. Estimas 3 semanas; la persona PM lo quiere en 1. ¿Cómo reaccionas?
Comunicación con productoLo que revela una buena respuesta
Clarificació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.
Te incorporas 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 tu plan a 30 días?
Pragmatismo y priorizaciónLo que revela una buena respuesta
Diagnó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 3
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ñas?
Diseño de sistemasLo que revela una buena respuesta
Aclaraciones 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.
Debug: tu 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 investigas?
Depuración y observabilidadLo que revela una buena respuesta
Mé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.
Rendimiento: una consulta de listado da 4 segundos p95 con 200 ms de p50. Tienes 1 semana para bajar el p95 por debajo de 800 ms. ¿Plan de acción?
Rendimiento y mediciónLo que revela una buena respuesta
Medir 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 3
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?
Fundamentos backendLo que revela una buena respuesta
Transacció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.
Idempotencia de un endpoint que crea un recurso (por ejemplo, un pago). ¿Cómo la implementas en concreto con PostgreSQL más un servicio stateless?
Fundamentos backendLo que revela una buena respuesta
Comprensió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.
Estrategia de tests en un servicio backend: pirámide, tipos, lo que realmente mide. Describe el arbitraje en tu último proyecto.
Calidad del códigoLo que revela una buena respuesta
Comprensió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 3
¿Cómo recibes una code review crítica sobre código del que estabas convencido·a de haber hecho bien?
CoachabilityLo que revela una buena respuesta
Apertura: 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.
¿Qué papel juegas en la transmisión técnica a perfiles junior o a las nuevas incorporaciones?
Mentoría y transmisiónLo que revela una buena respuesta
Postura 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.
¿Cómo trabajas con una persona PM o una de frontend? Describe una vez en la que devolviste un brief de producto con cuestionamientos.
Comunicación con productoLo que revela una buena respuesta
Postura 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.
Salario y contratación por nivel
El mismo puesto en cada nivel: cuánto se paga, cuánta experiencia cabe esperar y cuánto suele durar la búsqueda.
Desarrollador·a Backend Junior
- Salario fijo bruto anual
- 26.000 €21.000 € – 32.000 €
- Experiencia
- 0–2 años
- Plazo de contratación
- 30–55 días
Desarrollador·a Backend (Intermedio)
- Salario fijo bruto anual
- 50.000 €40.000 € – 62.000 €
- Experiencia
- 3–7 años
- Plazo de contratación
- 45–75 días
Desarrollador·a Backend Senior
- Salario fijo bruto anual
- 58.000 €46.000 € – 70.000 €
- Experiencia
- 7–12 años
- Plazo de contratación
- 55–90 días
Salario de Desarrollador·a Backend por país
El mismo puesto y el mismo nivel en cada país que cubrimos, con cifras de fuentes del propio país.
| País | Mínimo | Valor central | Máximo |
|---|---|---|---|
| EspañaEsta página | 40.000 € | 50.000 € | 62.000 € |
| AlemaniaDeutsch | 52.000 € | 62.000 € | 78.000 € |
| FranciaFrançais | 45.000 € | 55.000 € | 70.000 € |
| Países BajosNederlands | 53.160 € | 63.060 € | 72.960 € |
| ItaliaItalianoItalia · sondaggio Crebs · Back-end Developer Mid-weight, anni non indicati | 35.000 € | — | 45.000 € |
Fuentes
- Alemania (consultado en mayo de 2026): Stepstone Gehaltsdaten Backend-Entwickler:in Deutschland 2026 · Stepstone Gehaltsreport 2026 · Honeypot State of Software Engineering Germany 2025 · Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe
- Francia (consultado en mayo de 2026): APEC, Baromètre 2025 de la rémunération des cadres tech · INSEE, DADS 2024 (PCS 388a, Ingénieurs informatiques) · Talent.io, Étude rémunération tech France 2025
- Países Bajos (consultado en agosto de 2026): Intermediair — salaris backend developer
- Italia (consultado en octubre de 2026): Crebs, Guida Stipendi 2026: Media stipendi Back-end Developer in Italia (livelli Junior, Mid-weight e Senior; metodo del sondaggio) · Hays Italia Salary Guide 2026, Technology, Digital & New Media — Software Development, p. 70 (PDF Hays ospitato da QualEnergia; solo confronto) · Hays Italia Salary Guide 2026 (pagina ufficiale dell’edizione)
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. Filtra 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. Personaliza 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: filtra 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
Busca 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) Describe el servicio backend más complejo del que hayas sido responsable; QPS, tamaño de datos, restricciones, (2) Describe un incidente de producción que pilotaste; 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 evita las preguntas técnicas tipo trampa; busca 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úa 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úa 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)
Llama a dos referencias: un·a antiguo·a tech lead o manager directo y un·a antiguo·a compañero·a de backend. Plantea 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.
Cómo reconocer una gran contratación
| 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. |
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, dilo 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. Prefiere 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. Indica con precisión tu stack en la oferta (lenguaje, framework, base de datos, infraestructura, observabilidad); filtrará de forma natural los perfiles mal encajados. Si tu stack es rara (Elixir, Rust, Clojure), asume la escasez del vivero y caza de forma activa; no cuentes 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árate para responder con honestidad.