Cuarenta y cinco minutos, un editor compartido, un desconocido que mira cada tecla y un problema que nunca has visto: invertir una lista enlazada, encontrar el subarray con la suma máxima. Sin documentación, sin búsquedas, a veces ni siquiera autocompletado. Y encima te piden que "pienses en voz alta". Es el live coding, y en muchos procesos de selección sigue siendo el momento que lo decide todo.
Yo estoy en contra. No porque sea difícil, sino porque mide lo que no es. He hecho entrevistas desde los dos lados de la mesa y en otro artículo escribí cómo cambiaría las preguntas técnicas en la era de la IA. Aquí voy al grano: por qué el live coding clásico no funciona, qué les concedo a quienes lo defienden y qué haría en su lugar.
De qué live coding hablo
Primero, una distinción. Estoy en contra del ejercicio algorítmico cronometrado, observado en directo y sin herramientas, sobre un problema que no tiene nada que ver con el trabajo y cuyo resultado decide por sí solo si sigues adelante o no. No estoy en contra de trabajar junto a un candidato en una tarea realista, con documentación y herramientas a mano, para ver cómo razona. Parecen lo mismo, pero no lo son: vuelvo a ello al final.
Mide el estrés, no la competencia
No es solo una impresión. En 2020, unos investigadores de la North Carolina State University y de Microsoft publicaron un estudio controlado con 48 estudiantes de informática: la mitad resolvió un problema en la pizarra delante de un entrevistador y la otra mitad a solas, en una sala privada. Quienes estaban siendo observados obtuvieron resultados más de dos veces peores. Los autores señalan que el formato se parece de forma inquietante al Trier Social Stress Test, un protocolo que se usa en psicología precisamente para provocar estrés.
El estudio es pequeño y está hecho con estudiantes, así que no lo tomo como una ley. Pero confirma lo que cualquiera que haya pasado por una entrevista conoce bien: bajo observación, la memoria de trabajo se reduce, se pierde el hilo, se cometen errores tontos que en condiciones normales nunca se cometerían. El resultado no responde a la pregunta "¿sabe programar?", sino a otra: "¿qué tal programa mientras alguien lo juzga en directo?". Y en el trabajo real esa situación no existe.
El trabajo real no se parece a un live coding
| En el live coding | En el trabajo real |
|---|---|
| 45 minutos para un problema nunca visto | Horas o días, con tiempo para entender el problema |
| Sin documentación ni búsquedas | Documentación, búsquedas y ejemplos siempre abiertos |
| Asistente de IA prohibido | Asistente de IA en el editor, todos los días |
| Un desconocido que mira cada tecla | Concentración, y la review llega después |
| Algoritmos de manual | Leer código existente, integrar APIs, corregir bugs |
| Lo que cuenta es llegar a una solución | Cuentan la legibilidad, los tests y el mantenimiento a lo largo del tiempo |
Quien sea contratado pasará los días leyendo código escrito por otros, eligiendo una librería, entendiendo por qué un test falla solo en CI. Evaluarlo por su capacidad de implementar de memoria un algoritmo, en media hora y bajo la mirada de alguien, es medir una habilidad que usará pocas veces, en unas condiciones en las que nunca trabajará.
Premia a quien entrena el formato, no a quien trabaja bien
El live coding algorítmico se ha convertido en una disciplina en sí misma, con plataformas, cursos y cientos de ejercicios que repetir hasta reconocerlos a simple vista. Quien tiene semanas libres para entrenar llega preparado. Quien trabaja a tiempo completo, tiene familia o simplemente dedica su tiempo a construir software de verdad en lugar de resolver acertijos parte con desventaja. Al final, la entrevista selecciona sobre todo la preparación para la entrevista.
Y penaliza de forma sistemática a algunas personas: a quien sufre ansiedad, a quien es neurodivergente, a quien hace la entrevista en un idioma que no es el suyo y tiene que pensar en voz alta mientras traduce mentalmente. Nada de esto dice algo sobre cómo esa persona escribirá código en un equipo.
También le cuesta a la empresa
Normalmente se habla del candidato, mucho menos de la empresa. Cada falso negativo es un desarrollador válido descartado porque se bloqueó durante diez minutos. Y quien tiene experiencia y alternativas, a menudo, evita por completo un proceso con live coding: la empresa ni siquiera llega a ver a esos candidatos.
Hay también un efecto menos visible. Al observar a alguien bajo presión, el entrevistador acaba valorando la seguridad más que el fondo: quien habla con soltura parece mejor que quien calla y piensa. Es un sesgo que existe en cualquier entrevista, pero este formato lo amplifica.
Lo que les concedo a quienes lo defienden
- Comprobar que una persona sabe programar de verdad es legítimo. Un currículum se puede inflar, y hoy incluso un ejercicio para hacer en casa lo puede resolver una IA.
- Las tareas largas para casa tienen un coste real: horas de trabajo no remunerado, a menudo desproporcionadas para el puesto.
- El live coding es barato y uniforme: el mismo ejercicio para todos, una hora y listo.
Son objeciones serias. Pero la respuesta a "tenemos que verificar las competencias" no puede ser un formato que las mide mal. Hace falta un formato que verifique lo mismo sin la parte que distorsiona el resultado.
Lo que haría en su lugar
- Code review de código real. Un fragmento verosímil, con un bug y algunas decisiones discutibles, para comentarlo como si fuera la pull request de un compañero. Se ve enseguida quién entiende el código, y nadie tiene que escribir al dictado.
- El proyecto del candidato. Un repositorio, un trabajo anterior, un proyecto personal: "explícame esta decisión", "¿qué cambiarías hoy?". Una experiencia vivida aguanta cinco preguntas de profundización; una historia aprendida de memoria se cae a la segunda.
- Una tarea breve para casa, seguida de una conversación. Dos o tres horas como máximo, pagadas si es posible, y luego una conversación en la que el candidato explica y modifica su propia solución. Si la ha escrito una IA y no la entiende, bastan unos minutos de preguntas para notarlo.
- Pair programming sobre una tarea realista. Si de verdad se quiere ver a alguien escribir código: un pequeño repositorio real, documentación e IA permitidas, sin cronómetro sobre el resultado. El entrevistador trabaja con el candidato en lugar de vigilarlo.
- Una sesión de debugging. Un test que falla y tiempo para entender por qué: es lo más parecido a un día de trabajo normal.
Si el live coding se queda, al menos así
Entiendo que no todas las empresas cambien su proceso de un día para otro. Si el live coding se queda, hay algunas reglas mínimas que lo hacen menos injusto:
- comunicar con antelación el formato, la duración y el lenguaje;
- elegir un problema relacionado con el trabajo, no un acertijo de manual;
- permitir documentación y búsquedas, como en cualquier día normal;
- valorar el razonamiento, no solo el resultado final;
- dejar al candidato unos minutos para leer y pensar en silencio antes de pedirle que hable.
Y si el candidato eres tú
Puedes pedir, con educación, una alternativa: una code review, hablar de un proyecto tuyo, una tarea breve para hacer en casa. No todas las empresas aceptarán, pero pedirlo no cuesta nada. Y la respuesta ya dice mucho de cómo trabajan: una empresa que no sabe explicar por qué usa cierto formato probablemente nunca se lo ha preguntado.
En resumen
Estoy en contra del live coding clásico porque mide cómo aguanta una persona el estrés de ser observada, no cómo trabaja. Es un mal negocio para el candidato y también para la empresa, que descarta a personas válidas y selecciona a quien se ha entrenado para el formato. Las alternativas existen y verifican lo mismo, es decir, si una persona sabe programar, sin distorsionar el resultado. He reunido más ideas sobre cómo renovar las entrevistas técnicas en este artículo, y si estás preparando una entrevista, encontrarás las preguntas técnicas organizadas por nivel en la guía de las 25 preguntas de entrevista frontend/Angular.
