Scorecard de entrevista para Ingeniero de Software
Un scorecard estructurado para entrevistar a un Ingeniero de Software: 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 Ingeniero de Software
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Diseño de sistemas y descomposición Mide si la persona puede convertir un requerimiento ambiguo en servicios, módulos e interfaces, y sostener esos límites frente a alternativas realistas. | 20% | Elige framework o base de datos antes de tener claros los requerimientos; describe el diseño final sin nombrar una sola alternativa que haya descartado. | Enuncia primero las restricciones, esboza dos o tres estructuras viables y explica cuál se implementó y qué condiciones debían cumplirse para sostener esa elección. |
| Criterio en code review Mide cómo la persona da y recibe feedback en code review, lo que determina cuánto riesgo de defecto detecta el equipo antes de producción. | 18% | Entiende el review como aprobar o bloquear; recuerda comentarios sobre formato y nombres pero ningún caso donde un review haya evitado un defecto real. | Da ejemplos de comentarios que cambiaron un diseño, separa objeciones bloqueantes de preferencias y describe haber cambiado de postura ante datos concretos. |
| Depuración y análisis de causa raíz Mide si la persona aísla causas con evidencia — logs, traces, bisect — en lugar de adivinar, lo que define cuánto tiempo quedan abiertos los problemas en producción. | 18% | Describe el arreglo pero no cómo confirmó la causa; atribuye incidentes pasados a sistemas inestables o a otros equipos sin haber logrado reproducirlos. | Nombra la señal que acotó la búsqueda, la hipótesis que descartó y cómo comprobó que el arreglo atacaba la causa y no el síntoma. |
| Estrategia de testing Mide si la persona elige tipos de test según riesgo y costo, lo que define si la suite detecta regresiones o solo hace más lento el delivery. | 15% | Plantea el porcentaje de cobertura como objetivo; no puede nombrar un bug que los tests hayan detectado, o escribe tests solo cuando se lo piden en el review. | Explica qué capas cubre con tests unitarios, de integración o end-to-end y por qué, y cita una regresión que la suite frenó antes de llegar a usuarios. |
| Criterio de alcance y trade-offs con fecha límite Mide si la persona puede recortar alcance sin ocultar el costo, lo que define cuánto retrabajo no planificado absorbe el equipo después de una release. | 15% | Afirma que todo salió a tiempo y sin concesiones, o menciona atajos sin decir a quién se le avisó ni qué quedó registrado. | Describe un recorte concreto, el riesgo que aceptó, quién lo aprobó y si el trabajo pendiente quedó registrado y efectivamente se completó. |
| Comunicación técnica Mide si la persona puede volver legible una decisión técnica para quien no escribió el código, lo que define si esas decisiones sobreviven a la rotación del equipo. | 14% | Explica el trabajo solo en términos de implementación; cuando se le pide reformularlo para alguien no técnico, repite la misma jerga más despacio. | Ajusta la profundidad al interlocutor, enuncia la decisión antes del detalle y señala un documento o ADR que otra persona usó después. |
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 incidente de producción que haya diagnosticado personalmente. ¿Cuál fue la primera señal, qué descartó y cómo confirmó la causa raíz?
- Describa un diseño que haya implementado en los últimos dos años donde eligió entre dos opciones reales. ¿Qué inclinó la decisión y qué lo habría hecho cambiar de opinión?
- Hábleme de un código suyo que fue rechazado en code review. ¿Cuál fue la objeción y en qué se diferenciaba la versión final de su primer intento?
- Mencione algo que haya escrito y que otro ingeniero tuvo que mantener. ¿Cómo supo si esa persona podía trabajar con ese código sin consultarle?
- ¿Qué fue lo último que sacó de una release para cumplir una fecha? ¿Quién lo decidió, qué riesgo implicó y qué pasó con el trabajo pospuesto?
Señales de alarma
- No puede nombrar una sola decisión técnica que hoy considere equivocada, en toda su carrera.
- Describe todos sus proyectos como exitosos y atribuye cada fracaso a la gerencia o a otro equipo.
- Describe todo logro en plural y no logra aislar qué partes del sistema escribió personalmente.
- Nombra tecnologías y versiones con soltura pero se vuelve vago apenas la pregunta pasa a qué se rompió y por qué.
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 Ingeniero de Software →
Preguntas frecuentes
¿Qué debe incluir un scorecard de entrevista para un ingeniero de software?
Competencias ponderadas que reflejen lo que el rol realmente hace, anchors de conducta que describan cómo suena una respuesta baja y una alta, y una pregunta por competencia que pida trabajo pasado en lugar de hipótesis. Los pesos deben sumar 100 para que los puntajes sean comparables entre entrevistadores. Sin anchors, dos personas usan el mismo número para decir cosas distintas.
¿Cuántas rondas de entrevista necesita una búsqueda de ingeniero de software?
La mayoría de los equipos resuelve con dos a cuatro rondas: una conversación técnica sobre trabajo pasado, un ejercicio práctico parecido al código real y una instancia sobre diseño y colaboración. Sumar rondas más allá de eso suele agregar días de calendario, no información. Conviene definir de qué competencia se hace cargo cada ronda antes de agendarla.
¿Cómo comparar dos ingenieros de software con el mismo puntaje?
Volver a la evidencia detrás de cada puntaje en lugar de discutir los totales otra vez. Comparar los ejemplos concretos que dio cada persona en las competencias de mayor peso y verificar si el puntaje se apoya en algo que hizo personalmente o en algo que hizo su equipo. Verdict puntúa candidatos sobre ese tipo de evidencia citada, así que el desempate queda anclado a lo que realmente se dijo.
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.