Test de algoritmos: qué mide y cuándo aplicarlo
Pocas prácticas de reclutamiento técnico generan tanto debate como el test de algoritmos estilo pizarra. Para algunos equipos sigue siendo el estándar de facto, para otros es un ritual desconectado del trabajo real que filtra mal. La verdad está en algún punto intermedio, y depende mucho de qué mide y cómo se usa.
Qué mide un test de algoritmos
Un test de algoritmos clásico, del tipo invertir una estructura de datos o encontrar un camino óptimo, mide sobre todo dos cosas: familiaridad con estructuras de datos y patrones algorítmicos comunes, y capacidad de razonar bajo presión con tiempo limitado, que es en buena medida lo que también captura un test de razonamiento lógico, con la ventaja de tener baremos y validez reportada. Mide poco o nada sobre otras capacidades igual de relevantes para el trabajo real: diseño de sistemas, calidad de código mantenible, colaboración, o criterio de producto.
Esto no lo descalifica: significa que mide una porción estrecha de lo que hace a alguien bueno en el rol, y que usarlo como única señal produce un panorama incompleto.
Las críticas y qué tienen de cierto
La crítica más común es que este tipo de test favorece a quien practicó específicamente el formato, no necesariamente a quien es mejor desarrollador en el trabajo diario. Es una crítica con fundamento: existe toda una industria de preparación específica para este tipo de entrevistas, lo que sesga el resultado hacia quien tuvo tiempo y recursos para prepararse de esa forma particular, más que hacia habilidad general.
Otra crítica frecuente es que el estrés del formato, resolver un problema abstracto en una pizarra frente a un evaluador con tiempo limitado, no se parece a las condiciones reales de trabajo, donde casi nadie programa así, con documentación y herramientas disponibles casi siempre a mano.
Ambas críticas tienen base real y explican por qué muchos equipos han reducido el peso de este formato en sus procesos en los últimos años, complementándolo o reemplazándolo con ejercicios más cercanos al trabajo real.
Cuándo sí aplicarlo
El test de algoritmos conserva valor en contextos específicos: roles donde el trabajo diario efectivamente requiere razonamiento algorítmico intenso, como sistemas de alto rendimiento o motores de búsqueda, y como señal parcial de capacidad de resolución de problemas cuando se aplica con criterio, sin ser la única variable de decisión.
También tiene sentido en una versión más moderada: problemas de dificultad razonable, resueltos con acceso a documentación, con foco en el proceso de razonamiento y comunicación durante la resolución, no en llegar a la solución óptima de memoria bajo presión extrema.
Con qué complementarlo
Un test de algoritmos, si se usa, debería ser una señal entre varias, no la decisiva. Combínalo con un ejercicio más cercano al trabajo real, como un test de Python o el equivalente en el lenguaje del puesto, con un problema práctico del dominio del rol, una revisión de código existente, o una conversación de diseño de sistemas donde se evalúe razonamiento aplicado en vez de memorización de patrones.
En prueba técnica para programador está el proceso completo con los pesos sugeridos por etapa. La combinación más equilibrada suele ser: un ejercicio práctico que refleje el trabajo diario como señal principal, y un componente algorítmico más ligero, si el rol realmente lo justifica, como señal secundaria y no eliminatoria por sí sola.
Para ver una alternativa centrada en trabajo real en vez de acertijos abstractos, en evaluación de código está la guía con criterios objetivos de revisión.
Un test de algoritmos rinde cuando es una señal entre varias y no la única. Si quieres combinarlo con ejercicios prácticos y evaluación de código en un mismo proceso, puedes agendar una demo y lo armamos con tus roles.
Preguntas frecuentes
¿Debo eliminar por completo el test de algoritmos de mi proceso?
No necesariamente, depende del rol. Para la mayoría de los roles de desarrollo de producto, reducir su peso a favor de ejercicios más aplicados suele mejorar la calidad de la señal obtenida.
¿Qué tipo de rol sí justifica un test de algoritmos exigente?
Roles donde el desempeño en producción depende directamente de la eficiencia algorítmica, como sistemas de muy alto volumen o baja latencia, donde ese razonamiento es parte central del trabajo diario, no un ejercicio académico aislado.
¿Permitir documentación durante el test cambia lo que mide?
Sí, y en general para bien. Acerca el ejercicio a las condiciones reales de trabajo y desplaza el foco desde memorización hacia capacidad de razonar y resolver con las herramientas disponibles.
¿Cómo sé si mi test de algoritmos está filtrando mal a buenos candidatos?
Una señal de alerta es que candidatos con buen desempeño comprobado en trabajos anteriores fallan sistemáticamente este formato específico. Si eso ocurre con frecuencia, vale la pena revisar el peso que le estás dando dentro del proceso completo.
¿Quieres ver Self-AI en acción?
Agenda una demo y descubre cómo tomar mejores decisiones de talento con ciencia e IA.
Artículos relacionados
Evaluación de código: criterios objetivos de revisión
Cinco criterios que hacen que dos evaluadores lleguen al mismo resultado sobre el mismo entregable, y el sesgo que más distorsiona la nota final.
Test de React: qué evaluar y ejercicios de ejemplo
Qué pedir a un junior, a un semi senior y a un senior, con ejercicios concretos y los criterios que separan dominio real de trivia sobre hooks.
Prueba de backend: qué mide una buena evaluación
Un ejercicio de reservas que fuerza a resolver la doble reserva del mismo horario, y la rúbrica para puntuarlo sin premiar el estilo de código propio.