Prueba de frontend: cómo evaluar más allá del CSS

Una interfaz puede verse perfecta en el diseño y aun así fallar por completo en accesibilidad, rendimiento o mantenibilidad del código. Una prueba de frontend que solo revisa si el resultado visual coincide con el diseño deja fuera justamente lo que distingue a un buen desarrollador de uno que solo sabe maquetar.

Qué evalúa una buena prueba de frontend

Una prueba de frontend completa mira cuatro dimensiones, no solo la fidelidad visual: si la interfaz funciona correctamente en distintos escenarios de datos, incluyendo estados de carga, error y vacío; si es accesible para personas que usan lectores de pantalla o navegan solo con teclado; si el rendimiento es razonable, sin renders innecesarios ni cargas más pesadas de lo necesario; y si el código está estructurado de forma que otro desarrollador pueda mantenerlo sin dificultad.

La fidelidad visual frente al diseño sigue siendo relevante, pero es la dimensión más fácil de verificar a simple vista, y por eso mismo la que menos necesita ocupar el centro de la evaluación.

Accesibilidad y rendimiento

La accesibilidad se puede evaluar con criterios concretos y verificables: si los elementos interactivos son alcanzables y operables con teclado, sin depender exclusivamente del mouse; si las imágenes tienen texto alternativo descriptivo; si el contraste de color cumple con un mínimo razonable de legibilidad; y si la estructura semántica del HTML usa las etiquetas correctas en vez de recurrir a divs genéricos para todo.

El rendimiento se puede evaluar revisando si el componente evita renders innecesarios cuando datos que no afectan su salida cambian, si las imágenes y recursos pesados se cargan de forma diferida cuando no son visibles de inmediato, y si la persona puede explicar con criterio qué decisiones tomó para mantener la interfaz fluida bajo una carga de datos considerable.

Ninguna de estas dos dimensiones requiere herramientas sofisticadas para evaluarse en una prueba técnica. Basta con revisar el código y hacer un par de preguntas específicas durante la conversación posterior al ejercicio.

Ejercicio tipo con rúbrica

Ejercicio. Pide construir una interfaz que muestre una lista de artículos obtenida de una API, con un campo de búsqueda que filtre en tiempo real y paginación simple. Especifica que debe manejar correctamente los estados de carga, error y lista vacía, y que debe ser usable con teclado.

Rúbrica de corrección, sobre cuatro criterios:

Funcionalidad: la interfaz responde correctamente a los distintos estados de datos y a la interacción del usuario.

Accesibilidad: los elementos interactivos son operables con teclado y tienen etiquetas adecuadas para lectores de pantalla.

Estructura del código: los componentes están organizados con responsabilidades claras, sin lógica innecesariamente mezclada en un solo archivo.

Comunicación de decisiones: la persona puede explicar por qué estructuró la interfaz de esa forma y qué haría distinto con más tiempo.

Errores al corregir

El error más común es penalizar decisiones de estilo personal que no afectan la calidad real del código, como preferencias de formato que no impactan legibilidad ni funcionamiento. Otro error frecuente es no dejar tiempo para la conversación posterior al ejercicio, que suele revelar más sobre el nivel real de comprensión que el código entregado por sí solo.

También es un error común evaluar solo el resultado final sin considerar el proceso. Alguien que llegó a una solución imperfecta pero razonó bien el problema y priorizó correctamente bajo el tiempo disponible puede tener mejor nivel real que alguien que entregó algo visualmente perfecto pero sin entender por qué funcionó.

Para ver cómo evaluar específicamente el manejo de JavaScript dentro de este tipo de prueba, en test de JavaScript está la guía con ejemplos por nivel. Si el equipo trabaja con un framework concreto, los ejercicios por seniority están en test de React, y los criterios con los que se corrige el código entregado, en evaluación de código.

Una prueba de frontend que mira accesibilidad, rendimiento y estructura te dice mucho más que una que solo compara pantallas. Si quieres aplicarla con rúbrica y corrección consistente entre evaluadores, puedes agendar una demo y lo vemos con las vacantes que tienes abiertas.

Preguntas frecuentes

¿Es necesario evaluar un framework específico como React o basta con HTML, CSS y JavaScript puros?
Depende de lo que el equipo use en producción. Si el trabajo diario es con un framework específico, evaluarlo directamente da una señal más cercana al trabajo real que evaluar solo fundamentos.

¿Cuánto tiempo debería durar una prueba de frontend completa?
Entre 60 y 120 minutos según la complejidad del ejercicio y el nivel del rol, con tiempo adicional reservado para la conversación de revisión posterior.

¿La accesibilidad se debe evaluar siempre, incluso para roles junior?
Sí, al menos a un nivel básico. No exigir accesibilidad desde el inicio en la evaluación envía la señal de que no importa, y esa práctica es difícil de corregir después si nunca se estableció como estándar.

¿Cómo evalúo el rendimiento sin herramientas especializadas de medición?
Con revisión de código y preguntas directas es suficiente para una prueba técnica: pregunta qué decisiones tomó la persona para evitar renders o cargas innecesarias, y si puede identificar dónde podría haber un cuello de botella en su propia solución.