Scorecard de entrevista para Desarrollador Frontend
Un scorecard estructurado para entrevistar a un Desarrollador Frontend: 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 Frontend
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Arquitectura de componentes e interfaz Mide si la persona diseña componentes que siguen siendo componibles a medida que el producto crece, lo que define cuánta interfaz hay que reescribir cada trimestre. | 20% | Describe los componentes por la pantalla donde aparecen; no puede explicar cuándo una prop debería volverse un slot, un context o un componente aparte. | Explica dónde trazó el límite entre componentes presentacionales y con estado, y nombra una duplicación que unificó y otra que dejó a propósito. |
| Rendimiento y renderizado en el navegador Mide si la persona puede vincular una interfaz lenta a una causa medida — tamaño del bundle, layout thrash, re-renders — en vez de aplicar optimizaciones genéricas. | 18% | Enumera optimizaciones como hábitos — memoizar, lazy load, comprimir imágenes — sin ningún número antes y después ni claridad sobre cuál sirvió. | Nombra la métrica que estaba mal, la herramienta de profiling que la ubicó, el cambio que hizo y el resultado medido después del deploy. |
| Accesibilidad y marcado semántico Mide si la accesibilidad está en el marcado desde el inicio o se agrega tras una auditoría, lo que define cuánta interfaz es usable con teclado y lector de pantalla. | 16% | Trata la accesibilidad como agregar atributos aria al final; construye controles interactivos con div y no puede describir el recorrido por teclado de un formulario. | Usa elementos nativos antes que aria, probó un flujo real con teclado o con lector de pantalla y puede nombrar un patrón concreto que corrigió. |
| Estado del cliente y obtención de datos Mide cómo la persona separa los datos del servidor del estado local de la interfaz, lo que define con qué frecuencia el usuario ve información vieja o contradictoria. | 16% | Pone todos los valores en un único store global; describe el manejo de carga y de error como algo que la librería resuelve sola. | Distingue datos del servidor cacheados del estado efímero de la interfaz, y describe una race condition o lectura vieja concreta y cómo el arreglo cambió el flujo de datos. |
| Comportamiento multi-dispositivo y fidelidad al diseño Mide si la persona entrega una interfaz que aguanta distintos viewports, tipos de input y largos de contenido, de donde sale casi todo el retrabajo de frontend. | 15% | Revisa el trabajo solo en su propio tamaño de pantalla; considera un layout roto en viewport angosto o con texto largo como un caso borde para después. | Describe pruebas con contenido de largo real y con input táctil, y nombra un caso donde objetó un diseño que no sobrevivía a un texto largo. |
| Trabajo con diseño y contratos de API Mide si la persona resuelve temprano los huecos de un diseño o de un endpoint en vez de adivinar, lo que define cuánto del sprint se va en retrabajo. | 15% | Construye lo que muestra el mockup y avisa los bloqueos recién en la revisión; describe los estados faltantes como algo que debían especificar diseño o backend. | Nombra los estados que el diseño omitió — vacío, error, carga, texto largo — y describe haber acordado la forma de la respuesta con backend antes de implementar. |
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.
- Describa una interfaz que haya vuelto más rápida de forma medible. ¿Qué número estaba mal antes, qué mostró el profiling y cuál fue el número después?
- Hábleme de un componente que se reutilizó de maneras que no anticipó. ¿Qué se rompió y cómo cambió su interfaz después de eso?
- Describa la última vez que probó un flujo solo con teclado o con lector de pantalla. ¿Qué encontró y qué cambió en el marcado?
- Cuénteme un handoff de diseño donde el mockup no cubría un estado real. ¿Cómo detectó el hueco y con quién lo resolvió?
- ¿Qué bug de su propio código de frontend apareció solo en un dispositivo o navegador específico? ¿Cómo logró reproducirlo sin tener ese dispositivo delante?
Señales de alarma
- Describe el trabajo solo en términos del framework y no puede explicar qué hace el navegador por debajo.
- Trata la accesibilidad como un requisito legal o como algo que un plugin resuelve al final del proyecto.
- Reporta mejoras de rendimiento sin medición previa ni posterior, solo la afirmación de que se siente más rápido.
- Culpa a diseño o a backend por todo el retrabajo y no puede citar una pregunta que haya hecho antes de construir.
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 Frontend →
Preguntas frecuentes
¿Qué competencias deben ir en un scorecard de desarrollador frontend?
Arquitectura de componentes, rendimiento de renderizado, accesibilidad, estado del cliente y obtención de datos, comportamiento multi-dispositivo y colaboración con diseño y backend. Conviene ponderarlas según en qué va a gastar tiempo el rol: un puesto de design system y uno de features de producto no son el mismo trabajo. Los pesos deben sumar 100 para que todos puntúen en la misma escala.
¿Conviene incluir un ejercicio de código en vivo en una entrevista de frontend?
Un ejercicio corto y parecido al trabajo real informa más que un problema de algoritmos: construir un componente pequeño con estado de carga y de error, o arreglar un layout que se rompe en pantalla angosta. Conviene dejar que la persona use sus herramientas habituales. Lo que se puntúa es cómo decide, no si recuerda una API de memoria.
¿Cómo distinguir a un buen desarrollador frontend de alguien que solo sabe un framework?
Preguntar qué hace el navegador por debajo y qué pasó cuando el framework no resolvió el problema. Los perfiles fuertes explican un problema de render o de layout sin vocabulario de framework y pueden señalar un arreglo medido. Puntuar cada respuesta contra anchors escritos, con la evidencia citada al lado del puntaje, mantiene ese criterio consistente entre entrevistadores.
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.