Algo se rompió esta semana en los foros donde los ingenieros senior discuten entre ellos, no en LinkedIn con posteos de thought leadership, sino en el lugar donde de verdad se dicen las cosas. La pregunta de siempre volvió a circular: ¿tener proyectos personales sigue siendo necesario para que te tomen en serio como buen ingeniero?
Pero la discusión derivó hacia un lugar más incómodo. Si cualquier candidato puede apoyarse en un agente de IA para resolver el ejercicio técnico de una entrevista, ¿qué es lo que en realidad se está midiendo ahí adentro?
La pregunta que dejó de servir
Durante años la entrevista técnica tuvo una función simple: comprobar si la persona podía resolver un problema sola, sin ayuda, con el pizarrón o el editor vacío como único aliado. Tenía sentido. En un mundo donde escribir código desde cero, recordar la sintaxis exacta y no trabarse frente a algo nuevo eran señales reales de capacidad, medir eso equivalía a medir al ingeniero.
Ese mundo cambió de lugar sin avisar. Hoy cualquier persona con acceso a un agente de código puede producir una solución razonable a un problema de entrevista clásico sin entenderlo del todo. "¿Puede resolver esto solo?" sigue siendo la pregunta en un montón de procesos, aunque cada vez mide menos lo que dice medir.
Por qué evaluar sin ayuda dejó de significar algo real
Acá el problema es concreto. Ese mismo ingeniero, apenas entre a trabajar, va a tener un agente de IA al lado en cada pull request, cada bug, cada feature nueva. Evaluarlo en la entrevista sin esa herramienta mide una habilidad que después no va a usar de la forma en que el examen la pide.
Es parecido a evaluar a un piloto por su capacidad de volar sin instrumentos. Puede decir algo sobre reflejos y conocimiento de base, pero no es el trabajo que esa persona va a hacer todos los días. El trabajo real siempre incluyó las herramientas disponibles.
Antes y ahora, dos preguntas distintas
Antes, la pregunta que definía a un buen ingeniero era ¿puede resolver esto solo? Medía memoria, velocidad de tipeo y manejo fino de la sintaxis del lenguaje de turno. Un candidato que se trababa con un detalle menor de implementación podía perder una oferta entera por eso, aunque su criterio de diseño fuera excelente.
Esa pregunta perdió el sentido que tenía. La que debería reemplazarla suena parecida pero mide algo completamente distinto: ¿toma buenas decisiones usando las herramientas que tiene disponibles? Responderla bien requiere observar cómo alguien dirige a un agente, qué le pide, qué le corrige, y sobre todo, cuándo decide no seguir su sugerencia.
El criterio, no la memoria, es lo que separa a un senior
Un agente de IA puede escribir código funcional en segundos. Lo que no tiene es contexto: no sabe por qué ese endpoint carga una excepción rara que quedó de una migración de hace dos años, no estuvo en la reunión donde se tomó la decisión de arquitectura después de un incidente en producción, y no sabe qué parte del sistema es intocable ni por qué.
Un ingeniero senior sí tiene ese contexto, o sabe cómo conseguirlo antes de aceptar una sugerencia. Ahí está la habilidad que hoy lo separa de alguien que todavía no llega a ese nivel: el juicio para reconocer cuándo la respuesta del agente es correcta, cuándo hay que ajustarla, y cuándo hay que descartarla entera porque resuelve el síntoma equivocado. Esa capacidad de detectar el error no sale de un buen prompt, sale de años de haber visto sistemas fallar de maneras muy específicas.
Un ejemplo del tipo de error que separa a los dos
Piensa en un caso simple: el agente propone agregar un índice a una tabla para acelerar una consulta lenta. La sugerencia compila, pasa los tests, y en el ambiente de desarrollo la consulta efectivamente corre más rápido.
Un ingeniero sin el contexto suficiente la acepta y sigue. Uno senior se detiene un segundo antes: sabe que esa tabla recibe escrituras constantes en producción, que un índice mal elegido puede frenar cada insert, y que el problema real no está en la consulta sino en cómo se está paginando esa vista.
La sugerencia del agente no estaba mal escrita. Estaba mal dirigida, del tipo que uno aprueba en el PR con un comentario tipo "funciona, pero me da cosa". Esa sensación, la de saber cuándo algo anda técnicamente bien pero está mal, es exactamente lo que un ejercicio de entrevista debería estar buscando hoy.
Los side projects no perdieron valor, perdieron el monopolio
Vale la pena aclarar algo antes de seguir. Tener proyectos personales sigue diciendo algo real sobre un ingeniero: iniciativa, curiosidad, capacidad de terminar algo sin que nadie te lo pida ni te pague por eso. Eso no cambió.
Lo que cambió es que dejó de ser el único indicador válido. Antes, si alguien no tenía repos personales para mostrar, la sospecha caía sobre su compromiso real con el oficio.
Hoy un ingeniero puede no tener un solo proyecto propio y aun así demostrar, en cómo dirige a un agente durante una entrevista y detecta dónde se equivoca, exactamente el tipo de criterio que antes solo se veía en quien programaba los fines de semana. Durante mucho tiempo el side project fue la prueba más visible de ese criterio. Ya no es la única forma de mostrarlo.
Lo que cambia para quienes diseñan el proceso
Para las empresas que arman procesos de entrevista, esto implica repensar el ejercicio técnico desde el diseño. Dar acceso a un agente durante la entrevista y observar cuándo la persona confía en la sugerencia y cuándo la cuestiona revela más sobre su nivel real que prohibirlo y cronometrar cuánto tarda alguien en escribir un bucle desde cero, como si todavía fuera 2015. La pregunta que vale la pena hacerse al diseñar el proceso no es cómo evitar que el candidato use IA, sino cómo armar un ejercicio donde usarla mal quede tan expuesto como no usarla en absoluto.
El código lo puede escribir cualquiera con el prompt correcto, y hasta el propio agente lo sabe (probablemente mejor que nadie). Lo que separa a un ingeniero senior de alguien que todavía no llega ahí nunca fue quién escribe más rápido, sino quién nota primero que lo que se acaba de escribir está mal.
