Evaluación de competencias
Evaluación de competencias de Ingeniero Backend
La contratación backend falla cuando evalúa lo incorrecto. Dos candidatos pueden listar el mismo stack y razonar de forma completamente diferente sobre un endpoint idempotente, una migración de esquema en una tabla en producción o un bucle de reintentos que colapsa un servicio dependiente durante una incidencia. Recordar el funcionamiento interno de un framework es barato y, cada vez más, está a un prompt de distancia. Lo que predice una buena contratación backend es el criterio de sistemas: cómo alguien diseña contratos, modela datos y razona sobre fallos, y eso no se ve en un currículum.
Una buena evaluación mide ese criterio directamente: tareas realistas en un entorno en vivo, ponderadas según el nivel y el contexto para el que se contrata, y calificadas con la misma rúbrica para todos los candidatos. No es un cuestionario sobre la carga diferida del ORM. H-Evaluate genera el ejercicio directamente a partir de tu descripción de puesto —generación por puesto—, de modo que un backend de pagos recibe un énfasis distinto al de uno de analítica, y ningún candidato ha visto las preguntas en ningún foro antes.
Qué evaluar
Las competencias que predicen el desempeño en este puesto, asignadas a los cinco pilares de contratación.
Diseño de API y contratos
Extender un servicio real —diseñando endpoints versionados e idempotentes con semántica de error que un cliente pueda interpretar— en lugar de recitar convenciones REST de forma abstracta.
Modelado de datos y evolución
Profundidad en diseño de esquemas, indexación a partir de patrones de consulta y migraciones seguras sin tiempo de inactividad, calibradas según el nivel de seniority y las exigencias de integridad de datos del puesto.
Fiabilidad y razonamiento ante fallos
Razonar sobre timeouts, reintentos con backoff, radio de impacto y qué falla primero bajo carga, eligiendo un enfoque bajo restricciones reales, no uno de libro de texto.
Criterio ante incidencias y contratos
Cómo gestiona un candidato escenarios realistas: un cliente dependiendo de un bug, una dependencia inestable antes de un lanzamiento, un cambio incompatible a mitad de un despliegue.
Colaboración y comunicación
Cómo explican una decisión de diseño, reconocen un trade-off con honestidad y razonan sobre un problema cuando no tienen el panorama completo.
Fluidez en IA
Supervisar código backend generado por IA, detectando una transacción faltante o un bucle de reintentos ingenuo, y verificar el resultado en lugar de pegarlo sin revisarlo.
Cómo estructurar la evaluación
- 1Inicia a los candidatos desde un servicio pequeño y funcional que deben extender: el trabajo backend real es extensión, no un repositorio desde cero.
- 2Inyecta un modo de fallo realista (una dependencia inestable, una consulta lenta) y observa cómo hacen que el servicio falle de forma controlada.
- 3Incluye un prompt breve de 'qué falla primero a 100x de carga' para evidenciar el razonamiento sobre capacidad y la comunicación al mismo tiempo.
- 4Permite que los candidatos usen sus herramientas habituales, incluidos asistentes de IA, y evalúa qué tan bien supervisan el resultado.
- 5Califica a cada candidato con la misma rúbrica anclada —claridad del contrato, seguridad en la migración, gestión de fallos— para que los resultados sean comparables y defendibles.
Señales que predicen el éxito
- +Diseña endpoints idempotentes y define qué constituye un cambio incompatible
- +Planifica una migración sin tiempo de inactividad en lugar de un simple añadido de columna
- +Añade timeouts, reintentos acotados e instrumentación sin necesidad de indicárselo
- +Verifica el código generado por IA contra el modo de fallo y puede explicar cada decisión
Señales de alerta
- –Domina el framework pero guarda silencio sobre qué ocurre cuando la base de datos falla a mitad de una transacción
- –Recurre a microservicios y cachés antes de demostrar dónde está el cuello de botella
- –Se encoge de hombros ante el versionado y lo que experimenta un cliente durante un despliegue
- –Pega el resultado de IA tal cual y se bloquea cuando se le pregunta por qué hay una línea concreta
Evaluación frente a entrevista
Una entrevista sirve para profundizar en uno o dos temas, pero premia hablar con fluidez sobre sistemas por encima de la capacidad de trabajar realmente en uno. Una evaluación estructurada muestra lo contrario: si el candidato diseña un contrato seguro, detecta un riesgo en la migración y supervisa el resultado de IA en condiciones realistas. Usa la evaluación como evidencia para decidir a quién entrevistar y qué indagar, y luego deja que la conversación profundice en las decisiones que el trabajo ya ha puesto de manifiesto.
Evaluación de competencias
Configura esta evaluación por puesto y seniority
Observa cómo cambia el énfasis en tiempo real al cambiar el puesto y el nivel — sin registro.
Lecturas relacionadas
Cómo contratar a un ingeniero backend: habilidades, pruebas y señales
Cómo contratar a un ingeniero backend en 2026: mapa de habilidades, prueba de trabajo real, señales de fluidez en IA, entrevistas estructuradas y señales de alerta.
Pruebas de muestra de trabajo: la forma más predictiva de contratar
Las pruebas de muestra de trabajo miden lo que un candidato puede hacer realmente y predicen el rendimiento laboral mejor que los currículums o las entrevistas. Cómo diseñarlas y puntuarlas bien.
Entrevistas estructuradas: guía para una selección más justa
Las entrevistas estructuradas se encuentran entre los mejores predictores en la selección de personal. Esta guía explica qué hace que una entrevista sea estructurada y cómo diseñarla, puntuarla y aplicarla.
Preguntas frecuentes
¿Cómo se evalúa a un ingeniero backend?
Dales un servicio pequeño y funcional y pídeles que lo extiendan con una funcionalidad realista, y luego que gestionen un modo de fallo inyectado: una dependencia inestable o una consulta lenta. Termina con una breve explicación de qué falla bajo mayor carga. Esto evalúa diseño de API, modelado de datos y criterio de fiabilidad a la vez, y es mucho más difícil de fingir que trivialidades sobre frameworks o puzzles de algoritmos.
¿Qué habilidades debe cubrir una evaluación de ingeniero backend?
Cuatro áreas predicen la mayor parte del éxito: diseño de API y contratos, modelado de datos y evolución segura de esquemas, instintos de fiabilidad y observabilidad, y fundamentos de seguridad. Pondera según el contexto: un equipo de pagos se inclina por la integridad de datos, uno más cercano a infraestructura por la fiabilidad, pero evalúa las cuatro. El conocimiento específico de frameworks importa mucho menos, porque los frameworks rotan mientras estos problemas de sistemas permanecen.
¿Se debe permitir a los candidatos backend usar herramientas de IA en una evaluación?
Sí. Los ingenieros backend supervisan código generado por IA a diario, así que una evaluación realista debe permitirlo y luego medir qué tan bien lo hacen: si detectan una transacción faltante, un bucle de reintentos sin backoff o una consulta que hace un escaneo completo de tabla en producción. La habilidad que se contrata es la supervisión del resultado de IA, no evitarla.
¿Son los puzzles de algoritmos una buena forma de filtrar ingenieros backend?
Pocas veces. Para la mayoría de los puestos backend de producto, el criterio de sistemas predice el rendimiento mejor que la memorización de algoritmos. Mantén como mucho un ejercicio breve de programación para confirmar la fluidez, y dedica el resto de la evaluación al diseño de API, el modelado de datos y un escenario de fallo realista, que es el trabajo que el puesto realiza día a día.