La relación amor-odio con las entrevistas de código: por qué la velocidad le está ganando a la calidad

Las entrevistas de código siempre han sido controversiales. Para algunos desarrolladores son un reto divertido, una forma de mostrar habilidades de resolución de problemas bajo presión. Para otros, son una fuente de frustración — una prueba que se siente más como un concurso de televisión que como un reflejo del trabajo real que hacemos.

He estado en ambos lados. Hace años, recuerdo que me pidieron resolver problemas de árboles binarios. Tenía siglos sin tocar algo así, y no podía dejar de pensar: ¿cuándo fue la última vez que alguien en esta empresa invirtió un árbol binario como parte de su trabajo diario? Otra vez me pidieron construir un sistema de colas de mensajes usando child processes. ¿Lo irónico? Todas las empresas en las que he trabajado ya dependían de plataformas establecidas como RabbitMQ, Kafka o Azure Service Bus. No estaba resolviendo un problema — estaba fingiendo que las herramientas que usamos en la vida real no existían.

En otra entrevista no me dejaron usar IntelliSense ni consultar documentación. Tuve que programar como si estuviera desconectado del entorno que uso todos los días. Este tipo de escenarios evidencian un problema más profundo: las entrevistas de código suelen quitarnos exactamente las cosas que nos hacen desarrolladores productivos.

Por qué las empresas usan retos de código

Hay razones por las que existen las pruebas de código, y algunas son justas. Le permiten a los reclutadores estandarizar evaluaciones, escalar el proceso de contratación y, especialmente para los juniors, ofrecen una oportunidad de demostrar capacidad sin mucho historial de trabajo previo. Plataformas como HackerRank o LeetCode hacen fácil automatizar el proceso y filtrar cientos de candidatos rápidamente.

Pero la velocidad y la escala tienen un costo. El resultado suele ser una prueba unidimensional de qué tanto alguien ha practicado acertijos de algoritmos, no de qué tan bien puede construir y mantener software en el mundo real y desordenado.

Por qué les fallan a los desarrolladores senior

Para los desarrolladores senior, el valor que aportamos va mucho más allá de los ejercicios de código en crudo. Nosotros:

• Diseñamos sistemas resilientes y escalables.
• Mentoreamos a los juniors y guiamos equipos.
• Tomamos decisiones de trade-off entre velocidad y sostenibilidad a largo plazo.
• Navegamos código legacy, servicios de terceros e integraciones.

Los retos de código rara vez miden estas habilidades. En su lugar, se enfocan en si puedes programar como una máquina bajo presión de tiempo. Ese enfoque no solo tergiversa la experiencia senior, sino que también filtra a ingenieros sólidos que podrían brillar en el rol real.

Cómo se ve una buena entrevista

No todas las entrevistas son malas. Una de las mejores que he tenido iba a ser un screening técnico corto de treinta minutos para un rol senior. En lugar de eso, se convirtió en una conversación de dos horas y media entre dos desarrolladores. Nunca tocamos una pizarra ni un ejercicio de código. Discutimos ideas de diseño y posibles soluciones para un proyecto nuevo. Exploramos cómo tecnologías como gRPC, Node.js, C#, React y Flutter podrían encajar juntas, aunque ninguno de los dos conocía el objetivo final exacto del proyecto.

Lo que la hizo valiosa no fue resolver un problema en el momento, sino compartir perspectivas. El entrevistador tenía mucha más experiencia que yo, pero pude contribuir con ideas desde mi propio background y experiencia "fuera de la caja". Se sintió como dos profesionales intercambiando ideas — el tipo de colaboración que sí ocurre en los proyectos de software reales.

Esa entrevista me dejó la sensación de que esa empresa valoraba la profundidad, la conversación y la experiencia práctica más que la memorización. Irónicamente, aprendí algo nuevo del entrevistador, y él aprendió algo de mí. Así debería sentirse una verdadera entrevista de nivel senior.

El problema del outsourcing

Otro factor es el auge de las agencias de reclutamiento externas. Muchas empresas ahora tercerizan la contratación de desarrolladores a agencias cuyo incentivo principal es el volumen y la velocidad. Mientras más rápido colocan un candidato, más rentables son. Las entrevistas de calidad toman tiempo, y el tiempo recorta las ganancias.

Este cambio ha convertido la contratación de desarrolladores en un negocio de commodities. Las agencias se apoyan fuertemente en pruebas de código estandarizadas porque son fáciles de administrar y rápidas de calificar. ¿El resultado final? A los desarrolladores se les trata menos como profesionales y más como piezas reemplazables.

Cantidad sobre calidad en la industria

Esto no se trata solo de entrevistas. Mira la última década de Silicon Valley. Las startups consumen cantidades masivas de recursos, levantan millones y queman la energía de los desarrolladores a tasas increíbles. ¿Y cuántas de esas ideas "disruptivas" produjeron realmente valor duradero?

Con demasiada frecuencia, las empresas optimizan por velocidad y crecimiento a toda costa. Los desarrolladores quedan atrapados en el ciclo: sprints constantes, backlogs interminables y la rueda de hámster del "agile" donde la velocity importa más que el oficio. La calidad ahora se trata como sinónimo de tiempo perdido.

En ese ambiente, no sorprende que las prácticas de contratación también prioricen la velocidad sobre la calidad. Si la meta es output rápido y reemplazo rápido, ¿por qué las entrevistas no estarían diseñadas para moverse rápido en lugar de evaluar a profundidad?

Lo que estamos perdiendo

Cuando las entrevistas reducen a los desarrolladores a solucionadores de acertijos, y cuando la contratación se inclina hacia la cantidad sobre la calidad, perdemos algo importante:

• El oficio de la ingeniería de software.
• El reconocimiento de que la experiencia y el criterio importan.
• La capacidad de construir sistemas que duren más que el siguiente ciclo de funding.

También perdemos buenos desarrolladores que se van frustrados, no porque no puedan resolver problemas de algoritmos, sino porque saben que esas pruebas no reflejan el valor que aportan.

Una mejor manera

Las entrevistas no tienen que estar rotas. Hay mejores enfoques:

• Pair programming sobre tareas realistas.
• Ejercicios de diseño de sistemas que reflejen retos reales de la empresa.
• Revisar o refactorizar muestras de código real.
• Permitir que los candidatos usen sus herramientas normales, desde IntelliSense hasta documentación y asistentes de IA modernos.

Estos enfoques miden lo que importa: criterio, colaboración y la capacidad de resolver problemas del mundo real con las herramientas correctas.

Pensamiento final

No me opongo a los retos de código en sí. A lo que me opongo es a que estén desconectados de la realidad del trabajo. Cuando las entrevistas premian la velocidad sobre la calidad, cuando nos quitan las herramientas que realmente usamos, y cuando tratan a los desarrolladores como piezas intercambiables, todos perdemos.

Los mejores ingenieros no son los que pueden invertir un árbol binario en diez minutos. Son los que pueden diseñar sistemas que no colapsen con usuarios reales, guiar a sus equipos a través de trade-offs difíciles y entregar valor que perdure.

Hasta que las entrevistas reflejen eso, seguirán siendo un ritual de amor-odio que dice más sobre la velocidad que sobre la calidad.