Scorecard de entrevista para Desarrollador Backend
Un scorecard estructurado para entrevistar a un Desarrollador Backend: seis competencias con pesos, qué es realmente un 1 y qué es un 5, y preguntas que sacan evidencia en vez de opiniones. Imprimilo o copialo a tu ATS.
El scorecard para Desarrollador Backend
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Modelado de datos y diseño de almacenamiento Mide si la persona modela datos según patrones de acceso e invariantes, y no por conveniencia, porque un esquema equivocado es lo más caro de deshacer después. | 20% | Describe tablas sin nombrar una sola restricción o índice; trata las migraciones de esquema como algo que el ORM resuelve cuando cambia el código. | Explica qué invariantes hace cumplir la base y cuáles la aplicación, y describe una migración sobre datos en vivo hecha sin downtime ni pérdida de datos. |
| Diseño de APIs y contratos Mide si la persona diseña endpoints que se pueden usar sin leer la implementación, lo que define cuánta carga de soporte genera cada integración. | 18% | Modela los endpoints según la pantalla del momento; cambia campos de la respuesta sin versionar y considera que romper clientes es problema de quien consume. | Explica una decisión de compatibilidad — cambio aditivo, ruta versionada, ventana de deprecación — y cómo se avisó y migró a los consumidores. |
| Concurrencia, consistencia y manejo de fallas Mide si la persona razona sobre qué pasa cuando dos requests chocan o falla una llamada aguas abajo, que es donde nace casi toda la corrupción de datos. | 18% | Asume que los requests llegan de a uno y que las llamadas funcionan; agrega un retry sin preguntarse si la operación puede ejecutarse dos veces sin daño. | Nombra dónde aplicó claves de idempotencia, locks o transacciones, y explica contra qué falla se estaba protegiendo y cómo lo probó. |
| Rendimiento de consultas y throughput Mide si la persona encuentra la consulta o el camino de llamadas que domina la latencia bajo carga real, en vez de optimizar código que no era el problema. | 15% | Atribuye la lentitud a la base de datos en general; nunca leyó un plan de ejecución y no puede decir qué consulta se ejecutaba más veces. | Describe la medición que aisló el camino caliente, el índice o la reescritura de consulta que aplicó, y cómo cambiaron la latencia y la carga después. |
| Seguridad y manejo de datos Mide si la autorización, la validación de entrada y el manejo de secretos son parte de cómo construye la persona, porque un error acá expone datos de forma directa. | 15% | Considera que la seguridad es alcance del equipo de infraestructura; verifica autenticación pero no si quien llama puede tocar ese registro en particular. | Describe una verificación de autorización que agregó en la capa de datos y explica cómo se manejan secretos y datos personales en código que escribió. |
| Observabilidad y responsabilidad operativa Mide si la persona instrumenta servicios para que un problema se pueda diagnosticar desde afuera, lo que define cuánto dura un incidente a las tres de la mañana. | 14% | Registra solo errores y solo en desarrollo; se entera de las fallas de producción cuando las reporta un usuario u otro equipo. | Nombra la métrica o el trace que hizo diagnosticable un incidente pasado, y describe una alerta que agregó o quitó porque resultó ruidosa. |
Los pesos suman 100. Acordalos antes de la primera entrevista, no después: ajustar pesos cuando ya hay puntajes es la forma en que un panel justifica a su favorito.
Preguntas que sacan evidencia
Cada una pide algo que ya pasó, con suficiente detalle como para verificarlo. Las hipotéticas premian el ensayo, no la trayectoria.
- Cuénteme un esquema que haya diseñado y luego tuvo que cambiar. ¿Qué tocó la migración, cuántos datos había en vivo y qué hizo para evitar downtime?
- Describa un bug que haya arreglado y que solo aparecía con requests concurrentes. ¿Cómo lo reprodujo y qué garantizaba el arreglo final?
- Hábleme de un cambio de API suyo que rompió a un consumidor. ¿Cómo se enteró y qué cambió después en su forma de publicar contratos?
- Mencione una consulta que haya acelerado en producción. ¿Qué mostraba el plan de ejecución antes y cuál fue la latencia después del cambio?
- ¿Cuál fue el último hueco de autorización que encontró en código, propio o ajeno? ¿Cómo se detectó y qué cambió el arreglo?
Señales de alarma
- Habla de escala en nombres de tecnologías en vez de la carga que un sistema realmente soportó.
- Nunca miró un plan de ejecución y no puede nombrar el endpoint más lento de un servicio que tuvo a cargo.
- Describe la pérdida o corrupción de datos como imposible en vez de un riesgo contra el que diseñó.
- En todos sus ejemplos, la autorización, los reintentos y los backups son responsabilidad de otro equipo.
Cómo usar este scorecard
- Acordá los pesos con el panel antes de que alguien entreviste, y dejalos por escrito.
- Cada entrevistador puntúa todas las competencias por separado, con una nota que cite lo que el candidato dijo textualmente.
- Comparen los puntajes antes de discutirlos. Discutir primero ancla al panel en quien habla más fuerte.
Armar un scorecard a medida → · Cadena booleana para buscar Desarrollador Backend →
Preguntas frecuentes
¿Qué hay que buscar al contratar un desarrollador backend?
Evidencia de haber tenido a cargo datos y tráfico, no solo de haber escrito endpoints: un esquema que migró, un bug de concurrencia que reprodujo, una consulta que midió y arregló. Conviene preguntar qué se rompió en producción y cómo se enteró. La experiencia en un lenguaje o framework pesa menos que la capacidad de razonar sobre fallas.
¿Cómo evaluar diseño de sistemas backend sin una ronda de pizarrón?
Preguntar por un sistema que la persona construyó de verdad y presionar sobre los límites: por qué esos servicios, qué invariantes hace cumplir la base, qué pasa cuando falla una llamada aguas abajo. Un sistema real expone trade-offs que un diseño hipotético no muestra, porque hubo que convivir con las consecuencias.
¿Cómo ponderar un scorecard de entrevista para backend?
Ponderar las competencias por las que el rol puede fracasar. Un servicio con mucha carga de datos pide más peso en modelado y rendimiento de consultas; uno con muchas integraciones, en contratos de API y manejo de fallas. Los pesos deben sumar 100, los anchors se escriben antes de la entrevista y cada respuesta se puntúa contra la evidencia que dio la persona, no contra una impresión general.
Cuando lo que está en juego es una contratación real, usá evidencia
Estas herramientas son heurísticas rápidas. Verdict lee el CV contra tu descripción de puesto y puntúa seis dimensiones con citas textuales como evidencia — un documento de contratación que podés defender.