Programar bajo Presión: Cuando las entrevistas técnicas fallan

Hoy, scrolleando en mi timeline de X (Twitter), me encontré con este curioso post de Ed Andersen (@edandersen), desarrollador y creador de contenido en Youtube: Link al tweet

Esto me dejó pensando. En el mismo post, Ed se preguntaba si este tipo de pruebas realmente funcionan, si los candidatos apuestan a que no serán entrevistados por alguien técnico.

Disclaimer: este blog busca abrir un debate, no descalificar la opinión de Ed Andersen. No fui testigo de esa entrevista, solo reflexiono a partir de su publicación.

La pregunta que me hago no es si el candidato mintió o no. La pregunta real es: ¿es justo medir a un desarrollador solo por escribir un bucle, o cualquier fragmento de código, bajo presión?

Hace poco pasé por algo parecido. Apliqué a una empresa para un rol de Software Engineer. Primero recibí un assignment: desarrollar una solución completa para mostrar datos de un API y crear recomendaciones. Me tomó varios días, incluso con la sugerencia de usar IA.

Luego vino la entrevista técnica con ingenieros de la empresa. Y pasó lo de siempre: la ansiedad se apoderó de mí. Me pidieron algo simple —hacer una petición—, algo que he hecho miles de veces en 13 años de experiencia… y me quedé en blanco. Tuve que recurrir a la documentación.

No sé si ese momento fue decisivo pero al final recibí la negativa. Y esa voz interior apareció: “¿De qué sirvieron todos estos años de experiencia si una simple entrevista puede hacerme dudar de mí mismo?”.

Y vuelvo a la misma pregunta: ¿qué tan justo es poner en duda toda una carrera porque los nervios nos juegan una mala pasada?

La presión como filtro invisible

No soy el único que lo ha sentido. En 2020, investigadores de la Universidad Estatal de Carolina del Norte y Microsoft hicieron un experimento: compararon a candidatos resolviendo un problema de programación en privado versus hacerlo en una entrevista tradicional, en pizarra y bajo la mirada de un entrevistador. El resultado fue claro: los candidatos bajo presión rindieron casi la mitad de lo que podían dar en privado.

Y lo más interesante: cuando les preguntaron cómo se sentían, muchos dijeron exactamente lo que yo sentí: nervios, presión, mente en blanco. En otras palabras, la entrevista técnica no estaba midiendo tanto su habilidad para resolver problemas como su capacidad de lidiar con la ansiedad.

Algo parecido encontraron otros estudios: candidatos que se muestran nerviosos suelen recibir peores evaluaciones, aunque respondan correctamente. Es decir, el nerviosismo “ensucia” la percepción de competencia del entrevistador, incluso si el contenido de la respuesta es válido.

Casos de talento desaprovechado por nervios

Aquí es donde todo se vuelve más serio. En el mismo estudio de NC State y Microsoft, ocurrió algo llamativo: todas las mujeres participantes que hicieron la entrevista en público reprobaron la prueba, mientras que todas las que la hicieron en privado aprobaron. La muestra era pequeña, pero el resultado es un golpe de realidad. La presión y el formato afectan distinto según el grupo, y eso significa que podríamos estar descartando talento valioso por un simple tema de ansiedad.

También he leído historias de desarrolladores con experiencia reconocida —personas que han creado librerías usadas por miles— que fallan entrevistas en grandes compañías porque, frente a la pizarra, olvidaron cómo invertir un árbol binario o escribir un bucle sencillo. La ironía es que esas mismas personas ya habían demostrado en la vida real que podían crear software complejo y útil, pero el formato de la entrevista no supo medirlo.

¿Qué estamos midiendo en realidad?

Esto abre un debate incómodo. Si las entrevistas técnicas buscan encontrar a los mejores desarrolladores, ¿por qué seguimos confiando en un formato que se parece más a una prueba de estrés que a un día de trabajo real?

Porque en el trabajo real no estamos en una pizarra con alguien observando cada tecla. Programamos con nuestro editor, con documentación, con Stack Overflow abierto y, sobre todo, en equipo. Equivocarse y corregir forma parte del proceso.

Sin embargo, en muchas entrevistas se espera precisión inmediata, como si olvidar la sintaxis exacta de un foreach invalidara toda tu experiencia. Y lo preocupante es que la ciencia ya confirmó lo que muchos sentimos: estas entrevistas están filtrando más la tolerancia a la presión que la verdadera capacidad técnica.

De hecho, los investigadores compararon las entrevistas en pizarra con una prueba clínica de inducción de estrés usada en psicología para generar ansiedad. Lo que significa que, sin querer, la industria tecnológica diseñó un método que mide más los nervios que las ideas.

Métodos alternativos de evaluación que reducen la presión

La buena noticia es que hay alternativas. Algunas compañías y expertos ya están experimentando con procesos más humanos y realistas:

Pruebas en privado: dejar que el candidato resuelva un problema en su entorno, sin alguien observando cada tecla. Luego se revisa la solución y se le pide que explique su razonamiento. Esto reduce la ansiedad y permite evaluar la lógica más que los nervios.
Assignments cortos y realistas: en vez de acertijos de pizarra, dar ejercicios prácticos alineados al trabajo real. Algo que no tome una semana de esfuerzo, sino unas horas, y que se evalúe por la calidad del código, no por la rapidez con que lo escribió.
Pair programming: entrevistar como si fuera una sesión de colaboración. En vez de un jurado, el entrevistador se convierte en un compañero de trabajo momentáneo. Esto baja la tensión y muestra cómo el candidato piensa en voz alta, resuelve y se comunica.
Segundas oportunidades: permitir que el candidato reformule o intente de nuevo si se bloquea. Porque seamos sinceros: ¿cuántas veces en el trabajo real solucionamos algo a la primera, sin errores ni dudas?

Conclusiones

Las entrevistas técnicas son necesarias, pero el formato tradicional está roto. En lugar de medir cómo resolvemos problemas, mide cómo respondemos al estrés artificial. Y en esa confusión, la industria puede estar desperdiciando talento que sí sabe programar, pero no sabe rendir un show bajo presión.

Un buen proceso de selección debería imitar la vida real: acceso a documentación, colaboración en equipo, espacio para equivocarse y corregir. Eso es lo que hacemos todos los días los desarrolladores.

Porque al final, lo que debería importar no es si recuerdas de memoria la sintaxis de un foreach, sino si puedes transformar ideas en software útil y sostenible.

Sugerencias para candidatos/entrevistadores

Si eres candidato, practica entrevistarte sin nadie observando, escribe tus miedos antes de la entrevista y simula presión.

Si eres reclutador o empresa, considera implementar evaluaciones colaborativas y menos estresantes, como pair programming o trabajos contextuales.