Scorecard de entrevista para Desarrollador Full Stack
Un scorecard estructurado para entrevistar a un Desarrollador Full Stack: 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 Full Stack
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Implementación de frontend y manejo de estado Si puede construir interfaces que aguanten datos y cambios de estado reales, y no solo el camino feliz con datos de ejemplo. | 18% | Describe componentes que construyó pero no puede explicar cómo resolvió los estados de carga, error y vacío, ni por qué apareció un loop de re-render. | Recorre un bug de estado concreto — cache desactualizado, dos fetch compitiendo — dice cómo lo reprodujo y qué cambió el fix en el ciclo de render. |
| Diseño de APIs y backend Si diseña endpoints y contratos que sobreviven al cambio, algo central porque un perfil full stack es dueño de los dos lados de cada interfaz. | 18% | Enumera frameworks que usó pero no puede decir por qué un endpoint devolvía esa forma, ni qué se rompió cuando un cliente necesitó un campo nuevo. | Explica un contrato que versionó o dio de baja, quiénes lo consumían y cómo hizo el rollout sin romper a los clientes que ya estaban en producción. |
| Modelado de datos y comportamiento de queries Si puede diseñar un esquema y razonar sobre lo que realmente hace la base de datos, que es donde empiezan casi todos los problemas de performance. | 16% | Escribe queries que devuelven las filas correctas pero no puede explicar por qué un join las duplicó ni cómo verificó que el conteo fuera el real. | Señala una decisión de esquema que tomó — una desnormalización, un índice, una columna nullable que eliminó — y el bug o comportamiento de query que la motivó. |
| Debugging a través de todo el stack Si puede seguir una falla desde el navegador hasta la base de datos, en lugar de adivinar dentro de la capa que mejor conoce. | 18% | Describe incidentes de producción por lo que se arregló, sin contar cómo aisló la causa ni qué evidencia le permitió descartar las otras capas. | Reconstruye un incidente de punta a punta: el síntoma, los logs o traces que leyó, las hipótesis que descartó y cómo confirmó que el fix aguantó. |
| Práctica de entrega y release Si su código llega a los usuarios de forma segura: tests que atrapan regresiones reales, deploys reversibles y cambios de un tamaño que se puede revisar. | 16% | Habla de tests y CI en general pero no puede nombrar un bug que sus tests hayan atrapado, ni describir cómo se revirtió un deploy que salió mal. | Describe su rutina de release en concreto: qué cubren los tests y qué queda afuera a propósito, cómo llega un cambio a producción y el último rollback que hizo. |
| Criterio de alcance y sentido de producto Si cuestiona el trabajo que no va a sobrevivir el contacto con usuarios, algo relevante porque el rol está cerca de las decisiones de producto. | 14% | Toma los requerimientos como vienen y no recuerda haber cuestionado ninguno, o menciona el conflicto como razón para dejar de preguntar. | Recuerda un ticket concreto que renegoció, el costo o riesgo que puso sobre la mesa, con quién lo habló y qué terminó construyendo el equipo. |
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ál fue el bug que más tiempo te llevó encontrar? ¿Cuál era el síntoma, qué revisaste primero y qué resultó estar mal al final?
- ¿Qué API diseñaste que después tuvo que cambiar? ¿Quién la consumía, cómo versionaste o migraste el cambio y qué se rompió igual?
- ¿Qué query o qué pantalla se puso lenta en producción? ¿Cómo la mediste y qué cambió realmente el fix que aplicaste?
- ¿Cuál fue el último cambio que tuviste que revertir o parchear en caliente? ¿Cómo te enteraste de que estaba mal y cuánto tardaste?
- ¿En qué feature discutiste el requerimiento? ¿Cuál fue tu argumento, con quién lo planteaste y qué terminó saliendo a producción?
Señales de alarma
- No puede nombrar un solo bug de producción que haya diagnosticado, solo features que entregó.
- Define full stack como haber usado un framework de cada lado, sin ownership sobre los datos ni sobre los deploys.
- Atribuye cada decisión técnica al equipo o al tech lead, sin explicar en ningún caso su propio razonamiento.
- Descarta tests, code review o rollbacks como burocracia sin describir qué usa en su lugar.
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 Full Stack →
Preguntas frecuentes
¿Qué tiene que cubrir una entrevista para un desarrollador full stack?
Los dos lados del stack con el mismo rigor: un problema de interfaz o manejo de estado, uno de API y modelado de datos, y un ejercicio de debugging que cruce capas. Después conviene confirmar la práctica de entrega — tests, deploys, rollbacks — porque ahí se ve si el ownership full stack es real.
¿Cómo distingo a un full stack sólido de alguien con cobertura superficial de los dos lados?
La profundidad aparece en las causas, no en las herramientas. Conviene pedir una falla concreta y escuchar cómo la aisló: qué capa descartó y con qué evidencia. Los perfiles superficiales enumeran tecnologías; los sólidos nombran síntomas, hipótesis y la verificación que cerró el caso.
¿Cómo mantengo criterios consistentes entre candidatos full stack?
Las competencias y los pesos se fijan antes de la primera entrevista, y todos se puntúan contra los mismos anchors, anotando la evidencia junto a cada puntaje. Verdict hace lo mismo del lado del CV: cada puntaje queda atado a una cita textual, así la comparación se apoya en el registro y no en impresiones.
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.