Los coding challenges son una pérdida de tiempo
Después de cientos de entrevistas técnicas, no creo que el live coding haya medido bien el trabajo. Ahora que la IA es parte del día a día, tiene todavía menos sentido.
En los últimos años me ha tocado estar en los dos lados de cientos de entrevistas técnicas. Llamadas con recruiters, phone screens, take-homes, rondas de system design, deep dives de arquitectura, entrevistas de comportamiento y más sesiones de live coding de las que quiero contar. He sido el candidato nervioso. También he sido el entrevistador cansado. He pasado procesos que probablemente no debí pasar, y no pasé procesos que sí debí pasar.
Después de vivirlo suficientes veces, me quedé con una opinión bien directa: los live coding challenges son una pérdida de tiempo para todos. Siempre fueron medio teatro. Ahora que la IA es parte del trabajo real, se sienten todavía más desconectados de lo que hacemos día a día.
Para ser claro, no estoy en contra de las entrevistas técnicas. Me gustan las buenas entrevistas técnicas. Estoy en contra de un ritual específico: comparte tu pantalla, resuelve un problema de algoritmos de memoria y habla en voz alta mientras alguien mira tu cursor parpadear y un reloj corre en contra.
El live coding nunca midió el trabajo real
Invertir un árbol binario con el cronómetro corriendo, narrando cada pensamiento mientras alguien mira cada letra o palabra que escribes, tiene muy poco que ver con construir software de verdad. El trabajo real rara vez se hace solo. Rara vez está cronometrado al minuto. Casi nunca se hace sin docs, referencias, compañeros, logs, tests o código existente.
El live coding premia sobre todo dos cosas: patrones memorizados y poder mantener la calma mientras te observan. No son habilidades inútiles, pero tampoco son el trabajo. He visto ingenieros muy buenos quedarse pegados en ese formato. También he visto candidatos que no venían tan fuertes avanzar sin problema porque justo habían practicado ese patrón la semana anterior. La señal es débil.
La versión grabada es peor. Grabación de pantalla prendida. Cámara prendida. Micrófono prendido. Cronómetro corriendo. A veces ni siquiera hay entrevistador: solo un cuestionario, un coding challenge y la instrucción de grabarte mientras haces todo en modo speedrun. Trata a un ingeniero con experiencia como a un sospechoso que tiene que demostrar que no está haciendo trampa. Nadie trabaja mejor cuando lo están vigilando así, y el formato dice bastante sobre cómo la empresa ve a la gente que está tratando de contratar.
No escribo código a mano desde 2024
Esta es la parte que muchos entrevistadores no están listos para escuchar: no escribo a mano una línea significativa de código de producción desde 2024. Ahora la IA escribe el código. Yo sigo construyendo software. Simplemente ya no creo que teclear sea la parte difícil.
Mi trabajo es la arquitectura, los tradeoffs, el resultado y la validación. Decido qué construir y por qué. Decido cómo encajan las piezas, dónde el sistema va a aguantar, dónde se puede romper y cómo vamos a probar que funciona. Reviso lo que me entrega el modelo. Defino los evals y los guardrails. Uso mi criterio en las partes donde no hay una respuesta obvia.
Entonces, cuando una entrevista prohíbe las herramientas que uso todos los días y me evalúa por cuánta sintaxis recuerdo de memoria, está midiendo una habilidad que dejé de optimizar a propósito. Es como pedirle a alguien que maneja Uber en Nueva York todos los días que apague el GPS, el tráfico en tiempo real, los cortes de calle y las rutas actualizadas. Puede manejar igual. Quizás incluso conoce bien la ciudad. Pero va a llegar más lento, se puede topar con una calle cortada y va a hacer peor su trabajo, que depende de usar la mejor información disponible.
Las entrevistas que sí me gustan
Dame una conversación real. Cuéntame algo que construiste y que de verdad te importó. ¿Por qué esa base de datos? ¿Por qué ese límite entre servicios? ¿Qué se rompió en producción? ¿Qué cambiarías si partieras de nuevo hoy? Pon dos diseños sobre la mesa y conversemos los tradeoffs.
Ahí aparece el conocimiento real. Una buena entrevista técnica deja que el candidato muestre lo que sabe, y también deja que el entrevistador entienda cómo piensa esa persona en condiciones parecidas al trabajo, no en una actuación.
Además funciona en ambos sentidos. Yo evalúo a la empresa tanto como la empresa me evalúa a mí. Quiero entrar a un equipo que valga mi tiempo. El equipo quiere a la persona correcta para el trabajo. Ningún lado está por encima del otro. Las mejores entrevistas que he tenido se sintieron como dos profesionales tratando de entender si deberían construir algo juntos, no como un examen con timbre al final.
Take-homes, bien hechos
Si de verdad necesitas verme construir, dame un take-home asíncrono que pueda hacer en mi horario, con las herramientas que usaría en un trabajo real. Los mejores que he hecho se sintieron como trabajo real. Algunos fueron pagados, y bien pagados, porque eran trabajo real. Esa sola decisión me dice harto: esta empresa respeta mi tiempo y se toma su proceso de hiring lo bastante en serio como para invertir en él.
Ahora compara eso con una ronda de live coding grabada, con un micrófono encima del hombro. Un formato dice: confiamos en ti, aquí hay algo real, muéstranos cómo piensas. El otro dice: actúa para nosotros mientras te grabamos. El mismo objetivo declarado. Un mensaje completamente distinto.
La entrevista muestra la cultura de una empresa
Esta es la parte que mucha gente pasa por alto. La entrevista no es un filtro neutral pegado al lado de la empresa. Es la empresa, en versión chica. Un proceso que respeta tu tiempo, confía en tu experiencia y evalúa tu criterio te está mostrando una cultura que vale la pena. Un proceso armado sobre vigilancia, preguntas trampa y restricciones artificiales también te está mostrando su cultura. Créeles.
Eso significa que puedes decir que no. Puedes rechazar ese challenge grabado e incómodo y pedir una conversación o un take-home en su lugar. Yo lo he hecho. Las empresas con las que valía la pena trabajar dijeron que sí sin hacerlo raro. Las que insistieron con el teatro me dijeron gratis cómo probablemente se iban a sentir los próximos meses o años trabajando ahí.
Las herramientas cambiaron, y el trabajo cambió con ellas. La IA debería escribir el código. Los ingenieros deberían gastar más energía en arquitectura, resultados, validación y en el trabajo que de verdad mueve el sistema hacia adelante. Las entrevistas deberían evaluar eso.
Si tu proceso todavía le pone nota a la gente por lo bien que puede fingir que seguimos en 2015, no está midiendo talento. Está perdiendo el tiempo de todos, partiendo por el tuyo.