Test de React: qué evaluar y ejercicios de ejemplo

Un test de React centrado solo en preguntas de trivia sobre hooks o ciclo de vida filtra a quien memorizó documentación, no a quien sabe construir interfaces mantenibles. Lo que de verdad distingue a un buen desarrollador de React es cómo estructura estado, componentes y efectos secundarios frente a un problema real, no cuántos nombres de hooks recuerda.

Qué evaluar en un test de React por nivel

Un desarrollador junior de React debería poder construir componentes funcionales, manejar estado local con hooks básicos como useState, y consumir una API con manejo razonable de estados de carga y error. No se espera que domine patrones avanzados de optimización.

Un nivel semi senior debería, además de lo anterior, saber cuándo elevar estado, evitar renders innecesarios con las herramientas adecuadas, y estructurar componentes reutilizables con una separación clara de responsabilidades.

Un nivel senior debería poder diseñar la arquitectura de estado de una aplicación completa, decidir cuándo usar contexto frente a una librería de manejo de estado, anticipar problemas de rendimiento antes de que aparezcan, y justificar sus decisiones técnicas con criterio de trade offs, no solo con preferencia personal.

Ejercicios de ejemplo

Ejercicio para nivel junior o semi senior. Dado un componente que muestra una lista de productos obtenida de una API, pide implementar un campo de búsqueda que filtre la lista en tiempo real, con manejo de estado de carga mientras se obtienen los datos iniciales y un mensaje claro si la búsqueda no arroja resultados.

Ejercicio para nivel senior. Entrega un componente con un bug de renders excesivos y pide que lo diagnostique y lo corrija, explicando por qué ocurre el problema antes de arreglarlo. Este ejercicio revela si la persona entiende el modelo de renderizado de React o solo aplica soluciones memorizadas sin comprender la causa.

Criterios de corrección

Evalúa con una rúbrica de cuatro criterios: si el componente funciona correctamente frente a los casos esperados, si el estado está estructurado de forma lógica y sin duplicación innecesaria, si el código es legible y sigue convenciones consistentes, y si la persona puede explicar con claridad las decisiones que tomó cuando se le pregunta.

Este último criterio importa más de lo que parece. Alguien que puede justificar por qué eligió un enfoque sobre otro demuestra comprensión real, mientras que alguien que solo puede repetir un patrón sin explicar el porqué probablemente lo copió sin entenderlo.

Errores al diseñar la prueba

El error más frecuente es hacer preguntas de trivia sobre la sintaxis exacta de un hook poco usado, que no tiene relación con la capacidad real de construir una interfaz funcional. Ese tipo de pregunta favorece a quien repasó documentación recientemente, no a quien tiene experiencia real.

El segundo error es dar demasiado tiempo o demasiado poco. Un ejercicio de React con complejidad razonable debería poder completarse en 45 a 90 minutos según el nivel, lo suficiente para ver decisiones de diseño reales sin convertirse en un proyecto completo no remunerado.

El tercer error es no permitir el uso de documentación durante la prueba. En el trabajo real nadie programa de memoria sin consultar nada, y prohibirlo mide memorización en vez de capacidad de resolver problemas con las herramientas disponibles.

Para ver cómo diseñar una evaluación de frontend más amplia, que cubra más allá de React, en prueba de frontend está la guía completa con ejercicio tipo y rúbrica. Los fundamentos del lenguaje que sostienen a cualquier framework están en test de JavaScript, y los criterios para corregir lo entregado, en evaluación de código.

Un test de React con ejercicios por nivel y rúbrica te dice cómo trabaja la persona, no cuánta API recuerda. Si quieres aplicarlo con corrección consistente, puedes agendar una demo.

Preguntas frecuentes

¿Se debe permitir el uso de IA durante un test de React?
Es una decisión que cada equipo debe tomar según qué quiere medir. Si se permite, el foco de la evaluación debería moverse hacia la capacidad de revisar, corregir y justificar el código generado, más que hacia escribirlo desde cero.

¿Qué tan importante es evaluar TypeScript junto con React?
Depende de si el equipo lo usa en producción. Si es así, vale la pena incluirlo en el ejercicio, porque el manejo de tipos revela otro nivel de cuidado y estructura en el código.

¿Un test técnico de React reemplaza una entrevista de arquitectura?
No. El test técnico mide capacidad de implementación concreta, mientras que una conversación de arquitectura evalúa cómo la persona piensa decisiones a mayor escala, algo que un ejercicio acotado en tiempo no siempre logra capturar.

¿Cuánto peso debería tener este test en la decisión final de contratación?
Es una señal importante pero no la única. Combinarlo con una conversación técnica y con referencias de trabajo previo da una vista más completa que depender solo del resultado del ejercicio.