Live coding en la entrevista: cómo transcurre y cómo entrenarlo

Qué es el live coding

El live coding es un formato de entrevista técnica en el que el candidato resuelve un problema en tiempo real, verbalizando su razonamiento en voz alta. El entrevistador no ve solo el código final, sino todo el proceso: cómo entendió el enunciado, cómo eligió el enfoque, cómo reaccionó a las pistas, cómo comprobó su solución.

Es precisamente el proceso el objeto principal de evaluación. Un código que funciona pero escrito en silencio se puntúa a menudo por debajo de una solución imperfecta con un razonamiento claro. Al empleador le interesa cómo vas a pensar ante problemas reales, donde los enunciados son incompletos y no hay una respuesta correcta al final del libro de texto.

Qué evalúa el entrevistador

El checklist formal varía según la empresa, pero el núcleo de la evaluación es universal:

• Trabajo con el enunciado. Si el candidato hizo preguntas de aclaración o se lanzó a escribir código con la primera impresión. Los problemas reales siempre están infradefinidos — saber identificar las condiciones límite antes de escribir código distingue a un ingeniero con experiencia.
• Estructura del razonamiento. Si expuso el enfoque antes de implementar, si descompuso el problema en pasos, si explicó la elección de la estructura de datos.
• Calidad del código. No la brevedad de olimpiada, sino la legibilidad: nombres con sentido, manejo de los casos límite, ausencia de números mágicos.
• Reacción al feedback. Cómo asume el candidato una pista: la incorpora a la solución o se pone a la defensiva. Es una señal directa de cómo será en una code review.
• Autocomprobación. Si pasó la solución por los ejemplos, si encontró por sí mismo el caso límite de entrada vacía — o si declaró «listo» tras la última línea.

Las cuatro fases del live coding: cómo funciona el entrenamiento

En IT Interview Coach el live coding reproduce la estructura de una entrevista real — la sesión transcurre en cuatro fases:

1. Aclaración del enunciado (clarify). Al recibir el problema, puedes hacer preguntas: qué restricciones tiene la entrada, qué devolver con datos vacíos, si importa el rendimiento. La IA responde como un entrevistador real — aclara el enunciado, pero no da pistas de la solución. El simple hecho de preguntar ya suma a la evaluación: así se forma el hábito de no saltar al código.
2. Solución (solve). Escribes el código y lo envías. El número de intentos no está limitado — igual que en una entrevista real, donde tras un comentario del entrevistador puedes corregir.
3. Análisis (review). La IA evalúa la solución: si hay problemas, no da la respuesta hecha, sino que señala la dirección con una pregunta orientativa y una pista sobre el caso límite que se te escapó. Así funciona un buen entrevistador: comprueba si sabes rematar la solución con la mínima ayuda.
4. Discusión (discuss). Tras aceptar la solución — preguntas sobre el enfoque: por qué elegiste esa estructura de datos, cuál es la complejidad, qué cambia si la entrada crece mil veces. Esta fase imita las preguntas de follow-up en las que fallan los candidatos que copiaron la solución o llegaron a ella por casualidad.

Tras la sesión — un debrief estructurado: qué se trabajó, cómo fue la solución por intentos, zonas de riesgo (a partir de las pistas registradas) y qué entrenar a continuación. El debrief se construye solo sobre los datos reales de la sesión — intentos y pistas —, no sobre consejos genéricos.

Errores típicos de los candidatos

• Código desde el primer segundo. El candidato empieza a teclear antes de entender el problema. A los diez minutos resulta que estaba resolviendo otro problema. Regla: primero un ejemplo de entrada-salida en voz alta, luego el código.
• Solución silenciosa. Cinco minutos de silencio — el entrevistador no sabe si el candidato avanza hacia la solución o está atascado. Verbalizar es una habilidad que solo se entrena con la práctica.
• Ignorar los casos límite. Array vacío, un solo elemento, duplicados, números negativos — el set típico por el que hay que preguntar o que hay que manejar antes de declarar «listo».
• Reacción defensiva a las pistas. El entrevistador dice «¿y si la entrada está vacía?» — el candidato se justifica en lugar de «cierto, ahora lo corrijo». Una pista es ayuda, no una acusación.
• Entregar sin autocomprobar. Pasar la solución por el ejemplo del enunciado lleva un minuto y caza la mitad de los errores — pero la mayoría de los candidatos no lo hace.

Cómo entrenar

1. Entrena el formato, no solo los problemas. Resolver cientos de problemas de LeetCode en silencio no prepara para el live coding: bajo la presión de ser observado y con la obligación de hablar, se resuelve de otra manera. Hacen falta sesiones que reproduzcan el formato completo — con aclaración del enunciado y discusión al final.
2. Empieza por problemas de tu nivel. En el bot los problemas se calibran por especialización (Backend, QA, ML) y nivel (Junior — Senior). Fallar en problemas demasiado difíciles no entrena la habilidad, sino la frustración.
3. Trabaja con el debrief. Las zonas de riesgo del debrief son una lista concreta de lo que entrenar. Si de sesión en sesión se repite «no comprueba los casos límite» — ese es tu punto de crecimiento.
4. Combínalo con la teoría. El live coding comprueba la aplicación; la entrevista simulada, la comprensión. En una entrevista real habrá ambos bloques: entrena los dos.

Preguntas y respuestas

Ver también