Las entrevistas de live coding solo miden el estrés, no la habilidad para programar

• Las entrevistas de live coding en realidad miden mejor la respuesta al estrés que la capacidad de programar de un ingeniero
• Según estudios científicos, en un entorno donde alguien observa en tiempo real aparecen deterioro cognitivo y grandes variaciones en el rendimiento
• En particular, en el caso de las candidatas, se observó incluso que en un entorno público todas fueron rechazadas, mientras que en un entorno privado todas aprobaron
• En la mayoría de las empresas no se exige adaptarse al estrés, pero aun así se evalúa erróneamente eso mediante una prueba de código
• Los simulacros, la exposición gradual y ciertos suplementos nutricionales pueden ayudar a aliviar el estrés

---

Experiencia personal con las entrevistas de live coding

• A algunas personas les gustan las entrevistas de live coding, pero al autor no
• Durante su proceso de postulación a Toptal, falló en la prueba de live coding, pero al resolverla de nuevo por su cuenta la completó rápidamente
• Esa experiencia le hizo darse cuenta de que bajo supervisión en tiempo real no podía rendir según su capacidad real por el estrés

El cerebro bajo estrés

• En situaciones de alto riesgo y presión de tiempo, se activa la amígdala y suben los niveles de cortisol
• Como resultado, se deteriora la función de la corteza prefrontal, encargada del razonamiento complejo y la memoria
• La memoria de trabajo es el indicador más importante para evaluar la capacidad de resolver problemas nuevos, y en situaciones de programación en vivo disminuye de forma considerable
• Incluso con una ansiedad de rendimiento leve, pensar con claridad puede volverse casi imposible
• Cuesta concentrarse, no se pueden recordar varios pasos a la vez y uno siente que es “mucho peor de lo normal”

Hallazgos clave de la investigación

• Un estudio realizado por investigadores de Microsoft comparó cómo se resolvía el mismo problema de programación en un entorno privado y uno público
• En el entorno privado, la persona trabajaba sola en una habitación; en el público, resolvía el problema frente a un supervisor mientras verbalizaba su proceso de pensamiento
• Como resultado, el rendimiento se redujo a la mitad cuando había observación, y además la variación entre resultados fue mucho mayor
• A diferencia de los candidatos hombres, todas las candidatas del entorno público reprobaron, mientras que en el entorno privado todas aprobaron
• El entorno de live coding funciona como un filtro de exclusión científicamente demostrado que deja fuera a ingenieros competentes

La realidad del rendimiento bajo estrés

• Al final, el live coding no es más que una medida indirecta del desempeño bajo estrés
• Algunas empresas realmente buscan personas que rindan bien en entornos estresantes, pero la mayoría no lo deja claro en sus vacantes
• Considerando que la mayor parte del trabajo real implica poco estrés en tiempo real, descartar a un gran ingeniero solo porque cometió errores en live coding es inapropiado
• Es razonable decir que el live coding mide más los niveles de hormonas del estrés que la habilidad de programar

Formas de reducir el estrés

• Como el live coding es común en la industria, hace falta entrenamiento para adaptarse al estrés
• Practicar repetidamente en entornos parecidos a los reales (Pramp, Interviewing.io, simulacros de LeetCode, etc.) puede ayudar al cerebro a acostumbrarse al estrés
• También funciona subir la presión poco a poco: poner temporizador, grabarse o pedirle a un amigo que observe
• Además, se puede probar con suplementos como L-tyrosine (para reponer neurotransmisores bajo estrés) y L-theanine (para mejorar relajación y concentración)
• Antes de una entrevista real, hay que comprobar en simulacros qué método funciona mejor para cada persona

Conclusión

• Ser malo en live coding no significa carecer de aptitud como ingeniero, sino reflejar una característica humana común

[GN⁺]

Opinión de Hacker News

• No pretendo generalizar mi caso, pero quiero compartir mi experiencia personal. Ahora soy un indie developer autónomo y exitoso. Una de las principales razones por las que no abandoné el desarrollo indie ni siquiera en los tiempos difíciles fue que, en la práctica, me había vuelto casi imposible conseguir empleo. Soy una persona de mediana edad en una industria tecnológica con fuerte discriminación por edad, no tengo título en ciencias de la computación y en las entrevistas de live coding se me pone la mente en blanco. Quiero señalar que no todo el estrés es igual. Los bomberos se meten a edificios en llamas, pero aun así pueden sentir terror al hablar frente a desconocidos. Yo también tolero bien el estrés del trabajo diario, pero me resulta insoportable que alguien me observe por encima del hombro mientras decide mi futuro financiero. Después de la entrevista, muchas veces sí logro resolver el problema de código. Tal vez los entrevistadores crean que soy un fraude, pero casi 20 años de trayectoria dicen lo contrario. Mucha gente parece tratar los "false negatives" como si fueran algo aleatorio, pero hay personas como yo que quedan fuera siempre. Siempre fracaso en entrevistas estilo audición; no soy alguien que se desempeñe sobre un escenario.

  • Me identifico muchísimo con eso de ser evaluado mientras otros te observan. Tengo poco más de 60 años. En mis 20 y 30 me iba más o menos bien en entrevistas, pero con el tiempo sentí que el proceso se volvió cada vez más confrontativo. Antes la sensación era de "vamos a ver cómo te contratamos"; ahora parece más bien "vamos a encontrar una razón para no contratarte". Puede ser por discriminación por edad, pero también creo que cambió el ambiente de la industria. En los últimos 15 años, mis experiencias de entrevista se volvieron cada vez más desagradables, e incluso llegué a sufrir pánico durante algunas. Aun así, de alguna manera sí conseguí trabajo, y gracias a referencias también hice contratos sin entrevista. La última startup en la que estuve se quedó sin financiamiento a finales de 2022 y decidí retirarme. Me encantaba el trabajo y seguía usando tecnología moderna, pero sobre todo ya no podía soportar más entrevistas.

  • Creo que el problema es la estructura misma. Las entrevistas de programación recientes parecen diseñadas para verificar si gente joven hizo tareas de estructuras de datos en CS. Tal vez eso tenía sentido en empresas de contratación masiva tipo FAANG en los 2010, pero en compañías pequeñas o medianas sería mucho mejor enfocarse en situaciones reales de trabajo, como leer código o discutir edge cases. Llevo más de 20 años trabajando en startups y aun así sigo sin pasar estas pruebas. También me niego a memorizar cosas a la fuerza. Si ese tipo de empresa no encaja conmigo, entonces mejor que no se dé. He sido CTO, lancé varias empresas y gestioné equipos bien, pero aun así me tratan como si fuera junior. Una vez me rechazaron por no poder implementar un caché LRU de forma rápida y limpia, y me pregunto qué tan necesario es eso hoy en una startup. Ni siquiera lo he usado recientemente. Puede que por no resolver ese tipo de problema al instante parezca incompetente, pero no entiendo qué sentido tiene evaluar cosas que no se usan en el trabajo real. Es como contratar a un arquitecto por su habilidad con una regla de cálculo. Esta forma de contratar termina produciendo bases de código complejas, cuando lo realmente importante debería ser cumplir objetivos de negocio, no maximizar la complejidad. Yo quiero trabajar con colegas que descompongan problemas y mantengan la lógica y la estructura simples. Elegir gente inteligente con leetcode tiene sus ventajas, pero es mejor quien resuelve problemas reales de manera constante y efectiva.

  • He vivido esta situación desde el lado de quien contrata. Hice una entrevista telefónica a un estudiante que había participado mucho tiempo en el proyecto, y me pareció que por varias formas de estrés y por la barrera del idioma no estaba logrando mostrar bien su capacidad. Estaba dispuesto a cambiar el formato, pero la persona candidata decidió por sí misma que ya no quería seguir intentando. Ahora bien, si cambias a una entrevista de programación asíncrona, puede que al final solo estés midiendo si usó un LLM o no. Si al final hay que elegir entre filtrar gente que se congela en entrevistas o filtrar farsantes totalmente incompetentes, yo preferiría filtrar a los primeros.

  • He visto mucho este desajuste de personalidad en empresas. Muchos programadores son introvertidos, pero quienes contratan suelen ser extrovertidos. Si esa diferencia no se maneja bien, el talento introvertido termina excluido o incomprendido. Los espacios abiertos y de asientos compartidos tienen un problema parecido. A los managers les gusta la colaboración, pero para la gente introvertida puede ser un entorno muy duro.

  • Me da curiosidad saber cómo empezaste a tener éxito como desarrollador indie. Yo también estoy cerca de los 40 y programé como hobby durante mucho tiempo, pero desde el año pasado decidí tomarlo en serio como profesión. Tengo muchos proyectos públicos en GitHub, bastante experiencia de éxito en otros campos y no se me da mal comunicarme. Pero me cuesta mucho el live coding. Me interesa saber qué piensas de una ruta de contribución independiente donde uno pueda demostrar su capacidad real. Si de verdad tengo habilidad, me gustaría cobrar por eso.

• Esta semana entrevisté a una persona candidata para Data Engineering. Le di cuatro sentencias SQL muy básicas y leyó los problemas en voz alta para luego dar inmediatamente la respuesta con sintaxis correcta. La última subía un poco la dificultad y ahí se atoró. Le dije "verifica el resultado" y no entendió, además de ponerse a la defensiva. Luego le dije "haz un dump de la tabla" y tampoco entendió en absoluto; solo puso excusas. Al final, en el SQL que pegó aparecía [redacted].ai en la salida. Seguramente resolvió las primeras con IA, y en la última se le notó. Si no hubiera habido una prueba técnica, no habríamos detectado la trampa.

  • Las herramientas de trampa con IA para entrevistas están muy extendidas entre la gente joven. A veces se detecta al instante, pero candidatos con más experiencia ocultan mejor el uso de IA y tapan huecos con cosas como "no te escucho" y similares. En el grupo de managers al que pertenezco, este es el tema de contratación más discutido últimamente. Las empresas que pueden permitírselo hacen la última entrevista de forma presencial. En pantalla remota algunas personas parecen aceptables, pero al verlas en persona ni siquiera responden preguntas básicas y al final son rechazadas. Es un desperdicio de tiempo y dinero, pero consideran que sigue siendo mejor que el costo de una mala contratación. El uso de IA no se limita a entrevistas técnicas; también está por todos lados en currículums, preguntas conductuales e incluso respuestas en formato S.T.A.R. generadas por ChatGPT. Verificar referencias confiables es más importante que nunca. Ya me pasó varias veces que lo que dice un exjefe sobre el trabajo de alguien no coincide en nada con lo que aparece en su CV. Si desde el principio esa persona hubiera admitido que no tenía experiencia directa en nuestro dominio, quizá la habríamos contratado, pero cuando la mentira es tan evidente ya no inspira ninguna confianza.

  • Entrevistando candidatos últimamente, alrededor del 50% usó GenAI en vivo en tiempo real. Hasta ahora, detectar quién usa IA ha sido muy fácil. Se nota enseguida en una conversación natural. Irónicamente, el último candidato también repetía siempre el problema y luego se quedaba esperando entre 10 y 15 segundos. Eso demuestra que este tipo de prueba no resuelve el problema de fondo. Más bien crea otro nuevo y hace que descartes candidatos excelentes.

  • ¿Y si usar IA no fuera hacer trampa, sino adelantar lo que la persona haría en el trabajo real? Desde esa perspectiva, esa entrevista fue en realidad un ejemplo muy efectivo y a pequeña escala de <i>interpretación de requisitos</i>. Creo que sería más positivo permitir libremente las herramientas que se usan en el trabajo y, dentro de ese contexto, evaluar la comprensión real del puesto y del lenguaje. La exigencia no debería ser solo abandonar LeetCode, sino encontrar un método mejor.

• Al final, todo depende del contexto. Lo mismo aplica a las entrevistas de live coding. No son la mejor experiencia para quien postula, pero en empresas grandes como Meta o Google reducen mejor la tasa de false positives que otros métodos. Aun así, muchas veces quienes entrevistan no están lo bastante capacitados y los problemas tienden a parecer acertijos, así que si no practicaste mucho LeetCode o no vienes de la academia o de graduarte hace poco, se vuelve muy difícil. Trabajé seis años en assessment y vi de primera mano muchos procesos de contratación, desde Fortune 10 hasta startups. Suelo recomendar evaluaciones parecidas al trabajo real y ya no me gusta esa idea de llamar "trabajo real" a algo que bordea el unpaid labor. La evaluación debería servir para que la empresa pueda ofrecer con tranquilidad un salario alto. Con la llegada de la IA, incluso las tareas cortas para llevar a casa se volvieron difíciles de mantener justas. Por eso algunas empresas están volviendo a métodos extremos como entrevistas on-site y supervisión en tiempo real. Para mí, la solución perfecta sería dar a todas las personas candidatas el mismo tiempo, entorno y herramientas para mostrar su mejor nivel. Sigo pensando mucho en esto, pero todavía no encuentro la respuesta.

  • Se dice mucho que "funciona bien a nivel Meta o Google", pero en realidad no hay datos. He trabajado con desarrolladores de nivel F salidos de Facebook y Google. En la práctica, estas grandes empresas igualmente despiden entre 3% y 5% de su personal, y eso demuestra que las entrevistas por sí solas no logran filtrar bien los false positives. Considero que una tasa de error del 3% es demasiado alta para el tiempo que invierten quienes entrevistan. En esencia, no es tan distinto del viejo nivel de FizzBuzz.

  • Es como si a un albañil no le pidieras construir una pared, sino que solo verificas su certificación y lo contratas de inmediato. Muchas profesiones funcionan así. Si luego no da el ancho, lo despides después de contratarlo. No hace falta pasar por procesos humillantes de entrevista corporativa.

  • Los mejores ingenieros que he visto muchas veces terminan clasificados como false negatives. Se ponen nerviosos en entrevistas de live coding y no logran mostrar lo que saben. No creo que se pueda afirmar tan tajantemente que este tipo de entrevistas "funciona bien".

  • Decir "depende del contexto" y luego afirmar que "las entrevistas de live coding funcionan" es contradictorio. Del mismo modo, yo podría decir "depende del contexto, pero las entrevistas de live coding no sirven". No hay diferencia lógica.

  • Pasar leet-code sí puede servir para filtrar gente que de verdad no sabe resolver problemas. La solución ideal es dar a cada candidato un entorno donde pueda rendir al máximo con sus propias herramientas. Pero, en la práctica, a veces pienso que lo más justo sería hacer leetcode presencial, en un pizarrón y con pair programming junto a quien entrevista. Eso sí sería un entorno realmente cómodo.

• Creo que ambas explicaciones pueden ser ciertas al mismo tiempo. Sí existen desarrolladores "senior" que en realidad no saben trabajar, y el live coding ayuda a filtrarlos. Pero también hay personas que fracasan en entrevistas por razones totalmente distintas.

  • También hay muchos desarrolladores que hacen bien live coding, pero carecen de experiencia en diseño de sistemas a gran escala. Ese tipo de gente suele introducir deuda técnica, anti-patterns e inconsistencias que empeoran aún más la base de código. En realidad, son justo el tipo que hay que evitar. Las empresas creen que sus seniors actuales controlarán a la gente junior, pero como en cualquier empresa todos dicen que "nuestra base de código es basura", esa medida tampoco parece muy efectiva.

  • Si simplemente dejaras que la gente se siente sola en un cuarto a programar, no perderías talento excelente que solo rinde mal en entornos anormales.

  • Últimamente el live coding ya no es solo una prueba simple de programación; exige memorizar muchos algoritmos y combinar dos o tres en 30 minutos para resolver un problema. Uno termina gastando todo el tiempo en resolver el rompecabezas y ni siquiera queda espacio para mostrar capacidad real de programar.

  • En 20 años de trabajo profesional nunca me tocó trabajar con uno de esos supuestos "seniors incompetentes". Con un currículum y una charla de 15 minutos bastaba para filtrarlos. En cambio, sí vi mucha más gente que pasó entrevistas de pizarrón y luego afectó negativamente la productividad del equipo.

  • No entiendo por qué sería indispensable un entorno con límite de tiempo y con una persona obligada a pensar y explicar al mismo tiempo frente a un pizarrón. Si el objetivo es filtrar a quienes no pueden hacer el trabajo real, no hace falta llegar a ese extremo.

• A mi parecer, la única forma de comprobar de verdad si alguien puede desempeñar un puesto es hacer que lo desempeñe. Incluso si existiera una evaluación alternativa, si puedes hacer que haga el trabajo real no veo por qué usar otra cosa. Si el trabajo de la empresa es tan complejo que ni siquiera se puede separar una parte para usarla en entrevista, entonces probablemente la empresa está haciendo cosas innecesariamente complejas. Por ejemplo, si necesitas saber si alguien puede levantar 10 kilos, haz que levante una carga real de 10 kilos. En cambio, aquí hacen algo tipo "vamos a evaluar tu fuerza, así que bájate los pantalones y levanta una cubeta de 1 kg con los glúteos". Al final, solo deberías evaluar las habilidades realmente necesarias para el trabajo. Si buscas a un chef, que cocine en una cocina real. Si buscas personal de atención, observa cómo se comunica en una situación simulada. Y en un filtro telefónico también podrías mostrar una pantalla en tiempo real.

  • Hay quien responde: "si les haces hacer trabajo real en la entrevista, ¿no aparecen problemas de trampa o de explotación laboral?". Si la empresa reutiliza el trabajo de la prueba, podría haber incluso problemas legales.

  • También existe la propuesta de contratar directamente por un día, una semana o un mes, y si encaja entonces ofrecer empleo permanente. Eso sí, ese modelo no encaja bien con el sistema estadounidense de employer healthcare.

  • Desde el punto de vista de la empresa, consume demasiado tiempo. Por eso usan proxies sesgados más hacia el false negative que hacia el false positive.

  • Me interesa saber qué opinan sobre la preocupación de que pedir trabajo real en una entrevista sea en el fondo exigir free labor.

  • Como adaptarse a una organización nueva toma tiempo, probar con trabajo real podría ser incluso menos eficiente. Puede que una evaluación de live coding mida mejor comunicación, resolución de problemas y habilidad pura para programar.

• Desde que tuve hijos, mi capacidad para programar en entrevistas cayó muchísimo. Antes jamás me pasaba esto, pero ahora siento que hay demasiado en juego. Pienso en el seguro médico, la hipoteca, la jubilación y la presión se vuelve enorme. Durante la entrevista me bloqueo por completo, y es doloroso que la solución se me ocurra apenas termina. Cuanto más tiempo dedico a practicar, peor siento que rindo. Además, por tener personas que dependen de mí, practicar más me genera culpa. El efecto de aprendizaje es bajo y más bien me hace encogerme todavía más. Lo que sentí trabajando en big tech es que este formato de entrevista se implementó con la idea de "evaluar a todos por igual", pero en la práctica no refleja en absoluto cómo cambian o se desequilibran las circunstancias de cada persona. Incluso colegas muy resistentes al estrés pueden cambiar unos años después. Se supone que empezó para eliminar sesgos, pero creo que ya es momento de cambiar el método.

  • No eres la única persona que se siente así. Con la edad baja la velocidad de aprendizaje y también el tiempo libre, así que practicar leetcode se vuelve menos eficiente. Molesta ver que al final terminan siendo recompensadas simplemente las personas que tienen más tiempo disponible.

  • Recomiendo probar cosas como meditación, respiración, L-Theanine o beta bloqueadores para reducir el estrés. También sugiero monitorear frecuencia cardiaca y presión arterial con un smartwatch. De verdad puede ayudar a romper el círculo vicioso del estrés.

• Es un entorno de estrés muy intenso, cualitativamente distinto al estrés del trabajo real. Para compartir mi experiencia en una entrevista de Google: yo fui la persona que creó el primer motor de búsqueda local de los Países Bajos, y en Google un entrevistador con sombrero vaquero me pidió escribir binary search en un pizarrón con marcador. Yo casi nunca escribo a mano, solo uso teclado, y además ni siquiera quisieron mirar mi experiencia diseñando índices de búsqueda. Capaz Google en realidad estaba buscando una mentalidad de "cowboy".

  • A mí también me convenció en su momento un reclutador de Google para entrevistarme, pero la calidad de quienes me entrevistaron fue tan mala que, incluso después de saltarme la entrevista técnica, desde entonces rechazo cualquier propuesta de Google. La mayoría de las preguntas eran del estilo "te atrapé" o sobre estructuras antiquísimas de UNIX sin relación con la realidad, como los inode. No tenían ninguna relación con el puesto. Las empresas necesitan sí o sí procesos para hacer seguimiento a las preguntas, recoger feedback y capacitar a quienes entrevistan. Aún hay demasiadas compañías donde las preguntas dependen del gusto personal de cada entrevistador.

  • En realidad, esta estructura sí funcionó exactamente como estaba pensada. Este tipo de empresas quiere gente capaz de soportar cualquier humillación por parte de la empresa. Como no había fit, en cierto sentido ambos lados salieron ganando.

  • Si te pareció humillante que te pidieran hacer binary search, quizá es porque tu ego es demasiado grande.

  • Si estuvieran en juego 250 mil dólares al año más stock options adicionales de Google, con gusto aguantaría una "humillación" por un día.

• Yo trato el live coding screening como una "conversación sobre código". Dejo claro a la persona candidata que el objetivo de la entrevista es verificar si podemos comunicarnos bien entre nosotros. No basta con ser técnicamente fuerte; también hay que poder colaborar. Por ejemplo, si durante la conversación implementa algo mal por un malentendido, o si por muy bien que escriba código no puede sostener una conversación técnica, eso ya es un problema. Por eso las preguntas tipo FizzBuzz son importantes: no solo prueban habilidad, también ponen a prueba la capacidad de tener una discusión técnica.

  • Exacto. La esencia de una entrevista de live coding no es "si puede resolver el problema", sino "si puede explicar cómo lo resolvería". Lo central es una base técnica mínima junto con capacidad de comunicación. Una parte considerable del trabajo real consiste en explicarle cosas a managers no técnicos, así que puedes verlo como una prueba de eso.

  • Me gusta este enfoque. Yo puedo resolver FizzBuzz de al menos 3 lenguajes y de 4 maneras distintas, y tengo confianza en poder explicar las 12.

• Yo también reconozco este problema y coincido en que no hay una alternativa perfecta. A lo largo de mi carrera vi varias veces a personas que "hablan y se comportan como ingenieros" pero en realidad no saben programar. Muchas veces me arrepentí de haber ignorado la capacidad de código en entrevistas. También me gustaría que la gente joven entendiera que varias etapas del proceso de contratación tienden a favorecer más a postulantes mayores. Sé que en la industria abundan ingenieros sin capacidad real de programar que se escudan en una imagen inútil de "experto". Contratar sin haber visto ni una sola vez cómo alguien programa es como contratar al guitarrista de una banda solo por su CV, la conversación y referencias. Incluso alguien que nunca tocó guitarra podría conseguir el puesto de "experto en guitarra". De verdad existen personas que pasan así, sin ninguna credencial especial. Si en una entrevista no tienes evidencia directa y solo te queda especular, inevitablemente terminan entrando sesgos y prejuicios.

  • Sobre eso de "hay problemas pero no hay alternativa", existe un sistema basado en certificaciones, como con médicos y abogados. A nadie le piden hacer una cirugía de demostración antes de operar. Y el riesgo ahí es mucho mayor. En realidad, los procesos de verificación más duros suelen recaer en puestos de menor nivel, mientras que managers y cargos altos, con más impacto real, pasan con mucha más facilidad.

  • Yo creo que hacer que escriban pseudocode en un pizarrón sería mejor. Reduce el estrés por sintaxis y permite ver mejor la lógica de resolución. Además, encaja bien con mi forma de colaborar, que es intercambiar ideas juntos en un pizarrón.

• El fenómeno de que "el estrés es independiente de la capacidad" aparece una y otra vez. Incluso el paper de Microsoft fue espantoso. La mayoría de los consejos son del tipo "solo resuelve mucho LeetCode", pero ignoran el estrés, es decir, el cortisol. Yo practico para acostumbrarme al entorno de estrés mismo. Mis amistades no pueden entrenarme con suficiente intensidad y un coach cobra demasiado por hora. Por eso ahora estoy desarrollando un side project llamado Tough Tongue AI. Ofrece preguntas en tiempo real, interrupciones y feedback inmediato dentro de un editor de código en vivo con respuestas por voz. Este entrenamiento me va acostumbrando poco a poco a esa tensión de "alguien me está observando". Si las entrevistas de live coding van a seguir existiendo, además de algoritmos necesitamos formas de entrenar la respuesta fisiológica al estrés.

  • Es una de las mejores herramientas de aprendizaje.