Test de JavaScript: qué evaluar y ejemplos por nivel

Preguntar de memoria la diferencia entre var, let y const filtra a quien repasó un artículo de blog la noche anterior, no a quien entiende cómo funciona JavaScript en la práctica. Un buen test de JavaScript mide comprensión aplicada: cómo la persona resuelve un problema real, no cuántas reglas de sintaxis puede recitar.

Qué evaluar en un test de JavaScript por nivel

Un nivel junior debería manejar con soltura las estructuras de control, funciones, arrays y objetos, y entender lo básico de trabajo asíncrono con promesas o async await para consumir una API sencilla.

Un nivel semi senior debería, además, entender bien el manejo de contexto y closures, escribir código que evite efectos secundarios inesperados, y manejar casos de asincronía más complejos, como varias llamadas en paralelo con manejo adecuado de errores en cada una.

Un nivel senior debería poder diseñar la estructura de un módulo o servicio completo, razonar con claridad sobre el modelo de concurrencia de JavaScript y por qué ciertas operaciones bloquean o no el hilo principal, y anticipar problemas de rendimiento o memoria antes de que se manifiesten en producción.

Ejercicios de ejemplo

Ejercicio junior o semi senior. Dado un array de pedidos con distintos estados, pide escribir una función que agrupe los pedidos por estado y calcule el total de cada grupo, manejando el caso de que algunos pedidos tengan datos incompletos sin que la función falle.

Ejercicio senior. Entrega código que hace varias llamadas a una API de forma secuencial cuando podrían hacerse en paralelo, y pide optimizarlo, explicando qué riesgos introduce la paralelización, como manejo de errores parciales, y cómo los resolvió.

Preguntas de trivia que conviene evitar

Vale la pena nombrar explícitamente qué evitar, porque es donde más tests de JavaScript fallan. Preguntar la salida exacta de un fragmento de código diseñado para confundir con coerción de tipos poco común no mide capacidad real de trabajo, mide si la persona ha memorizado casos especiales de la especificación del lenguaje. Preguntar de memoria todos los métodos disponibles de un objeto nativo agrega poca señal, porque cualquier desarrollador consulta la documentación para eso en el trabajo real. Es la misma discusión que rodea al test de algoritmos: el formato premia la preparación específica más que la habilidad que el rol necesita.

Este tipo de pregunta favorece a quien estudió específicamente para el examen sobre quien tiene experiencia genuina construyendo software, y suele filtrar mal a candidatos senior que priorizan claridad de código sobre trucos de sintaxis.

Criterios de corrección

La rúbrica es la misma estructura que usamos en test de Python, ajustada a lo que este lenguaje pone en juego. Evalúa con cuatro puntos: si el código resuelve correctamente el problema, incluyendo casos límite razonables; si el manejo de asincronía y errores es apropiado para el nivel evaluado; si el código está bien estructurado y es legible sin necesitar explicación adicional; y si la persona puede justificar sus decisiones de diseño cuando se le pregunta en la conversación posterior al ejercicio.

Para ver cómo evaluar JavaScript dentro del contexto más amplio de una prueba de frontend completa, en prueba de frontend está la guía con ejercicio tipo y rúbrica.

Un test de JavaScript gana señal cuando se parece al trabajo real y se corrige con rúbrica. Si quieres ver cómo se aplica y se califica a escala, puedes agendar una demo y lo revisamos con tu proceso actual.

Preguntas frecuentes

¿Debo evaluar JavaScript puro o directamente con un framework como React?
Depende del rol. Evaluar JavaScript puro primero ayuda a distinguir si los fundamentos son sólidos, antes de ver cómo la persona los aplica dentro de un framework específico.

¿Qué tan importante es TypeScript en un test de JavaScript?
Si el equipo lo usa en producción, vale la pena incluirlo, porque el manejo correcto de tipos revela otro nivel de cuidado. Si no lo usan, evaluarlo puede filtrar candidatos válidos que simplemente no han tenido la oportunidad de usarlo.

¿Cuánto tiempo debería durar el ejercicio?
Entre 45 y 90 minutos según el nivel y la complejidad del problema, suficiente para ver decisiones de diseño reales sin convertirse en un proyecto extenso no remunerado.

¿Se debe permitir usar la consola del navegador o un entorno de pruebas durante el ejercicio?
Sí, siempre que sea posible. Trabajar sin poder probar el código en tiempo real no refleja cómo se programa en el trabajo, y penaliza a candidatos que simplemente prefieren validar su trabajo antes de entregarlo.