Evaluación de competencias
Evaluación de competencias de Ingeniero Frontend
El frontend es la única parte de tu sistema que cada usuario experimenta personalmente, y una mala contratación envía la primera impresión de tu marca —rota— a cada visitante. Sin embargo, los filtros habituales pasan por alto las habilidades que importan. Un currículum con funcionalidades publicadas y una prueba para llevar a casa aprobada ya no demuestran que un candidato puede construir un componente por sí mismo, ni juzgar si el código que generó un asistente es accesible, eficiente y mantenible. Las trivialidades de CSS y los cuestionarios de frameworks evalúan la memorización de una superficie de API que cambia cada año.
Una buena evaluación pone a prueba el criterio que sobrevive a ese cambio constante: cómo estructura un candidato un componente, decide dónde vive el estado y trata la accesibilidad como un requisito de ingeniería en lugar de una lista de verificación. El formato de mayor señal es corregir un componente con errores realistas y justificar los trade-offs, no construir una aplicación de tareas desde cero. H-Evaluate genera el ejercicio a partir de tu descripción de puesto —generación por puesto, ajustada a tu stack y nivel de seniority— de modo que ningún candidato llega habiendo ensayado la respuesta.
Qué evaluar
Las competencias que predicen el desempeño en este puesto, asignadas a los cinco pilares de contratación.
Depuración de un componente en vivo
Corregir un componente interactivo realista con herramientas reales —un bug de estado, una ruta de teclado rota, un re-renderizado innecesario— y explicar los trade-offs, no construir desde un repositorio vacío.
Profundidad en framework y plataforma
Conocimiento práctico del modelo de renderizado, el DOM y la plataforma de navegador que el puesto requiere, a la profundidad que exige el nivel de seniority, más allá de la API actual de un solo framework.
Criterio de gestión de estado
Decidir dónde debe vivir un fragmento de estado y razonar sobre qué ocurre cuando dos actualizaciones colisionan: toda UI interactiva es un pequeño sistema distribuido.
Criterio de colaboración con diseño
Cómo gestiona un candidato un diseño que es inviable o perjudicial según lo especificado: rechazo temprano y específico con una alternativa, en lugar de construir silenciosamente lo incorrecto.
Comunicación de trade-offs
Justificar por qué eligieron estado local sobre un store, o una abstracción sobre otra, con claridad y honestidad sobre los inconvenientes, no solo sobre la elección que tomaron.
Fluidez en IA
Dirigir la IA para andamiar y explorar, luego revisar y corregir su resultado: detectar un diálogo generado inaccesible o un efecto de closure obsoleto antes de que se publique.
Cómo estructurar la evaluación
- 1Usa un componente interactivo con errores que incluya un bug de estado, un bug de accesibilidad y un bug de rendimiento: depurar está más cerca del trabajo real que construir desde cero.
- 2Incluye un comportamiento deliberadamente ambiguo sin una única respuesta correcta, de modo que la justificación escrita aporte la mitad de la señal.
- 3Limítalo a unos 90 minutos y dilo desde el principio: una muestra de trabajo que ocupa un fin de semana selecciona por tiempo libre, no por habilidad.
- 4Permite que los candidatos usen herramientas de IA abiertamente y premia el comportamiento de verificación, no la pureza de las pulsaciones de teclado.
- 5Califica la justificación junto con la corrección usando una rúbrica anclada, para que la simpatía y un portfolio llamativo no decidan la contratación.
Señales que predicen el éxito
- +Razona sobre la estructura del componente desde el coste del cambio, no desde nombres de patrones
- +Comprueba rutas de teclado, foco y rendimiento en teléfonos de gama media sin que se lo pidan
- +Sopesa dónde debe vivir el estado en lugar de optar por defecto por un store global
- +Usa la IA para andamiar y luego poda y corrige lo que produjo
Señales de alerta
- –Critica el diseño visual cuando se le pide que critique la accesibilidad de un formulario
- –Opta por 'meter todo en un store' sin razonamiento sobre trade-offs
- –Publica un componente generado que no puede explicar línea a línea
- –Trata un portfolio pulido como prueba de autoría que no puede demostrar
Evaluación frente a entrevista
Un recorrido por el portfolio muestra resultados, no autoría, y una IA puede construir un sitio de portfolio convincente en una tarde. Una entrevista premia la narración segura de logros pasados. Una evaluación estructurada muestra la habilidad en bruto sobre tu propia tarea: si el candidato depura un componente real, detecta el problema de accesibilidad y supervisa el resultado de IA. Úsala para ver el trabajo directamente y luego entrevista para ver cómo colaboran y lideran.
Evaluación de competencias
Configura esta evaluación por puesto y seniority
Observa cómo cambia el énfasis en tiempo real al cambiar el puesto y el nivel — sin registro.
Lecturas relacionadas
Cómo contratar a un ingeniero frontend: guía 2026 basada en habilidades
Cómo contratar a un ingeniero frontend en 2026: habilidades clave, una prueba práctica con bugs, señales de fluidez en IA, preguntas estructuradas y un scorecard.
Prueba para casa vs. codificación en vivo: qué funciona de verdad
Prueba para casa vs. codificación en vivo: qué mide cada formato, los costes para el candidato, los riesgos de trampa con IA y el híbrido que supera a ambos.
Entrevistas estructuradas: guía para una selección más justa
Las entrevistas estructuradas se encuentran entre los mejores predictores en la selección de personal. Esta guía explica qué hace que una entrevista sea estructurada y cómo diseñarla, puntuarla y aplicarla.
Preguntas frecuentes
¿Cómo se evalúa a un ingeniero frontend?
Usa una muestra de trabajo en lugar de trivialidades: dale al candidato un pequeño componente interactivo con errores realistas —una condición de carrera en entrada rápida, una ruta de teclado rota, un re-renderizado costoso— y pídele que lo corrija y justifique los trade-offs. Califica el proceso de depuración, los instintos de accesibilidad y rendimiento, y la claridad de la justificación escrita con una rúbrica acordada antes de revisar las candidaturas.
¿Qué habilidades debe cubrir una evaluación de ingeniero frontend?
Evalúa cuatro dimensiones: arquitectura de componentes, criterio de gestión de estado, instintos de accesibilidad y rendimiento, y colaboración con diseño, más fluidez en IA y comunicación de trade-offs. El conocimiento enciclopédico de frameworks no está en la lista de forma deliberada: los frameworks cambian cada pocos años mientras que este criterio se transfiere, y es lo que separa a un ingeniero que escala con tu base de código de uno que deja una deuda de mantenimiento.
¿Debe la contratación frontend usar una prueba para llevar a casa o codificación en vivo?
Por lo general funciona mejor un híbrido. Las pruebas puras para llevar a casa son fáciles de externalizar a IA y difíciles de verificar; la codificación en vivo cronometrada mide los nervios tanto como la habilidad. Una muestra de trabajo en sandbox supervisado —tarea realista, herramientas normales permitidas, proceso visible— seguida de un breve debate donde el candidato defiende sus decisiones, aporta evidencia auténtica sin ninguno de los inconvenientes.
¿Cómo comprobar si un candidato frontend usa bien la IA?
Permite que usen la IA abiertamente dentro de la tarea de sandbox y luego evalúa el flujo de trabajo, no solo el resultado. Los candidatos sólidos andamian código repetitivo y exploran APIs con IA, y luego revisan y corrigen lo que produjo. Una prueba reveladora es entregarles un componente generado por IA que parece correcto pero tiene una ruta de teclado faltante o un closure obsoleto, y preguntarles qué cambiarían antes de publicarlo.