Diseñar una prueba de codificación para desarrolladores frontend que refleje el trabajo real

Qué requieren realmente los roles frontend

La mayoría del trabajo frontend no son algoritmos. Es:

• Leer un árbol de componentes desconocido y encontrar dónde vive el estado
• Integrar una respuesta de API en una interfaz sin romper casos límite (carga, error, vacío)
• Escribir CSS que funcione cuando el contenido es más largo de lo que diseñó el diseñador
• Reconocer cuándo un re-renderizado es la causa de un error de rendimiento
• Saber cuándo agregar una dependencia y cuándo no

Una pregunta de LeetCode sobre invertir un árbol binario no filtra nada de esto. Peor aún, filtra fuera a candidatos que son excelentes en el trabajo real y no están interesados en puzzles algorítmicos.

Una prueba de 90 minutos que mide lo que realmente importa

Dale al candidato una pequeña aplicación React rota con tres problemas:

1. Un error sutil. Una lista re-renderiza todas las filas en un único cambio porque la prop key es el índice del array. La lista es lenta con >100 elementos pero no está obviamente rota.
2. Una característica incompleta. Un formulario que envía pero no maneja el estado de carga o error.
3. Un problema de estilos. Un diseño de tarjeta que se rompe cuando el título tiene más de 40 caracteres.

Pídeles que reparen los tres. Proporciona la aplicación en funcionamiento, la base de código y la libertad de agregar bibliotecas (o no).

Esto mide habilidad real: leer código desconocido, reconocer patrones, criterio sobre cuándo agregar dependencias, gusto en CSS, integridad en casos límite.

Rúbrica

Puntúa cuatro dimensiones, 1–4 cada una, con anclas:

• Diagnóstico de errores. ¿Identificaron la causa antes de reparar? ¿O parchearon un síntoma?
• Integridad de casos límite. Carga, error, vacío — ¿los cubrieron sin indicación?
• Calidad del código. Nomenclatura, estructura, elecciones de dependencias.
• Comunicación. ¿Dejaron comentarios o una nota breve explicando compromisos?

Los candidatos senior rutinariamente puntúan 3–4 en las cuatro dimensiones. La prueba no necesita ser difícil para discriminar bien — necesita ser real.

Cómo administrarlo sin que se filtre

• Rota entre 3–4 variantes de aplicación rota.
• Fija candidatos a una variante asignada aleatoriamente.
• Usa las señales de keystroke y coherencia de código integridad de ClarityHire para que un candidato que pegó una corrección de otro lugar sea marcado para que el revisor investigue en la llamada de seguimiento.
• Siempre empareja la prueba con un seguimiento de 30 minutos en el que el candidato revisa sus cambios. Si no pueden explicar su propio diff, la puntuación baja en consecuencia.

Qué nunca hacer

• Tareas para hacer en casa de 4 horas. Perderás tus mejores candidatos a empresas que respetan su tiempo.
• Tareas abiertas "construir un clon de X". La varianza es demasiado alta; las rúbricas se rompen.
• Pruebas que requieren configurar un entorno local desde cero. Usa un IDE alojado para que el tiempo de configuración sea cero.

La prueba frontend correcta toma 90 minutos, refleja un ticket de martes por la mañana y produce una puntuación de rúbrica que puedes defender en un debriefing. Es el ancla de cualquier embudo de contratación de desarrolladores frontend.