Entrevista de live coding: cómo funciona y qué ayuda de verdad
Una entrevista de live coding es la ronda en la que escribes código delante de alguien, en tiempo real, y hablas mientras lo haces. Casi todos los consejos tratan de las semanas previas. Muy pocos tratan de esos cuarenta y cinco minutos, lo cual es extraño, porque es ahí donde candidatos igual de preparados se separan.
Qué es realmente una entrevista de live coding
Te unes a una llamada, el entrevistador abre un editor compartido —CoderPad, CodeSignal, HackerRank o a veces simplemente un IDE con la pantalla compartida— y te da un problema. Tienes entre treinta y sesenta minutos. Los dos veis el mismo cursor. Normalmente no hay autocompletado digno de ese nombre, a menudo no puedes ejecutar tests hasta que lo pides, y siempre hay alguien mirando las pausas.
Es deliberadamente distinta de una prueba para casa. Una prueba para casa mide el código que produces. Una ronda en directo mide cómo lo produces: si preguntas antes de asumir, si detectas tus propios errores, si puedes mantener una conversación con las manos ocupadas. La respuesta final importa menos de lo que cree la mayoría, y el camino hasta ella importa mucho más.
Qué está puntuando realmente el entrevistador
Casi todas las rúbricas se reducen a cuatro líneas: ¿entendiste el problema antes de resolverlo?, ¿es razonable tu enfoque y dijiste por qué?, ¿sabes escribir código que funcione sin que te lleven de la mano?, y ¿sabes explicar el compromiso cuando te preguntan? Fíjate en que solo una de las cuatro va sobre el código.
Por eso también una solución perfecta y silenciosa puntúa peor que una decente y narrada. El entrevistador solo puede calificar lo que le llega, y mientras piensas no le llega nada.
Los dos primeros minutos deciden más de lo que deberían
El instinto es empezar a teclear, porque teclear parece progreso y el silencio sale caro. Es el instinto equivocado. Dedica la apertura a reformular el problema con tus palabras, a hacer la una o dos preguntas que de verdad cambian la solución —tamaño de la entrada, si viene ordenada, duplicados, si puedes mutarla— y a enunciar el enfoque que piensas seguir con su complejidad.
Eso cuesta noventa segundos y compra tres cosas: resuelves el problema correcto, el entrevistador recibe una señal positiva temprana, y tienes un plan al que volver cuando te pierdas más adelante. Quien se lo salta es quien descubre en el minuto veinte que el array ya venía ordenado.
El blanco
A veces no se te ocurre nada. La salida fiable es decir en voz alta la solución más tonta posible: «La fuerza bruta es comprobar todos los pares, que es cuadrática. Empiezo por ahí y luego busco qué se repite.» Eso no es admitir una derrota: es lo que el entrevistador espera oír, porque optimizar una línea base enunciada es un proceso visible y calificable, y enunciar la línea base suele revelar la mejora.
La segunda salida es un ejemplo pequeño y concreto. Coge una entrada de cuatro elementos, resuélvela a mano, di qué estás haciendo. El patrón que necesitas suele verse en el ejemplo y no verse en abstracto.
Minuto quince: darte cuenta de que el enfoque es malo
Parece el final de la entrevista. Bien gestionado, es una de las señales más fuertes que puedes mandar: detectar tu propio error antes de que alguien lo señale es exactamente en qué consiste el trabajo.
Dilo de forma explícita y barata: «Esto no va a funcionar: en cuanto haya duplicados mi índice se rompe. Quiero cambiar a un mapa indexado por valor.» No sigas parcheando en silencio un enfoque muerto esperando que se recupere; los entrevistadores ven eso y lo leen como incapacidad de reevaluar. Y no te disculpes largamente. Una frase que nombra el fallo, otra que nombra el reemplazo, y a seguir.
El bug que no ves
Bajo presión la gente relee las mismas cinco líneas esperando un resultado distinto. Rompe el bucle de forma mecánica: imprime el estado en el punto que crees correcto y comprueba si de verdad lo es. Casi todos los bugs de entrevista son un desfase de uno, un valor inicial equivocado o una comparación al revés, y los tres se ven en cuanto imprimes la estructura intermedia en lugar de razonar sobre ella.
Narra la depuración. «Espero que este mapa tenga tres entradas en este punto, lo confirmo.» Depurar en voz alta es una señal positiva por sí misma; mirar fijamente en silencio no lo es.
El silencio es el verdadero modo de fallo
El entrevistador rellena una rúbrica que solo puede rellenar con lo que le llega. Treinta segundos de reflexión están bien si los etiquetas —«dame un momento para pensar la estructura de datos»— y salen caros si no, porque el silencio sin etiquetar se anota como atascado. Es el hábito más barato de esta lista y el que más consistentemente falta en los candidatos rechazados.
Por qué un atajo de teclado no funciona en una ronda en directo
La mayoría de herramientas de entrevista en tiempo real van con un atajo: oyes la pregunta, pulsas algo, recibes una respuesta. Ese modelo asume en silencio que tienes las manos libres. En una ronda de live coding no las tienes: estás tecleando, el entrevistador mira tu editor, y ese medio segundo en que vas a por el atajo se nota de un modo en que nunca se nota en una llamada conversacional.
Esta es la ronda en la que la asistencia o funciona sola o no funciona. Interview Copilot responde automáticamente a cada pregunta completada, sin tecla que pulsar: capta al entrevistador por el audio de la llamada, decide que la pregunta ha terminado y pone la estructura de la respuesta en tu pantalla mientras sigues tecleando. No un guion para leer: el mecanismo, el compromiso y el número que vale la pena decir en voz alta.
Dónde ayuda la asistencia en directo y dónde se vuelve en tu contra
Las herramientas en tiempo real son genuinamente útiles para un conjunto estrecho de cosas: recuperar una pregunta que oíste a medias, recordar una firma de librería que conoces pero no te sale, o dar con la terminología cuando la ronda no es en tu primer idioma. Son problemas de recuperación, y recuperar bajo estrés es un impuesto real e injusto que no tiene nada que ver con la capacidad de ingeniería.
Se vuelve en tu contra con respuestas que no puedes defender. Todo entrevistador repregunta —por qué esa estructura, qué pasa si la entrada se duplica, qué se rompe con duplicados— y la repregunta apunta justo a lo que acabas de decir. Soltar una respuesta pulida y luego fallar su repregunta es peor resultado que una respuesta más lenta que dominas por completo, porque convierte una señal dudosa en un no rotundo.
La línea utilizable es simple. Usa la ayuda para entender y para recordar. El razonamiento hazlo tú, con tus palabras, en voz alta, porque es lo único que se está puntuando.
FAQ
¿Qué es una entrevista de live coding?
Una ronda en la que escribes código en un editor compartido mientras el entrevistador mira y pregunta en tiempo real, normalmente de treinta a sesenta minutos. A diferencia de una prueba para casa, mide cómo llegas a la respuesta: las preguntas que haces, el enfoque que eliges y si sabes explicarlo mientras tecleas.
¿Cuánto dura una entrevista de live coding?
Normalmente cuarenta y cinco minutos: unos minutos de preparación, un problema principal y cinco o diez minutos para tus preguntas al final. Algunas empresas plantean dos problemas cortos en lugar de uno largo.
¿Puedo ejecutar y probar mi código durante una entrevista de live coding?
En CoderPad, CodeSignal y HackerRank normalmente sí, y deberías: ejecutar es más rápido que discutir con el código en tu cabeza. Pregunta primero si el entrevistador no lo ha dicho; algunos lo desactivan a propósito para ver si razonas sobre la corrección sin un runtime.
¿Qué debo hacer en los dos primeros minutos?
Reformula el problema en una frase, pregunta por el tamaño de la entrada y los casos límite, y di qué enfoque vas a intentar. Esa secuencia fija el objetivo de complejidad, saca a la luz los malentendidos cuando aún son baratos y le da al entrevistador algo que calificar antes de que exista código.
¿Qué hago si me quedo en blanco?
Di lo que estás pensando en vez de callarte: describe la versión por fuerza bruta en voz alta y después busca qué hay de derrochador en ella. Los entrevistadores puntúan el razonamiento que pueden oír; un candidato callado que acaba escribiendo código perfecto suele puntuar menos que otro que narró un camino más lento.
¿Es aceptable cambiar de enfoque a mitad?
Sí, y decirlo explícitamente es mejor que parchear en silencio un diseño roto. «Esto se está volviendo cuadrático y las restricciones sugieren que quieren lineal, voy a reestructurar con un hash map» se lee como criterio de ingeniería. Reescribir en silencio se lee como confusión.
¿Puedo buscar cosas durante la entrevista?
Normalmente sí para sintaxis y detalles de la librería estándar; pregunta antes. Lo que se evalúa es si sabes descomponer un problema y razonar sobre compromisos, no si memorizaste la firma de un método.