Antes de la próxima entrevista, haz una prueba: pega el enunciado de tu prueba técnica en Claude Code o en Cursor y mira el reloj. Si en unos minutos tienes una solución que pasa tus tests, la prueba ya no distingue a un buen desarrollador de alguien que sabe pegar un enunciado. Y si la haces en directo prohibiendo la IA, estás viendo cómo trabaja una persona en unas condiciones que no va a tener nunca en su puesto.
No hay que elegir entre prohibir y permitir. Hay que decidir qué quieres medir y construir la prueba para eso. Y lo que conviene medir ha cambiado, porque en un equipo que trabaja con agentes escribir código ya no es la parte difícil. La parte difícil es ver el fallo en un código que parece correcto.
Dos empresas de IA, dos respuestas opuestas
En junio de 2025, Canva publicó en su blog de ingeniería un artículo con un título que no deja dudas: «Sí, puedes usar IA en nuestras entrevistas. De hecho, insistimos». Para los puestos de backend, machine learning y frontend, sustituyó la entrevista de fundamentos de informática —problemas como implementar el Juego de la Vida de Conway— por problemas más ambiguos y realistas, del tipo «construye un sistema para gestionar despegues y aterrizajes en un aeropuerto con mucho tráfico». Y cambió lo que evalúa: cómo se descompone un requisito ambiguo, qué decisiones técnicas se toman con ayuda de la IA, si se detectan y corrigen los fallos del código generado y si el resultado cumple los estándares de producción.
Lo más interesante son sus conclusiones de las primeras pruebas. Los mejores candidatos hacían preguntas para aclarar el problema, usaban la IA para subtareas concretas sin perder el control del conjunto y revisaban con ojo crítico lo que generaba. Y los candidatos sin experiencia con estas herramientas lo pasaban mal, según Canva, porque les faltaba el criterio para guiar a la IA.
Anthropic mantiene una guía para candidatos, actualizada en julio de 2025, que va en la dirección contraria en lo que importa aquí. En el currículum, la IA está bien siempre que el primer borrador sea tuyo. Pero las pruebas para casa se hacen sin Claude salvo que se indique lo contrario, y en las entrevistas en directo, en sus palabras, «esto eres tú»: sin ayuda de IA, salvo indicación expresa. Quieren ver cómo razona la persona en tiempo real.
Las dos políticas son coherentes, porque cada una sabe qué mide. Anthropic quiere ver el razonamiento individual; Canva, cómo trabaja alguien con la herramienta que va a usar. Lo incoherente es lo que hacen muchas empresas: permitir la IA sin cambiar la prueba, con lo que se mide la velocidad del modelo, o prohibirla en la entrevista y después pedir en el puesto productividad con agentes desde el primer día.
Lo que se ha vuelto escaso
Si escribir código ya no es el cuello de botella, ¿qué lo es? Dos datos lo dejan bastante claro.
El primero es de METR, una organización de investigación que evalúa modelos de IA. En julio de 2025 publicó un experimento con dieciséis desarrolladores experimentados de proyectos de código abierto, que resolvieron 246 tareas reales en repositorios a los que contribuían habitualmente, unas con IA y otras sin ella. Con IA tardaron un 19% más. Antes de empezar esperaban ir un 24% más rápido, y al terminar seguían creyendo que habían ganado un 20%. Los autores insisten en que el estudio no demuestra que la IA ralentice a la mayoría de los desarrolladores: es una muestra concreta, en proyectos que conocían muy bien. Pero el desajuste entre lo que se percibe y lo que se mide no es un detalle, porque aparece incluso en gente con mucha experiencia.
El segundo es de la encuesta anual de Stack Overflow de 2025. El 84% de quienes respondieron usa o piensa usar herramientas de IA para programar, pero sólo un 33% se fía de su precisión, frente a un 46% que desconfía. La frustración más citada, por un 66%, son las soluciones que están «casi bien, pero no del todo». Y un 45% dice que depurar el código generado por IA le lleva más tiempo.
Juntos dibujan la habilidad que hay que buscar. No es escribir deprisa, que lo hace la herramienta. Es detectar el «casi bien» antes de que llegue a producción, y saber medir con honestidad cuánto te ha ayudado la herramienta. Ninguna de las dos cosas aparece en una prueba de algoritmos, y tampoco en un live coding en el que se permite la IA y se mide si el ejercicio queda resuelto.
Qué mide cada prueba hoy
Con ese criterio, las pruebas habituales quedan así:
| Prueba | Qué mide hoy | Para qué sirve |
|---|---|---|
| Algoritmo en pizarra, sin herramientas | Fundamentos y razonamiento en voz alta. No dice nada de cómo trabajará con agentes | Complemento corto, no prueba principal |
| Prueba para casa sin supervisión | Si sabe usar un agente, o nada, si después no se le pregunta cómo la ha hecho y por qué | Sólo si se revisa con el candidato |
| Live coding con IA permitida y el enunciado de siempre | La velocidad del modelo | Para poco: el enunciado ya no discrimina |
| Especificar un requisito ambiguo antes de implementarlo | Si sabe decir qué hay que construir, qué queda fuera y cómo se sabrá que está bien | Central en un equipo que trabaja con specs |
| Revisar un pull request generado por IA con fallos sembrados | Criterio sobre el código ajeno: la tarea que hará cada día | Central |
| Depurar un fallo en un código plausible | Lo que más tiempo cuesta según los propios desarrolladores | Muy útil, y rápido de preparar |
Valoración de onext. Las pruebas no se excluyen: lo que cambia es cuál pesa más en la decisión
Las dos filas centrales tienen algo en común: reproducen el trabajo. En un equipo que usa Spec-Driven Development, la jornada de un desarrollador consiste en buena parte en decir con precisión qué hay que construir, dejar que el agente implemente y comprobar que lo implementado es lo que se pidió. Si la entrevista no tiene esos tres momentos, está evaluando otro trabajo.
Una sesión en tres tiempos
Así plantearíamos una entrevista técnica de unos noventa minutos para un puesto de desarrollo en un equipo que trabaja con agentes. No es la única forma de hacerlo, pero cada parte tiene una señal concreta que mirar.
Especificar (unos 20 minutos)
Se da un requisito deliberadamente ambiguo, parecido al del aeropuerto de Canva, y se pide una especificación corta antes de tocar código: qué entra y qué no, qué criterios de aceptación tendría y qué preguntaría al cliente. Aquí se mira qué preguntas hace y si sus criterios se pueden comprobar. Alguien que escribe «debe ser rápido» no ha especificado nada; alguien que escribe cuántas operaciones por segundo y en qué condiciones, sí. Es el mismo razonamiento que desarrollamos en la especificación es donde se firma.
Delegar (unos 40 minutos)
El candidato implementa una parte con su propia herramienta —la que use en su día a día, no la que imponga la empresa— y va contando lo que hace. No se mira si termina. Se mira cómo reparte el trabajo con el agente, qué acepta sin leer, cuándo lo para y qué hace cuando el resultado no encaja con la especificación que acaba de escribir.
Revisar y romper (unos 30 minutos)
Se le entrega un pull request generado con IA sobre el mismo problema, con tres fallos sembrados del tipo que la IA comete de verdad: un test que describe el código en lugar de probarlo, un caso límite que nadie ha tratado y un criterio de la especificación que se ha saltado sin avisar. Se mira qué encuentra, cómo explica por qué es un fallo y qué pediría antes de aprobarlo. Es, casi literalmente, el review que sigue esperando a un autor que tendrá que hacer cada semana.
Y una última pregunta, que sale directamente del estudio de METR: «¿cuánto crees que te ha ahorrado la IA en esta sesión?». No se trata de penalizar una mala estimación, sino de ver si la persona se ha fijado. Quien responde «en la parte de implementar mucho, pero en la revisión he perdido tiempo porque el test no probaba nada» está midiendo su trabajo. Quien responde «muchísimo» sin matices, probablemente no. Es el mismo problema que vemos en las empresas cuando el ROI de Copilot se mide donde no está, pero en una sola persona.
Los fundamentos no desaparecen: se preguntan al final, sin herramientas, en una conversación corta sobre por qué ha tomado cada decisión. Es el punto que tiene razón Anthropic. Sin fundamentos no se detecta un error sutil en un código generado, porque no se sabe que es un error.
Lo que la IA no debería hacer en tu proceso de selección
Hay una ironía en todo esto. Muchas empresas que piden a los candidatos que no usen IA la usan ellas para filtrar currículums. Y ahí el problema no es de coherencia, es legal.
El Reglamento Europeo de IA clasifica como de alto riesgo los sistemas de IA destinados a la contratación o selección de personas, en particular para analizar y filtrar solicitudes de empleo y evaluar a los candidatos (anexo III, punto 4). Tras la modificación que entró en vigor el 27 de julio de 2026, esas obligaciones se aplican desde el 2 de diciembre de 2027. El aplazamiento no es un permiso para esperar: una herramienta de cribado que se contrate hoy seguirá en uso entonces, y habrá que poder explicar cómo decide y quién supervisa lo que descarta.
Hay además una razón menos jurídica. Un proceso que filtra con un modelo y evalúa sin él manda un mensaje raro a alguien a quien le vas a pedir que trabaje con agentes y que revise lo que generan. Lo razonable es que las decisiones sobre las personas las tomen personas, y decirlo por escrito. En nuestra propia oferta lo hemos hecho así: ninguna IA filtra ni puntúa las candidaturas, y nuestra política de privacidad lo recoge en el apartado de candidatos.
La entrevista tiene que parecerse al trabajo
Todo lo anterior se resume en una idea que no es nueva: la entrevista tiene que parecerse al trabajo. Lo nuevo es que el trabajo ha cambiado más deprisa que las entrevistas. Si en tu equipo se especifica, se delega en un agente y se verifica, eso es lo que hay que ver en la entrevista. Si la prueba se puede resolver pegando el enunciado, no dice nada del candidato. Y si en ningún momento hay que encontrar un fallo, deja fuera justo la habilidad que más falta hace.
Contratar mal es caro, y ya calculamos cuánto cuesta tener un puesto técnico meses sin cubrir. Contratar a alguien que escribe deprisa con un agente pero no ve sus errores también lo es, sólo que tarda más en notarse.
Por cierto, estamos contratando: buscamos un Full Stack Developer para trabajar con agentes de IA y Spec-Driven Development, la oferta está aquí.
Preguntas frecuentes
¿Hay que dejar usar IA en la entrevista técnica?
Depende de lo que quieras medir, y hay que decidirlo antes. Si quieres ver cómo razona alguien por su cuenta, tiene sentido pedir que no la use, como hace Anthropic en sus pruebas y entrevistas salvo que indique lo contrario. Si quieres ver cómo trabajará en el puesto, tiene sentido exigirla, como hace Canva desde junio de 2025. Lo que no funciona es permitirla sin cambiar la prueba: entonces se mide la velocidad del modelo, no a la persona.
¿Siguen sirviendo las pruebas de algoritmos?
Para comprobar fundamentos, sí, y los fundamentos siguen contando: sin ellos no se detecta un error sutil en un código generado. Pero ya no sirven como prueba principal, porque miden cómo trabaja alguien sin las herramientas que va a usar cada día. Una conversación corta sin herramientas sobre por qué ha tomado cada decisión de diseño da la misma información en menos tiempo.
¿Cómo se evalúa si un candidato sabe revisar código generado por IA?
Dándole a revisar un pull request generado con IA en el que se han sembrado fallos del tipo que la IA comete de verdad: un test que describe el código en lugar de probarlo, un caso límite que no se trata, un requisito de la especificación que se ha saltado sin avisar. Se mira qué encuentra, cómo explica por qué es un fallo y qué haría para que no llegue a producción. Es la tarea que va a hacer cada día.
¿Qué dice el Reglamento Europeo de IA sobre usar IA para filtrar candidatos?
Que los sistemas de IA destinados a analizar y filtrar solicitudes de empleo y a evaluar candidatos son de alto riesgo (anexo III, punto 4). Tras la modificación que entró en vigor el 27 de julio de 2026, esas obligaciones se aplican desde el 2 de diciembre de 2027. No es un motivo para esperar: una herramienta de cribado que se contrate hoy seguirá funcionando entonces, y habrá que poder explicar cómo decide.
¿Los desarrolladores que usan IA son más rápidos?
No siempre, y no lo saben medir por sí mismos. En el estudio de METR de julio de 2025, dieciséis desarrolladores experimentados de proyectos de código abierto tardaron un 19% más en sus tareas con IA, cuando esperaban ir un 24% más rápido, y al terminar seguían creyendo que habían ganado un 20%. Los autores advierten de que no se puede generalizar a todos los desarrolladores, pero el desajuste entre percepción y medida es la lección útil para una entrevista.
¿Qué perfil buscar para un equipo que trabaja con especificaciones y agentes?
Alguien que sepa decir qué hay que construir y cómo se sabrá que está bien antes de escribir código, que delegue en el agente las partes que puede verificar y que se pare a leer lo que acepta. En la entrevista se nota en tres cosas: las preguntas que hace ante un requisito ambiguo, los fallos que encuentra en un código que parece correcto y lo bien que estima cuánto le ha ayudado la herramienta.
Fuentes
- Simon Newton, «Yes, You Can Use AI in Our Interviews. In fact, we insist», Canva Engineering Blog, 11 de junio de 2025.
- Anthropic, guía de uso de IA para candidatos, actualizada el 10 de julio de 2025.
- METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10 de julio de 2025.
- Stack Overflow, Developer Survey 2025, sección de IA.
- Reglamento (UE) 2024/1689 de Inteligencia Artificial, anexo III, punto 4.
- Comisión Europea, «AI Omnibus enters into force», 27 de julio de 2026.
Jordi García es Tech Lead en onext. Trabaja en llevar la IA a producción gobernada en equipos de desarrollo y de producto —con Spec-Driven Development, ingeniería de contexto y verificación humana en cada paso— y firma los insights técnicos de onext sobre método, calidad y coste de la IA aplicada.
LinkedIn →