Contratar en la era de la IA
El mapa ya no coincide con el territorio
Estás entrevistando a un candidato junior. Le habéis puesto una prueba técnica.
La entrega es la mejor que has visto nunca. Documentación impecable. Diagramas de arquitectura que parecen sacados de un libro de Martin Fowler. Tests de integración. Manejo de errores. Hasta hay un README con instrucciones de despliegue.
Miras a tu compañera de entrevistas. Ella te devuelve la mirada. Estáis impresionados.
Entonces empezáis a preguntar.
¿Por qué X en lugar de Y? Silencio.
¿Qué pasa si el token expira durante una operación crítica? Silencio.
¿Por qué la API devuelve un 200 con un body de error en vez de un 4xx? Mirada de ¿de qué hablas?
Cada pregunta es un pinchazo en un globo que se va desinflando despacio.
Os volvéis a mirar, esta vez sin saber qué hacer con lo que acabáis de ver.
El mapa ya no coincide con el territorio
Durante décadas, la industria del software construyó sus procesos de selección sobre una premisa implícita: la capacidad de producir código era un proxy razonable de la capacidad de pensar sobre el desarrollo de software.
Si alguien entregaba una prueba técnica bien resuelta, probablemente entendía los fundamentos.
La premisa nunca fue perfecta, siempre hubo gente brillante que fallaba en las entrevistas y gente mediocre que las aprobaba. No era un proxy que yo comprase, pero, desde luego, era un proxy habitual
La IA ha terminado de romper esa premisa.
Hoy, la capacidad de producir código no correlaciona con casi nada. Cualquier persona con acceso a un LLM puede generar código que parece competente.
Es como si llevases treinta años contratando pilotos pidiéndoles que hagan maquetas de aviones. Las maquetas eran un proxy razonable cuando solo las podía hacer alguien que entendía de aerodinámica. Pero si de repente cualquiera puede producir maquetas perfectas con una impresora 3D, tu proceso de selección ya no selecciona pilotos. Selecciona gente con acceso a una impresora.
Lo que se ha roto en cada nivel
Juniors
El cambio más dramático está aquí. Un junior con acceso a herramientas de IA puede producir output que, en la superficie, es indistinguible del de un desarrollador mid de hace tres años.
Esto genera dos problemas simultáneos:
Problema 1: no puedes distinguir al que entiende del que copia. Ambos te entregan el mismo código. La diferencia es que uno sabe por qué funciona y el otro no. Y esa diferencia solo se manifiesta cuando algo se rompe, que es exactamente cuando más necesitas que alguien entienda lo que hizo.
Problema 2: los buenos juniors se devalúan. Si no puedes distinguirlos de los que simplemente copian el output de IA, el mercado los trata igual. El junior que ha invertido meses en entender cómo funciona algo técnico compite con el que aprendió a promptear ayer. En el proceso de selección tradicional, ambos se ven igual.
Esto tiene una consecuencia perversa: desincentivas exactamente el tipo de aprendizaje profundo que necesitas que exista en tu organización.
Mids
Con IA, un mid puede ahora producir a un ritmo que antes era imposible. Genial.
El problema es que la capacidad de generar ha crecido mucho más rápido que la capacidad de pensar sobre el problema. Tu mid puede producir tres veces más código en un día. Pero, ¿puede revisar que todo esté como debería? ¿Puede reducir la complejidad? ¿Puede razonar sobre a dónde va el sistema a esa velocidad?
Eso no se acelera con IA.
Resultado: generas más código que nadie entiende del todo.
Siempre fue importante cuestionar las soluciones propuestas; hoy es más importante todavía que ayer.
Seniors
Aquí el problema es más sutil. Un buen senior siempre se definió por su juicio: la capacidad de tomar decisiones a todos los niveles, de saber cuándo una solución “correcta” es la solución equivocada en tu contexto, de oler los problemas antes de que aparezcan.
Hasta ahora ese juicio no se desarrollaba pidiéndole a un LLM cosas. Se desarrollaba escribiendo código, rompiéndolo, debuggeándolo, manteniendo sistemas en producción durante años. Se desarrollaba sufriendo las consecuencias de tus propias decisiones.
Los futuros seniors de tu organización que se forman ahora delegando la escritura de código a la IA, ¿habrán desarrollado ese juicio? No sabemos cómo será el proceso para ser senior en este nuevo escenario.
Seguro que surjirán nuevas formas de desarrollar ese juicio que aún no vemos. Pero si tengo que entrevistar hoy, todavía es la única forma que tengo de saber si alguien es senior. Medir su experiencia en la forma “antigua” de desarrollar software.
Lo que no ha cambiado
Hay cosas que ninguna herramienta de IA cambia en una contratación:
La capacidad de comunicar ideas complejas. Esto sigue siendo igual de raro e igual de valioso.
La disposición a decir “no sé, pero lo podemos averiguar”. Paradójicamente, más importante ahora que la IA te da la ilusión de saberlo todo.
El instinto de simplificar. Cualquiera puede generar complejidad. Ahora es todavía más fácil que antes. Reducirla sigue siendo un arte humano.
La capacidad de trabajar con otros seres humanos. Obviedad que seguimos evaluando mal porque no es una “hard skill”.
Si tu proceso de selección ya evaluaba bien estas cosas, enhorabuena. Estás mejor preparado que la mayoría para contratar en la era de la IA.
Pistas para el nuevo mapa
No tengo un framework de contratación perfecto para este nuevo momento. Creo que nadie lo puede tener todavía.
Lo que sí tengo son pistas. Cosas que parecen funcionar mejor que lo que teníamos. Y, que, si lo miro, no son tan diferentes de lo que me gustaba usar para reclutar antes de la IA.
1. Evaluar el razonamiento, no el artefacto.
Dejar de mirar lo que entregan. Mira cómo piensan sobre lo que entregan.
Que alguien sepa explicar sus decisiones, justificar los trade-offs, identificar problemas futuros. Si alguien te entrega una solución perfecta pero no puede explicar por qué descartó las alternativas, eso te dice todo lo que necesitas.
2. Evaluar con ambigüedad deliberada.
Los problemas bien definidos son los más fáciles de resolver con IA. Es más útil evaluar problemas donde no está claro ni qué hay que hacer. ¿La persona hace suposiciones y avanza sin validarlas? ¿Pide clarificación? ¿Identifica que hay información que falta? La capacidad de navegar la ambigüedad siempre fue importante. Hoy más.
3. La honestidad intelectual.
Haz preguntas cuya respuesta correcta es “depende” o “no lo sé”. Si alguien te da una respuesta contundente a algo que genuinamente no tiene respuesta clara, eso es una señal. En un mundo donde la IA te da respuestas con confianza absoluta sobre todo, necesitas gente que ponga más en duda lo que haces.
4. Observa cómo usan la IA, no si la usan.
No tiene sentido prohibir herramientas de IA en las pruebas técnicas. Ya forman parte del stack que usamos. Lo importante nunca fue qué herramientas usamos. Sino cómo las usamos, qué hacemos con ellas…
Pero… ¿Alguien está contratando?
Es posible que para ciertos roles, en ciertos contextos, necesites menos gente de la que necesitabas antes. Ya hablé sobre algo de esto en mi anterior newsletter.
También es posible que necesites contratar justo debido a este cambio de paradigma. Y, si lo haces, no puedes usar un Playbook de 2019.
Para terminar
Los procesos de selección siempre fueron imperfectos. La única forma real de saber si alguien funciona es trabajar con esa persona.
Lo que ha cambiado es que las imperfecciones que antes solíamos tolerar, evaluar la producción como proxy del conocimiento, ahora son inútiles.
No creo que nadie tenga todavía “la” respuesta de cómo contratar bien en este contexto.
Sí creo que los managers que empiecen a experimentar ahora, que ajusten sus procesos, que prueben cosas distintas, que se equivoquen y aprendan, van a tener una ventaja enorme sobre los que sigan usando el antiguo sistema.
Si esta edición te ha hecho replantearte algo sobre cómo contratas en esta nueva era, considera reenviársela a alguien que también esté lidiando con esto. Cada nuevo lector nos acerca a una comunidad de managers más preparada.
Nos leemos.
P.D.: Si quieres profundizar, te voy a recomendar libros que no van directamente sobre contratación pero que me han influido más que otros en cómo pienso sobre ello.
Thinking in Bets, de Annie Duke. Contratar siempre es una apuesta, y evaluarla por el resultado (funcionó/no funcionó) en lugar de por el proceso es justo el error que la mayoría comete.
Range: Why Generalists Triumph in a Specialized World, de David Epstein. Para entender por qué en un entorno cambiante como en el que estamos, la amplitud de conocimiento puede ser más valiosa que la profundidad en una herramienta concreta.
Creo que nos encontramos ante una nueva disyuntiva en el sector. Seguir complicando las entrevistas para que se parezcan a las 12 pruebsa de Hércules como venía ocurriendo en los útlimos años o "back to the basics".
Llevo unos cuantos años contrando para todos los niveles, desde junior hasta perfiles principal y lo que mejor me ha funcionado siempre son las conversaciones tranquilas. Nada de pruebas técnicas complicadísimas, problemas algorítmicos o pizarras en blanco, como mucho una sesión de "pair programing" de verdad, no intentando pillarles sino entendiendo como pueden colaborar en el trabajo diario.
Para los junior que me cuenten un poco que saben e intentar indagar en su actitud, lo demás se lo puedo enseñar. Para perfiles más senior, que me cuenten un sistema en el que hayan trabajado o diseñado. Que me digan por qué tomaron ciertas decisiones, que errores creen que cometieron, qué no volverían a hacer. Esta son la clase de conversaciones que te indican como piensa la persona, su capacidad de revisar sus propias decisiones, de entender los trade offs, etc...
Así he creado equipos y seleccionado individuos que siguen aportando valor allí donde los contraté.