Esta semana entrevisté a diez desarrolladores. No contraté a ninguno
Seis resolvieron el live-coding perfecto. Cuatro de esos seis, diez minutos después, no supieron explicar su propio código. Cómo hago entrevistas ahora — y por qué el filtro antiguo ya no filtra.
Ayer entrevisté a diez desarrolladores. No contraté a ninguno.
Era uno de esos proyectos en los que el cliente te pide "ayúdame con la contratación" y acabas seis horas sentado en Zoom viendo pasar senior backends, uno más ideal que el anterior. Para que la cosa no se parara, rodé un formato de "tres reuniones por la mañana con pausa para café, tres más antes de comer". El jueves por la tarde tenía diez reuniones, diez fichas en Airtable y una sensación terca de estar haciendo algo mal.
Seis de diez resolvieron el live-coding perfecto. Cuatro de esos seis, diez minutos después, no pudieron explicar su propio código. "Pues… porque es lo que se hace" — cita directa. Como justificación para haber elegido esa estructura de datos en concreto.
Cerré la última llamada. Anoté "no" en el tracker. Escribí a RR.HH. que seguíamos buscando. Y me quedé mirando mi café que, me di cuenta solo entonces, llevaba un par de horas frío.
(Pensamiento aparte — por qué en 2026, con la IA ocupándose de mi correo, mi calendario y a veces respondiendo a ventas por mí, todavía no tengo solución para "el café tiene que seguir caliente cuatro horas de entrevistas". Por lo visto una de esas tareas que parecen tontas a primera vista y se vuelven mucho más tontas cuando intentas pensarlas con detenimiento.)
Hace cinco años entrevistar a un desarrollador era simple. Algoritmo de dificultad media (algo con grafos, por ejemplo — a todo el mundo le encantaban los algoritmos con grafos). Un case de arquitectura. Preguntas sobre SQL, caché, diferencia entre CTE y subconsulta (que, honestamente, busco en Google cada vez). En cuarenta minutos te hacías un cuadro aproximado.
El filtro funcionaba sobre conocimiento mecánico. Se acuerda el candidato de cómo está montado un B-tree. Monta una cola de prioridad en diez minutos. Explica el commit en dos fases sin decir, en tono ofendido, "bueno, esa es una pregunta muy profunda".
En 2026 ese filtro se rompió. No porque los desarrolladores hayan ido a peor. Porque todos tienen claude.ai abierto en la siguiente pestaña. Cualquier estudiante de segundo, con dos clics, resuelve el algoritmo medio en ocho minutos. No porque lo sepa — porque sabe preguntar. Y el modelo le devuelve no solo el código sino un comentario ya listo — como si fueran pensamientos suyos.
No es fraude. Al menos no del tipo que era el título plagiado en 1998. Probablemente ese mismo candidato va a usar el modelo también en el trabajo. Y está bien — yo trabajo igual.
El problema no es que use la herramienta. El problema es que yo estaba filtrando el skill equivocado.
La segunda y tercera entrevista de aquel día me pasaron en modo "no entiendo qué está pasando". El candidato resolvía la tarea en doce minutos, y la solución era… buena. Honestamente buena. Estructura correcta, casos borde tratados, nombres de variables legibles. Yo he escrito peor en mi vida.
En la cuarta entrevista cambié de táctica. El candidato escribió una solución. Cerré el IDE. Hablamos cinco minutos de otra cosa — recuerdo que discutíamos si Lisboa ahora es más barata que Barcelona (spoiler: ya no). Volví al código. Pregunté:
— ¿Por qué elegiste ese tipo de colección en concreto?
— Eh… porque… es lo estándar.
— ¿Y si N fuera diez millones?
— Bueno, funciona igual.
— ¿Qué cambia si cambias esta línea por esta otra?
Pausa. Larga.
Esa pausa es ahora la señal más honesta que puedo recoger en cuarenta minutos. Porque explicar no es recordar. No se puede googlear en la siguiente pestaña mientras estoy hablando. O se ve o no.
Un modelo escribe código. No explica ese código como tuyo propio si no hay tuyo propio.
Desde ese momento reconstruí el formato entero. Queda más o menos así.
Sigo dando una tarea. Pero no LeetCode. Elijo algo de un problema real que me llevó un mes atrás — con contexto, con restricciones, con un aire de trade-off. Algo del tipo: "hay tres opciones de arquitectura, elige y explica". No "implementa una cola de prioridad". Porque el trabajo real son trade-offs, no LeetCode.
El modelo también razona sobre trade-offs. Pero promedia. Elige "lo que hace la industria", "lo que es best practice". Un candidato fuerte elige distinto porque ve el matiz. Un candidato mediocre con modelo elige según el libro. Y cuando en medio de la conversación tiro una piedra al agua — "¿y si para nosotros lo crítico no es velocidad de escritura sino de lectura a la hora X, cuando todos sincronizan?" — el débil se queda, el fuerte reestructura.
Más difícil de falsear por chat, porque rompo el ritmo. Añado una restricción, aclaro el contexto, cambio la pregunta. Cada aclaración tiene que reflejarse en la respuesta. Un candidato con modelo en la segunda pestaña no lo pilla.
También añadí la pregunta sobre un error. No el genérico "cuéntame una debilidad tuya" — la concreta. "Cuéntame una decisión técnica que tomaste y de la que te arrepentiste. ¿Qué aprendiste?" Un empleado fuerte recuerda los detalles: aquel proyecto, aquella BBDD, aquella historia de tres días persiguiendo una fuga de memoria que, al final, estaba en una librería desgraciada que nadie sospechaba. Uno débil — responde en general. O parafrasea un caso de Medium que ya leí.
Y, por último, dejé de hacer live-coding puro. El "escribe desde cero" casi no lo uso ya. En su lugar — "aquí hay un trozo existente, mejorémoslo juntos". Mucho más difícil de falsear vía IA en la segunda pestaña, porque el ritmo lo pongo yo, el foco lo pongo yo, y las aclaraciones vuelan en tiempo real. El candidato tiene que pensar, no generar.
Qué dejó de importar — lo digo claro.
La velocidad de escribir código no filtra. Ahora está nivelada para todos, porque es propiedad del modelo. Certificados — "vi 20 minutos de vídeo y apreté un botón", estamos en 2026. Portfolio en GitHub — tampoco es garantía, porque la mitad de los commits son generados y la otra mitad, honestamente, también.
Qué se hizo más caro:
Formular el problema. La mitad del trabajo real es traducir "quiero que funcione" a spec. En la era de la IA ese skill pesa más que el código. Sin él, una persona con modelo produce un montón de bonito no funcional.
Gusto arquitectónico. El modelo ofrece tres opciones. La persona fuerte sabe cuál encaja aquí y por qué. Eso no cabe en un prompt, porque se construye en años de "lo probamos así y esto salió mal al tercer mes".
Contexto de negocio. "Por qué hacemos X y no Y". Esa parte el modelo no la capta ni con RAG, porque no está en ninguna fuente pública. Está en la cabeza de gente que seis veces ha visto caerse la misma venta en el mismo punto, en persona.
El viernes entregué el informe al cliente. No contraté a nadie. Recomendé rehacer el formato — no buscar al senior que resuelve el algoritmo perfecto, sino a alguien que pueda explicar paso a paso código ajeno. Eso, curiosamente, en 2026 es un skill raro y notablemente más caro.
El cliente aceptó. Reescribimos la oferta. La primera entrevista después — una mujer que no se apresuraba, hacía preguntas de vuelta, una vez dijo abiertamente "no sé", y después se puso a investigar en Google en modo "enséñame tu lío, que lo desenredo". La contratamos. Lleva tres meses y el proyecto está medible, diagnósticamente mejor por ello.
Los buenos candidatos en 2026 no son los que memorizan APIs — son los que piensan sistémicamente y saben usar la herramienta. Filtrar por "¿puede escribir código?" es como entrevistar a un carpintero preguntándole si puede levantar el martillo. Claro que puede. Todos pueden. Los martillos los venden en cualquier supermercado ya.
Pregunta qué va a construir con él.