Alternativas a entrevistas de pizarra: métodos más realistas y justos
Por qué la pizarra quedó obsoleta
Escribir código en una pizarra evaluaba tres cosas: conocer el algoritmo, tener buena letra, y no entrar en pánico bajo presión de presentación. Dos de esas cosas no tienen relación con el trabajo. La mayoría de equipos ha avanzado. Los sustitutos varían en calidad.
Los sustitutos clasificados
Mejor: take-home acotado + walkthrough
Una prueba take-home de 90 minutos produce un artefacto real. Un walkthrough de 30 minutos verifica que la candidatura lo escribió y prueba su razonamiento sobre el mismo. En conjunto, la señal es la más alta de cualquier formato excepto una semana de prueba laboral, y la experiencia de candidatura es dramáticamente mejor que cualquier formato en vivo.
El inconveniente: requiere herramientas de integridad para seguir siendo confiable en 2026. Las señales de tecleo y coherencia de código de ClarityHire hacen viable este formato; sin algo equivalente, el abuso de asistentes de IA erosiona los datos.
Fuerte: sesión de debugging en vivo
Se le da a la candidatura un pequeño codebase roto y se le pide encontrar y arreglar el bug mientras comparte pantalla. El entrevistador ocasionalmente pregunta «¿qué estás pensando?» pero principalmente observa. Prueba velocidad de lectura, instinto de debugging, y juicio.
Menos estrés que live-coding algorítmico porque no hay una página en blanco. Mayor señal que pizarra porque el medio es realista.
Bueno: pair programming en una tarea real
Cubierto en detalle en otro post. Señal alta en nivel senior cuando el entrevistador está realmente en pairing — resolviendo el problema colaborativamente, no observando en silencio.
Mediocre: live-coding con un IDE alojado
Mejor que pizarra porque existen resaltado de sintaxis y botones de ejecución. Sigue teniendo el problema de acertijos algorítmicos si la pregunta es un problema LeetCode. Sigue teniendo ansiedad de presentación. Úsalo como una ronda en un bucle, no todo el bucle.
Malo: live-coding en un editor hostil
Un editor web-based que carece de autocomplete, sin botón de ejecución, sin language server. Estás evaluando familiaridad con IDE, no habilidad. Omítelo.
Malo: take-home sin walkthrough
La candidatura produce un artefacto que no puedes verificar. Con asistentes de IA, este formato produce casi cero discriminación entre candidaturas fuertes y débiles.
Qué combinar
Un buen bucle de ingeniería usualmente incluye:
- Una corta muestra de trabajo asíncrona (take-home o ejercicio de coding asíncrono) para filtrado en etapa de cribado
- Una ronda de debugging en vivo o pair-programming para profundidad técnica
- Una ronda de diseño de sistemas para roles senior+
- Una ronda comportamental estructurada para todos
Tiempo total de candidatura: 5–6 horas más take-home. Tiempo total de entrevistador: 7–9 horas. Distribuido entre formatos realistas, no concentrado en pizarras.
Qué cambia en 2026
La pregunta de diseño de formato más importante en 2026 es: ¿cómo hacemos una take-home robusta contra asistentes de IA sin abandonar el formato? Dos patrones funcionan:
- Entrevistas con walkthrough donde la candidatura explica su propio envío.
- Captura de señal de integridad durante la take-home (tecleo, coherencia de código).
Equipos que resuelven esto obtienen lo mejor de ambos mundos: señal alta, bajo estrés de candidatura, escalable. Equipos que no lo hacen se ven empujados hacia formatos todo-en-vivo que escalan mal y frustran candidaturas fuertes.