LeetCode murió. Lo que lo reemplaza también está roto.
Entrevistar developers en 2026 con whiteboard es como entrevistar carpinteros sin dejarlos tocar madera. Pero las alternativas 'déjalo usar IA' también fallan. Qué sí funciona.
Entrevista técnica clásica en 2026: el reclutador abre HackerRank,
el candidato escribe bubbleSort a mano sin tocar IDE, el reviewer
evalúa “si piensa estructurado”. Una hora invertida.
Después de contratado, el mismo candidato trabaja todo el día con Claude Code, Cursor, Copilot. La habilidad que evaluamos no es la habilidad que va a usar.
LeetCode murió. Pero las alternativas que están emergiendo —“que use lo que quiera, incluyendo IA”— también fallan, por razones distintas.
Por qué LeetCode ya no sirve
Tres problemas que se acumularon:
- Filtra al revés. El mejor candidato en LeetCode no es el mejor developer real. Correlación bajísima entre los dos.
- Penaliza el skill nuevo. El candidato que sabe usar IA bien se ve “menos puro” que el que la rechaza por orgullo. Pero el primero va a ser más productivo en el job.
- Replicable con prep. En 2026 cualquier candidato motivado memoriza patrones de LeetCode con un agente en una semana. No filtra esfuerzo ni curiosidad.
Por qué “déjalo usar IA” tampoco funciona (todavía)
La alternativa obvia: “resuelve el problema con tu stack normal, agente incluido”. Suena bien. Falla por tres razones:
- El reviewer no sabe qué evaluar. Si el candidato genera la solución correcta con Cursor en 4 minutos, ¿es bueno o es suerte? El reviewer no tiene baseline.
- Filtra prompt engineering, no software engineering. El candidato bueno prompteando llega a una solución decente rápido. Pero no sabes si entendería un PR de 200 líneas.
- Demos en silencio. El candidato muestra el output, no su proceso. La diferencia entre senior y junior es el proceso, no el output.
Lo que sí funciona
Lo que vemos producir señal real:
Code review en vivo. Le das al candidato un PR (real o sintético) de 150-200 líneas con bugs intencionales. Su trabajo: identificar problemas, sugerir mejoras, defender sus opiniones. 45 minutos. Filtra criterio crítico — el skill más escaso en 2026.
Pair programming con agente disponible. Le das un problema abierto, le dejas usar Claude Code/Cursor/lo que quiera. Pero observa cómo cura contexto, qué prompts escribe, cómo revisa los diffs del agente, qué corrige y qué deja pasar. El output es secundario; el proceso es el filtro.
Pregunta de diseño con restricciones reales. “Diseña X. Vamos a iterar 30 minutos. Puedes hacer cualquier pregunta, usar cualquier herramienta.” Mide razonamiento sobre tradeoffs, no memoria.
Show your CLAUDE.md. “Mándame tu archivo de contexto del
proyecto actual. Vamos a hablar de las decisiones que tomaste.”
El candidato senior tiene uno. El que finge senior no.
Lo que importa filtrar en 2026
Cuando codear es trivial, lo que necesitas evaluar es:
- Criterio crítico: ¿puede detectar lo que está mal?
- Curaduría de contexto: ¿sabe darle al agente lo que necesita?
- Comunicación: ¿puede explicar por qué tomó una decisión?
- Honestidad operativa: ¿admite cuando no sabe? ¿reporta trade-offs?
- Diseño de sistemas: lo que la IA aún no hace bien
Esas habilidades NO se filtran con LeetCode. Tampoco con “haz lo que quieras”. Se filtran con conversaciones donde el candidato tiene que defender decisiones — propias y del agente.
La incomodidad
Esto cuesta más que un test automático. Una hora de senior por candidato es caro. La industria entera se construyó alrededor de filtros baratos.
Pero el costo de contratar al developer equivocado en 2026 es mucho más alto que en 2020 — porque produce más output, y si ese output es slop, contamina más codebase más rápido.
La pregunta para tu equipo de hiring
Tu próxima contratación: ¿la habilidad que evalúas en la entrevista es la habilidad que va a usar el día 1 en el job?
Si no, ya sabes por qué tu retention y tu productividad no cuadran con tu hiring score.
Si están repensando el proceso de hiring técnico para AI-era, conversemos — el chat está abierto.