Cada pocas semanas me escribe un VP de Ingeniería con alguna versión de la misma pregunta: ¿take-home o live coding? Casi siempre acaban de ver a un candidato fuerte quedarse en blanco frente al pizarrón, o un take-home impecable que resultó ser obra del compañero de cuarto, y quieren saber en cuál formato confiar. Mi respuesta suele molestarlos, porque es ninguno de los dos. Take-home vs live coding es una disyuntiva real con una resolución aburrida, y debajo hay un tercer formato que detecta justo lo que a los dos se les escapa. Dirijo una empresa de evaluaciones, Skillvee, así que lee la última parte con ese sesgo en mente. Esto es lo que cada uno ve en realidad.
Qué detecta realmente un take-home
Un take-home le da al candidato tiempo, silencio y sus propias herramientas. Esa es toda su personalidad. Descubres si alguien puede estructurar un proyecto pequeño, nombrar las cosas con sensatez, escribir un test y tomar decisiones razonables cuando nadie le mira por encima del hombro. Para mucho trabajo senior, ese es exactamente el músculo que te importa.
El problema es que también aprendes casi nada sobre quién hizo el trabajo. Un take-home en 2026 es un take-home para el candidato y para los modelos que use, y no hay forma honesta de darle la vuelta a eso. No puedes distinguir el esfuerzo de la subcontratación, ni una entrega de cinco horas de una de quince disfrazada para parecer ligera. Además le cobra el costo justo a la gente que más quieres: la persona con hijos, la que ya tiene un empleo, el candidato que hace malabares con otros cuatro procesos. Los candidatos fuertes racionan sus horas no pagadas, y un take-home pesado es donde muchos se bajan del proceso sin hacer ruido. Escribí por qué dejamos de confiar en el formato por completo en el postmortem del take-home.
Qué detecta realmente una entrevista de live coding
El live coding arregla el problema de atribución poniendo a un humano en la sala. Ves el trabajo mientras ocurre, así que sabes que es suyo, y obtienes algo que un take-home no puede darte: el candidato pensando en voz alta, reaccionando a un imprevisto, haciendo una pregunta aclaratoria o dejando de hacerla. Esa es señal genuina sobre cómo razona alguien en el momento.
Lo que agrega a cambio es un cronómetro y un público, y esas dos cosas tuercen la muestra. Muchos ingenieros excelentes se paralizan cuando un extraño los mira teclear, y muchos mediocres simplemente han practicado el formato hasta volverlo reflejo. El live coding premia sin decirlo la velocidad y la compostura bajo observación, lo cual se correlaciona más con ser bueno en live coding que con ser bueno en el trabajo. Puedes terminar midiendo nervios y archivándolos como competencia.
Take-home vs live coding vs simulación, lado a lado
Esta es la tabla con la que me gustaría que abrieran esos posts de "X vs Y". Agregué la tercera columna porque omitirla sería deshonesto sobre lo que hago.
| Take-home | Live coding | Simulación | |
|---|---|---|---|
| Atribución (si de verdad lo hizo el candidato) | Débil | Fuerte | Fuerte |
| Calidad del código | Sí, sin presión | Sí, contra el reloj | Sí, en contexto |
| Pensar en voz alta | No | Sí | Sí |
| Comunicación | No | Parcial | Sí |
| Colaboración | No | No | Sí |
| Autonomía ante la ambigüedad | Parcial | Parcial | Sí |
| Uso de IA | Sin control | Normalmente prohibido | Medido como habilidad |
| Costo en tiempo del candidato | Alto, horas no pagadas | Bajo | Bajo, una sola sesión |
| Optimiza para | Calidad de lo que construye solo | Compostura en el acto | Cómo trabaja alguien en realidad |
Lee las filas del medio. Comunicación, colaboración, autonomía, si alguien puede dirigir a la IA en lugar de ser aplanado por ella. Esas son las dimensiones en las que de verdad falló la última contratación que lamentaste, y ni un take-home ni una ronda en vivo pueden ver la mayoría. No es que los formatos se ejecuten mal, es que el formato no les da a esas dimensiones ningún lugar donde aparecer.
Por qué la dicotomía es la pelea equivocada
Entonces, la resolución honesta de take-home vs live coding: el take-home cambia atribución por realismo, el live coding cambia realismo por atribución, y eliges tu veneno según qué falla es la que menos te puedes permitir. ¿Contratas seniors con un onsite en el que confías para atrapar impostores? Inclínate por el take-home. ¿Más volumen, y la autoría te quita el sueño? Inclínate por el live coding.
Pero mira entre qué estás eligiendo. Dos maneras de calificar código, una relajada y otra bajo presión. La razón por la que ambas dejan un sabor insatisfactorio es que los errores de contratación caros rara vez fueron por el código. Fueron por la persona que escribía código decente y no toleraba el feedback, o que entregaba rápido y dejaba un desastre para todos los que venían después, o que se bloqueó la primera vez que un problema fue ambiguo en lugar de venir bien delimitado. La calidad del código es el boleto de entrada. Lo que de verdad hace estallar una contratación vive en el proceso, y una prueba solo califica el artefacto.
Ese es el hueco que persigue una simulación. Skillvee es una simulación de 60 minutos de un "día de trabajo" donde el candidato resuelve un problema realista y acotado, habla con compañeros de IA para destrabarse y defiende sus decisiones ante un gerente de IA, con la pantalla grabándose todo el tiempo. Como la IA está permitida y esperada, observas el aprovechamiento de la IA como una habilidad en lugar de vigilarlo como fraude. En una sola sesión ves cómo alguien programa, se comunica, colabora y maneja la ambigüedad, antes de que un solo ingeniero senior gaste una hora de entrevista. El mismo argumento desde el lado de las herramientas está en el desglose de CodeSignal vs HackerRank.
Cuándo elegir cuál
Sin rodeos, ya que ser justo aquí no me cuesta nada:
Usa un take-home cuando el puesto es genuinamente independiente, senior y de bajo volumen, y puedes vivir sin verificar del todo la autoría. Mantenlo por debajo de dos horas, y págalo si te es posible.
Usa live coding cuando necesitas atribución barata y tienes entrevistadores capaces de distinguir a un candidato fuerte pero nervioso de uno débil pero fluido, algo más difícil de lo que la mayoría de los paneles admite.
Usa una simulación cuando el problema costoso es lo que pasa después del filtro: onsites quemados en gente que entrevista bien y trabaja mal, ingenieros senior hundiendo más de cinco horas por contratación, sorpresas después de contratar que nunca fueron por el código. Ese es el caso para el que se construyó, y a volúmenes normales de mitad de embudo reemplaza etapas en lugar de agregar una.
Dónde se pone difícil
Nada de esto es gratis. Una simulación cuesta más por candidato que una prueba automatizada, así que a verdadera escala de inicio de embudo todavía vas a querer un filtro barato delante. Y vive o muere por el diseño de la tarea: una tarea simulada perezosa solo verifica si alguien siguió instrucciones, lo cual es su propia especie de inutilidad. Eso es trabajo real, ya sea que lo hagamos nosotros o lo hagas tú.
La conclusión que sí defendería: take-home vs live coding es una disyuntiva genuina, así que elige según qué riesgo te duele menos. Solo no la confundas con el menú completo. Ambos son respuestas a "qué tan bueno es su código", y la pregunta que predice si una contratación funciona es "cómo trabaja".