El 38% de tus candidatos tech usa AI para hacer trampa — y tu live coding no lo detecta

El 38,5% de los candidatos tech mostró señales de cheating con AI en entrevistas técnicas entre julio de 2025 y enero de 2026. El dato es de Fabric, sobre una muestra de 19.368 entrevistas. En roles puramente técnicos el número sube a 48%. Y la mayoría de las empresas sigue evaluando con un live coding por Zoom como si fuera 2019.

¿Qué tan grande es el problema realmente?

El cheating en entrevistas técnicas no es marginal — es el escenario base. Entre junio y diciembre de 2025, el porcentaje de candidatos que usaba AI no permitida pasó de 15% a 35%. En el estudio de Fabric de 19.368 entrevistas (Jul 2025 – Ene 2026), la foto es más cruda: 48% de cheating en roles técnicos, contra apenas 12% en sales. Los juniors (0–5 años de experiencia) hacen trampa al doble del rate de los seniors.

El número que más asusta no es la prevalencia. Es este: 61% de los candidatos que hicieron trampa pasaron el umbral de aprobación (score ≥7.0). Sin detección, esa gente avanzaba a la siguiente etapa. Mientras tanto, Karat (la empresa de coding interviews) estima que 80% de los candidatos usan LLMs durante code tests incluso cuando está explícitamente prohibido.

En los procesos que vemos en WeRecruitIT, el patrón es consistente con los datos: pantallazo perfecto, código que funciona a la primera, pero el candidato no puede explicar por qué eligió esa estructura cuando le hacés una pregunta de follow-up.

¿Por qué el proctoring tradicional no lo agarra?

Porque la generación 2025 de herramientas de cheating no está pensada para ser detectada por Zoom o Google Meet. Está pensada para vivir por debajo.

Las herramientas más usadas (Cluely, Interview Coder, Leetcode Wizard) usan low-level graphics hooks: DirectX en Windows, Metal framework en macOS. Renderizan respuestas como un overlay invisible que se dibuja sobre el output del GPU, por debajo de la capa que captura el screen-sharing. El interviewer ve la pantalla del candidato “limpia”. El candidato ve la respuesta del LLM superpuesta a su IDE.

Cómo cheatean hoy los candidatos (Fabric, 19.368 entrevistas):

Método	% de casos	Detectable por Zoom/Meet
Asistentes dedicados (Cluely, Interview Coder)	45%	No
Voice mode LLMs (ChatGPT en segundo plano)	34%	Parcialmente
Tab switching / segunda pantalla	18%	Sí
Ayuda humana en vivo	3%	A veces

Los vendors de proctoring específico claman 85–95% de detección. Plausible para los flujos estándar, pero el arms race ya empezó: en 2025 aparecieron seis tools nuevas tipo Cluely y al menos tres clones open source. La detección siempre va a estar uno o dos pasos atrás.

¿Qué pasa si la solución no es atrapar al tramposo?

Esta es la parte incómoda. La narrativa dominante es “necesitamos mejor proctoring”. La narrativa correcta probablemente sea otra: rediseñar el assessment para que el cheating sea irrelevante.

Mirá el dato desde el otro lado. En 2026, según Dice, el 71% de los job postings tech en EE.UU. requiere alguna forma de AI fluency — un salto de 181% interanual. O sea: las empresas ya no quieren developers que codeen sin AI; quieren developers que codeen con AI. Si vas a contratar a alguien para que use Copilot todo el día, ¿por qué le hacés una entrevista que prohíbe usar Copilot?

Acá entra el formato “pair programming with AI”, que IEEE-USA describe como el reemplazo emergente del live coding clásico. La estructura típica tiene tres fases:

1. Problem decomposition. El candidato descompone un requirement ambiguo. El interviewer evalúa criterio analítico — no se puede falsear con un LLM porque la pregunta es discursiva.

2. AI-assisted implementation. El candidato implementa usando AI explícitamente permitida. Lo que el interviewer mira es cómo prompt-ea, cómo iteró, qué descartó. No el output.

3. Code review. El candidato revisa código generado por AI con bugs sembrados y los identifica.

Las tres etapas miden cosas que un overlay LLM no puede resolver por vos: criterio, comunicación, juicio. Y eliminan el incentivo al cheating porque la AI ya está en la mesa.

¿El take-home volvió a ser viable?

Sí — pero con una versión diferente del take-home de 2019. Según el State of Tech Hiring 2025 de CoderPad, 68% de las empresas ya incorporan take-home tests (+12% interanual), y 41% corre un modelo híbrido: take-home seguido de una review session en vivo donde el candidato defiende lo que entregó.

Definamos rápido: un take-home estructurado es un trabajo asincrónico de scope acotado (1–4 horas), con un objetivo de producto real (no un puzzle de algoritmos), seguido de una conversación de 30–45 minutos donde el candidato camina al interviewer por su solución, justifica decisiones y responde follow-ups.

El take-home estructurado funciona aun en mundo AI porque la pregunta deja de ser “¿escribió esto él/ella?” y pasa a ser “¿puede explicar cada decisión y responder qué hubiera hecho distinto?”. Si el código lo hizo Cursor y el candidato no lo entiende, se rompe en 5 minutos de defensa.

McKinsey, en su Technology Talent Report de 2025, encontró que las empresas que usan take-home estructurado tienen 41% menos early departures que las que usan solo entrevistas en vivo. La señal no es perfecta, pero es mejor.

¿Qué deberías cambiar en los próximos 90 días?

Tres movimientos concretos, en orden de impacto:

Primero, aceptar que la AI está en la entrevista. No prohibirla en una fase del proceso. Diseñar una fase donde explícitamente esté permitida y donde la observación sea sobre cómo la usa el candidato.

Segundo, reemplazar el algoritmo de pizarrón. Migrar el primer filtro técnico hacia un work sample corto (1–2 horas) que mire trabajo realista, no LeetCode.

Tercero, agregar la defensa en vivo. Cualquier take-home tiene que cerrar con 30 minutos de “explicame esto”, donde un overlay LLM no ayuda y donde un candidato real demuestra criterio.

El 38% no es un dato sobre candidatos. Es un dato sobre el formato de entrevista que estás corriendo. Mientras el formato siga siendo “resolveme este algoritmo en vivo en una IDE compartida”, el número va a seguir subiendo. Y la mitad de los que aprueben no van a saber por qué su código funciona.

Lo más caro de un mal hire no es el sueldo. Es lo que esa persona rompe los primeros seis meses antes de que te des cuenta. Si tu proceso de evaluación no separa señal de ruido en 2026, vas a pagar esa diferencia más veces de las que querés.