Diseñar un test de coding para frontend developer que refleje el trabajo real
Qué requieren realmente los roles frontend
La mayoría del trabajo frontend no es algoritmos. Es:
- Leer un árbol de componentes desconocido y encontrar dónde vive el state
- Wirear una respuesta API a una UI sin romper edge cases (loading, error, empty)
- Escribir CSS que sobreviva contenido más largo del que mockeó la diseñadora
- Reconocer cuándo un re-render causa un bug de perf
- Saber cuándo añadir una dependency y cuándo no
Una pregunta de LeetCode "reverse-a-binary-tree" no filtra nada de esto. Peor, filtra fuera a candidatas excelentes en el trabajo real y desinteresadas en puzzles algorítmicos.
Un test de 90 minutos que mide lo real
Da a la candidata una app React pequeña y rota con tres issues:
- Un bug sutil. Una lista re-renderea todas las filas en un solo cambio porque el key prop es el index del array. Es laggy con >100 items pero no obviamente roto.
- Una feature incompleta. Un form que postea pero no maneja los estados loading o error.
- Un problema de styling. Un layout de card que se rompe cuando el título pasa de 40 caracteres.
Pídele arreglar los tres. Provee la app corriendo, el codebase y libertad para añadir librerías (o no).
Esto mide skill real: leer código desconocido, reconocer patterns, juicio sobre dependencies, taste en CSS, completeness sobre edge cases.
Rúbrica
Puntúa cuatro dimensiones, 1-4 cada una, ancladas:
- Diagnóstico de bug. ¿Identificó la causa antes de arreglar? ¿O parchó un síntoma?
- Completeness de edge case. Loading, error, empty — ¿los cubrió sin prompting?
- Calidad de código. Naming, estructura, elecciones de dependency.
- Comunicación. ¿Dejó comentarios o nota corta explicando trade-offs?
Las candidatas senior rutinariamente sacan 3-4 en las cuatro. El test no necesita ser difícil para discriminar bien — necesita ser real.
Cómo administrarlo sin que se filtre
- Rota entre 3-4 variantes de app rota.
- Pinea candidatas a una variante asignada al azar.
- Usa señales de keystroke y coherencia de código de ClarityHire para que una candidata que pegó un fix de otro lado sea flageada para el revisor en la llamada de follow-up.
- Siempre empareja el test con un follow-up de 30 minutos donde recorre sus cambios. Si no puede explicar su propio diff, el score baja.
Qué nunca hacer
- Take-homes de 4 horas. Perderás tus mejores candidatas.
- "Construye un clon de X" abierto. La varianza es muy alta; las rúbricas se rompen.
- Tests que requieran setear entorno local desde cero. Usa IDE hosteada.
El test frontend correcto toma 90 minutos, espeja un ticket de martes por la mañana y produce un score de rúbrica que puedes defender en un debrief.