Todo el que vende software de entrevistas está corriendo en este momento a lanzar la misma función: un detector de trampas con IA en entrevistas de programación. Análisis de tecleo. Detección de pegado. Proctoring por webcam. Pequeñas "puntuaciones de perplejidad" que dicen saber si fue un humano quien escribió el código de tu candidato.
Entiendo el instinto. Dirijo una empresa de evaluaciones, y alguna versión de "¿pueden atrapar a los tramposos?" aparece en la mayoría de las conversaciones que tengo con líderes de ingeniería. Pero creo que la detección es una guerra que pierdes lento y caro. Peor aún: apunta al blanco equivocado. La pregunta útil no es "¿usaron IA?". Es "¿qué tan bien la usan?".
Si eres el responsable de contratación de un equipo de ingeniería en crecimiento y desde hace dos años sientes que tus filtros no cuadran, este es mi argumento para cambiar la pregunta en lugar de comprar un mejor detector.
La carrera armamentista de detección que no puedes ganar
La detección asume que hay una línea limpia entre el trabajo del candidato y el trabajo de la IA. Esa línea ya no existe. Un ingeniero escribe un prompt, lee tres sugerencias, rechaza dos, edita la tercera y la entrega: hizo el trabajo. ¿Qué parte era la trampa?
Luego está la mecánica. La detección de pegado muere en el momento en que alguien teclea en lugar de pegar. El análisis de tecleo marca como sospechosos a los que escriben rápido y a los candidatos neurodivergentes. El proctoring empuja en silencio a tu mejor gente fuera del embudo, porque nadie con opciones quiere que lo filmen por webcam durante una hora. Y cada una de estas herramientas se vuelve menos confiable cada vez que sale un modelo nuevo, mientras que los candidatos que menos quieres son exactamente los que tienen motivación para esquivarlas.
Así que terminas pagando por un sistema que acusa a la gente que quieres y deja pasar a la que no. Yo no llamaría a eso un filtro.
Una aclaración rápida antes de seguir. Estoy construyendo Skillvee, una simulación de 60 minutos de un "día de trabajo" que reemplaza el filtro telefónico del recruiter y la primera ronda técnica. Los candidatos resuelven un desafío real, hablan con compañeros de IA y defienden sus decisiones ante un gerente de IA mientras se graba la pantalla. En una sola evaluación ves cómo un candidato programa, se comunica, colabora, actúa con autonomía y aprovecha la IA, antes de que cualquier ingeniero senior invierta una hora de entrevista. Así que sí, tengo un caballo en esta carrera. El argumento debería sostenerse por sí solo, pero mereces saber que el caballo existe.
Lo que el filtro debía decirte
Olvida la IA por un segundo. ¿Para qué servía el take-home o la prueba de código, en primer lugar?
No para responder "¿puede esta persona teclear un algoritmo?". Eso ya lo sabías, en buena medida, por el currículum y el GitHub. El filtro era un proxy de una sola pregunta: si esta persona va a ser buena en mi equipo. Y las pruebas de código siempre fueron un proxy débil de eso, porque las cosas que lo deciden nunca estuvieron en la prueba.
Piensa en tu última mala contratación. ¿El problema fue el código? Casi nunca. El problema fue la persona que se quedó tres días en silencio cuando se atascó. O la que entregó sin hacer la única pregunta aclaratoria que obviamente hacía falta. O la que esperó a que le dijeran cuál era el siguiente paso, todas y cada una de las veces. Esas son las sorpresas post-contratación que te cuestan seis meses y volver a cubrir la vacante, y ninguna aparece en una puntuación de código, con o sin IA en la ecuación.
La IA no rompió tu filtro. Rompió la excusa de tu filtro. La estrechez siempre estuvo ahí. La IA solo hizo imposible seguir fingiendo lo contrario.
La mejor pregunta: ¿qué tan bien usan la IA?
Asume que todos los candidatos usaron IA, igual que asumes que usaron un IDE y un buscador. Permítelo. Hazlo visible. Y luego mide lo que de verdad separa a la gente hoy: el criterio frente a la máquina.
Esta es la parte que me sorprendió viendo sesiones reales: la IA no comprime el rango de calidad de los candidatos. Lo estira. Dale a todos el mismo modelo y la brecha entre tus mejores y peores candidatos se hace más ancha, no más angosta.
Un candidato débil toma la primera respuesta del modelo y sigue adelante. Uno fuerte la trata como a un ingeniero junior rápido y seguro de sí mismo que miente de vez en cuando. Escribe prompts con precisión, contrasta el output contra lo que realmente se pidió, atrapa la sugerencia plausible pero incorrecta, y puede decirte después por qué la versión final se ve como se ve.
Un detector no puede ver nada de eso. De hecho, es peor: un detector lee al candidato fuerte como más sospechoso, porque usó más la IA. La diferencia solo se vuelve visible cuando la IA es parte de la evaluación y puedes ver el trabajo suceder. Eso es lo que significa "aprovechamiento de IA" como señal de contratación. Lo prefiero antes que una puntuación de código en condiciones de laboratorio para cualquier puesto que esté contratando este año, porque se parece más al trabajo real.
Las seis dimensiones de señal antes del onsite
Si reemplazas la detección con observación, necesitas saber qué estás observando. Esta es la lista con la que nos quedamos después de discutir mucho sobre qué predice de verdad el desempeño. Un buen filtro previo al onsite saca a la luz las seis en una sola sesión.
| # | Dimensión | Qué te dice |
|---|---|---|
| 1 | Calidad de código + criterio técnico | Qué entregan y qué trade-offs hacen |
| 2 | Comunicación | Cómo explican su razonamiento y hacen preguntas aclaratorias |
| 3 | Colaboración | Cómo consiguen contexto y trabajan dentro de las restricciones |
| 4 | Autonomía | Si empujan el trabajo o esperan instrucciones |
| 5 | Aprovechamiento de IA | Qué tan bien hacen prompts, verifican y corrigen el output de la IA |
| 6 | Criterio + gestión del tiempo | Cómo priorizan bajo presión realista |
Una prueba de código mide la primera fila, y hoy la mide mal. Un onsite cubre la mayoría de las filas, pero cuesta unas cinco horas de ingeniero senior por candidato. La brecha entre esas dos cosas es toda la oportunidad: medir las seis antes del onsite, para que a tu equipo solo llegue gente que vale el tiempo de tu equipo.
Cómo se ve esto en una sesión real
Imagina dos candidatos con la misma tarea: extender un servicio pequeño, las herramientas que quieran, un compañero de IA disponible para preguntas, un gerente de IA que revisa la decisión al final.
El candidato A le pide al compañero de IA la implementación completa, la pega, ve los tests pasar y envía. Cuando le preguntan por qué eligió esa estructura de datos, no tiene respuesta. Código limpio, sin criterio detrás.
El candidato B empieza con una pregunta de alcance. Nota que el enfoque generado omite un caso que el brief daba a entender, lo corrige, y cuando el manager lo cuestiona, explica el trade-off en una sola oración.
Mismas herramientas, misma hora, contrataciones completamente distintas. En un detector estos dos se ven idénticos. En todo caso, B se ve peor, porque usó más la IA. Observados en las seis dimensiones, el ranking es obvio y correcto. Esa inversión es todo el argumento.
Cómo montar tú mismo un filtro abierto a la IA
No nos necesitas para los principios. Si estás reconstruyendo tu primera ronda este trimestre:
- Di en voz alta lo que todos callan. Diles a los candidatos que usen lo que usarían en el trabajo. Una vez que la IA está permitida, esconderla deja de tener sentido, y por fin puedes observar comportamiento real.
- Usa una tarea real. Invertir una lista enlazada no te dice nada sobre cómo alguien trabaja con IA. Una porción acotada de trabajo real sí.
- Graba el proceso, no solo el resultado. La señal vive en cómo llegaron ahí. Califica solo el artefacto final y vuelves a estar calificando a la IA.
- Define qué es "bueno" en las dimensiones que no son código antes de la sesión. Comunicación, autonomía, uso de IA. Si no lo escribes de antemano, vas a puntuar por vibras, y las vibras no se calibran entre entrevistadores.
- Haz que defiendan una decisión. Un "¿por qué lo hiciste así?" de dos minutos separa a quien entendió su trabajo de quien solo lo transportó.
Dónde se pone difícil
Voy a ser honesto sobre los costos, porque los hay.
Diseñar una tarea realista exige esfuerzo real. Una simulación floja es solo un take-home con pasos extra, y los candidatos se dan cuenta. La tarea tiene que tener suficiente ambigüedad para que la autonomía y la comunicación de verdad aparezcan.
Puntuar seis dimensiones de forma consistente también es trabajo. Un solo hiring manager evaluando grabaciones a ojo se va a ir descalibrando. Necesitas o una rúbrica escrita que tu equipo de verdad siga, o herramientas que puntúen contra una. Y si tus entrevistadores no van a ver las grabaciones ni a leer los informes, construiste una señal que nadie consume, que es lo mismo que ninguna señal.
Nada de esto cambia la dirección. Cambia la matemática de construir versus comprar, una decisión que deberías tomar con los ojos bien abiertos respecto al ancho de banda de tu equipo.
Pero haz el trabajo y "¿están haciendo trampa?" deja, en gran medida, de ser una pregunta. No queda trampa posible. La IA es la herramienta esperada, y estás midiendo lo que siempre fue el punto: cómo trabaja esta persona.
Esa es la apuesta detrás de cómo funciona Skillvee, y es la razón de que nuestros precios sean por volumen y no por asiento con proctoring. La detección grava lo equivocado. Ver a la gente trabajar es el producto.