DEV Community: ITInterviewCoach

Los detectores de IA en las entrevistas están peleando la guerra equivocada

ITInterviewCoach — Wed, 26 Aug 2026 10:59:34 +0000

Lo digo como alguien que está construyendo IA para entrevistas

Ahora mismo hay una carrera en el mundo de la contratación: las empresas añaden proctoring a las entrevistas, detectores de IA, piden una segunda cámara y que desactives todo lo que no sea necesario. Todo el mundo intenta descubrir si el candidato está usando ChatGPT en otra ventana.

Yo estoy desarrollando un entrenador basado en IA para preparar entrevistas técnicas. En teoría, debería estar a favor de esta carrera.

Pero creo que ya estaba perdida antes de empezar.
Porque, en el fondo, estamos peleando la guerra equivocada.
Voy a explicar por qué con una entrevista que hice hace un par de años.

El banco y el falsificador

Cualquier detector es una historia entre un banco y un falsificador.

El banco inventa una nueva medida de seguridad. Al cabo de un tiempo, el falsificador encuentra la forma de sortearla. Entonces el banco inventa otra.

No hay una victoria definitiva. Es una carrera infinita en la que quien defiende siempre va un paso por detrás, porque reacciona en lugar de mover primero.

Con los detectores de IA en las entrevistas pasa exactamente lo mismo.

Hoy detectas a alguien por las pausas antes de responder o por sus ojos moviéndose de un lado a otro. Mañana aparece una herramienta que suaviza ambas cosas. Pasado mañana, un modelo responde en tiempo real con la voz del candidato.

Esa carrera no se puede ganar.
Solo puedes ir eternamente por detrás.

Por eso no me interesa detectar IA. Me interesa detectar algo que no dependa de qué herramienta haya utilizado el candidato: si realmente tiene la experiencia de la que habla o no.
Y eso se detecta de una forma completamente distinta.

El candidato que respondió a todo

Hace un par de años me pidieron que hiciera una entrevista técnica para un equipo que no era el mío. Otro departamento tenía prisa por cubrir una vacante y acepté encargarme de la parte técnica.

El candidato respondía. A todo.

No dijo "no lo sé" ni una sola vez. Nunca se quedó bloqueado de una forma que me permitiera escribir honestamente: "no da el nivel".

Formalmente, no había nada que objetar.

Terminé la entrevista y escribí un feedback que ni yo mismo esperaba de mí:

"Respondió a todas las preguntas. No me creo su experiencia. No lo recomiendo".

No voy a fingir que sé qué ocurrió realmente.

Tal vez estaba copiando las respuestas.
Tal vez había memorizado las respuestas de otra persona.
Tal vez se atribuyó un proyecto en el que nunca había trabajado.
O tal vez simplemente se vendió mal y yo me equivoqué.

No tengo pruebas.

Y precisamente ahí está la cuestión.

El trabajo de un entrevistador no es emitir un certificado de que alguien mintió. Es responder honestamente a una pregunta mucho más simple:
¿me creo que esta persona tiene la experiencia que dice tener?

Y hay una señal que, para mí, pesa mucho a la hora de responderla.

Los nervios no son una señal

Primero, hablemos de lo que NO fue una señal: los nervios.

Una persona puede trabarse, perder el hilo o repetirse, y eso no dice absolutamente nada sobre su experiencia.

Reducir la tensión es una responsabilidad directa del entrevistador.

Si el candidato se bloquea por estrés y tú permaneces sentado con cara de piedra marcando casillas, no estás evaluando a un profesional. Estás evaluando su capacidad para actuar bajo los focos.

A mí eso no me interesa.
Por cierto, aquel candidato estaba tranquilo.
El problema no eran los nervios.

Lo que realmente delata algo

La distribución de los detalles.

Cuando hacía preguntas abiertas en las que esperaba información concreta —"háblame de este proyecto", "¿dónde te encontraste con un problema?", "¿qué decidiste al final y por qué?"— recibía explicaciones generales.
Fluidas. Correctas.

"Optimizamos el pipeline, analizamos las métricas, discutimos diferentes enfoques con el equipo..."

Pero sin detalles.
Ni un solo:

"En este punto vimos una degradación, empezamos a investigar y descubrimos que el problema estaba aquí"

Sin embargo, cuando hacía una pregunta cerrada, en la que bastaba con un «sí» o un «no» y una breve explicación, empezaba un monólogo.
Un minuto. Dos minutos. Donde alguien con experiencia real habría dicho:

"Sí, lo usamos por esto"

Y se habría callado.
Esa inversión es la señal.

Una persona que realmente ha hecho aquello de lo que habla suele funcionar al revés: es breve con lo general y detallada con lo suyo.

Su propia experiencia no la recuerda como una definición memorizada. La recuerda porque la vivió.

No tienes que insistir demasiado para que profundice. Empiezan a aparecer detalles que son difíciles de inventar sobre la marcha.

Y las preguntas generales tampoco le asustan. No hay nada concreto que defender.

Cuando alguien no habla desde la experiencia, la imagen suele invertirse.

Lo general suena seguro porque es fácil generar una respuesta general. Con tus propios conocimientos, con un artículo que leíste ayer o con cualquier modelo de IA.

Pero cuando llegas a un proyecto concreto, aparece la niebla.

Porque no hay detalles.
Y si no hay detalles de dónde tirar, solo queda llenar el silencio con más palabras.

Es importante señalar algo: esto no tiene que ver específicamente con la IA.

La misma señal puede aparecer tanto en alguien que está leyendo respuestas de una pantalla en ese momento como en alguien que memorizó la experiencia de otra persona hace diez años, cuando todavía no existían estos modelos.

Por eso una nueva versión de una herramienta no puede eliminar el problema.

Solo hay una forma fiable de superar preguntas que profundizan de verdad en tu experiencia: tener realmente esa experiencia.

Lo mismo ocurre con el CV

El mecanismo es parecido cuando lees un currículum.

La gente suele discutir sobre líneas concretas: si una métrica redonda queda bien o mal, si conviene escribir "mejoré el rendimiento un 50 %".

Pero una sola línea no miente.
Lo que puede no cuadrar es la coherencia del conjunto.
Cada punto, por separado, puede parecer perfectamente plausible.

Un recién graduado entra directamente en una gran empresa y mejora el procesamiento de datos en un 50 %. Puede pasar.

Tres meses después deja el trabajo y desaparece del mercado durante un tiempo. También puede pasar.

Dos años más tarde entra en una empresa pequeña. Nada imposible.

Pero cuando leo toda la trayectoria seguida, desde el primer trabajo hasta el último —sí, a diferencia de lo habitual, prefiero leer de la experiencia más antigua a la más reciente para entender la trayectoria y no solo la última versión pulida del perfil, a veces se acumulan demasiados "¿esto no es un poco raro?".

Y llega un punto en el que el CV deja de resultar convincente.

Con las métricas ocurre algo parecido.
Una cifra espectacular rodeada de resultados más modestos puede ser perfectamente creíble.

Pero si cada logro es exactamente cinco veces mejor que el anterior, no me impresiona. Me da una razón para profundizar.

Los resultados reales son irregulares.

Una mejora perfecta y constante en cada línea empieza a parecer más una plantilla que una trayectoria real.

Dónde sí puede ser útil la IA en una entrevista

Para que no parezca que estoy en contra de cualquier uso de IA en contratación: no lo estoy.

Los sistemas de transcripción me parecen una herramienta excelente.

Después de una entrevista, ambas partes pueden revisar lo que realmente se dijo, en lugar de confiar en su propia versión de la conversación una semana después.

Eso beneficia a todos.
Con los summarizers tengo más dudas.

He probado varios y, en algunos casos, distorsionaban tanto la conversación que el resultado parecía el resumen de una entrevista completamente diferente.

Yo no confiaría en ellos para tomar una decisión importante sobre un candidato.

Los detectores y el proctoring, en cambio, me recuerdan al banco y al falsificador. La protección cambia. Quien quiere hacer trampa se adapta.

Y el ciclo vuelve a empezar.

A mí me interesa mucho más una entrevista que se parezca a una conversación entre dos colegas durante un café.

No un interrogatorio delante de varias cámaras.

Una conversación normal en la que la persona pueda hablar con tranquilidad sobre lo que realmente ha hecho.

En ese contexto, la distribución de los detalles aparece por sí sola.
Puedes copiar una definición.

Pero no puedes contar cómo pasaste una semana buscando un bug que parecía no existir y al final descubriste que el problema eran las zonas horarias... si nunca pasaste esa semana buscándolo.

La preparación que no queda obsoleta con el próximo modelo

Eso es exactamente lo que estoy intentando construir con mi proyecto en Telegram: ITInterviewCoach_bot.
No quiero crear otro sistema basado en:

"Memoriza las respuestas correctas"

Quiero que las personas se acostumbren a razonar en voz alta sobre su propia experiencia, de una forma que aguante preguntas cada vez más profundas.

Porque esa es la única preparación que no perderá valor con el próximo lanzamiento de otro modelo de IA.

No importa de qué lado de la mesa esté.

Los logros los dibujó mi novia. Los eliminé.

ITInterviewCoach — Fri, 14 Aug 2026 19:07:15 +0000

Una historia honesta como desarrollador en solitario: el detonante, los tropiezos técnicos, la trampa clásica de todo fundador, y un hallazgo que no esperaba.

La conversación que lo empezó todo

Hace unos meses, un conocido me escribió por LinkedIn. Llevaba medio año buscando trabajo, actualizaba su CV todos los días, y no dejaba de quejarse del mercado y de los reclutadores. Le ofrecí ayuda: le pasé su CV a un reclutador que conozco. El rechazo llegó casi al instante — su experiencia no encajaba con el puesto. Y lo curioso es que él lo sabía perfectamente, lo habíamos hablado — pero eso no aparecía en su CV.

Se lo dije directamente. Me escuchó… y siguió quejándose del mercado y de los reclutadores.

Lo que me sorprendió no fue que culpara a factores externos — eso es de lo más normal. Lo que me sorprendió fue que no lograba conectar la causa con el efecto en una situación que acababa de pasar delante de sus propios ojos.

Y no fue un caso aislado. Empecé a notar un patrón: gente con experiencia real que pierde sistemáticamente en los procesos de selección — no porque sean malos profesionales, sino porque no saben describir ni presentar esa experiencia.

De dónde salió la idea

Yo mismo me preparaba para entrevistas usando distintos modelos de lenguaje. Funcionaba, pero con limitaciones molestas: los modelos perdían el contexto a mitad de la sesión, la calidad de las preguntas variaba de una vez a otra, y no había ninguna estructura de feedback.

Decidí unir dos herramientas en una: análisis de CV — para llegar a la entrevista — y un entrenador de entrevistas — para superarla. Cuatro modos: entrenamiento por stack y grado, por temas concretos, análisis profundo de la experiencia a partir del CV, y live coding al estilo de una entrevista real.

Formato: bot de Telegram. Sin registro, sin app nueva que instalar. Solo /start.

El primer tropiezo: CVs y GDPR

El primer problema técnico apareció donde menos lo esperaba: en el parseo de los CVs.

Desde el inicio tomé una decisión de principio — no guardar los archivos de los usuarios. Esto reduce el riesgo con datos personales, simplifica la arquitectura y elimina de raíz toda una categoría de preguntas sobre GDPR. El archivo se procesa, se extrae lo necesario, y se elimina.

El problema: al borrar los datos personales del texto, junto con nombres y contactos se estaban recortando también cargos y nombres de empresas. Las expresiones regulares o se pasaban de listas o dejaban cosas sin limpiar. Necesité varias iteraciones hasta que el comportamiento se volvió predecible.

La lección es simple pero útil: en procesamiento de texto, la solución "obvia" casi siempre rompe algo que no lo era.

La parte más difícil: encontrar el tono correcto

Técnicamente, el bot funcionaba con relativa fluidez. Lo verdaderamente difícil fue otra cosa.

Los modelos de lenguaje, en el rol de coach, tienden a comportarse todos igual: elogian cualquier respuesta, evitan la crítica directa, suavizan cada observación hasta que pierde sentido. Es agradable, pero inútil. Una entrevista real no funciona así.

Pero el extremo contrario — un análisis duro después de cada respuesta — tampoco era la solución. Desmotiva y no refleja el formato real.

Hice cientos de sesiones a mano: respondía yo mismo las preguntas y observaba cómo reaccionaba el bot ante distintos tipos de respuestas — completas, superficiales, parcialmente correctas, incorrectas pero dichas con total seguridad. Esto no se podía delegar: los agentes tienen sus propios patrones de comportamiento, no son usuarios reales.

Al final encontré el equilibrio: si la respuesta está incompleta, el bot hace una pregunta de seguimiento en vez de evaluar de inmediato, y el análisis final es concreto y sin rodeos, pero sin dureza innecesaria. Esto me llevó más tiempo que el resto de la parte técnica junta.

La trampa clásica en la que caí de todos modos

Hay un error que conoce cualquier desarrollador de producto con experiencia. Yo también lo conocía. Y aun así caí en él.

Funciona así: aparece una idea que parece obviamente buena. Tu cabeza ya visualiza cómo va a funcionar, cómo la gente la va a amar. No quieres parar — quieres construir. Y construyes.

Implementé varios bloques de funcionalidad que en su momento me parecían extensiones lógicas del producto. Los testers lo dejaron claro: no hace falta, satura, no se entiende. Todo eso tuvo que salir.

Lo más doloroso de eliminar fue la gamificación con logros: insignias por progreso, todo un sistema visual de recompensas. Los logros los había dibujado una diseñadora — a mano, uno para cada escenario. Preciosos.

Las pruebas mostraron que distraía del flujo principal y añadía complejidad justo donde no debía haberla. Lo eliminé.

Tengo la esperanza de retomarlo algún día, pero con otro enfoque: primero entender si los usuarios realmente lo necesitan, y solo después ponerse a dibujar.

El hallazgo que no estaba buscando

Durante las pruebas empecé a medir el consumo de tokens en distintos tipos de diálogo. Encontré algo que no esperaba: según el idioma en el que estuvieran escritas, las mismas instrucciones de sistema podían consumir entre un 18% y un 40% más tokens. Esperaba una diferencia de hasta un 20%, no tanto.

Esto se explica por cómo los tokenizadores de los modelos de lenguaje actuales manejan distintos alfabetos: hay idiomas cuyo texto, en promedio, se divide en más tokens que otros para transmitir el mismo contenido. Para mensajes cortos la diferencia es insignificante. Para prompts de sistema, que se envían en cada solicitud, se nota bastante.

Reescribí todas las instrucciones de sistema en el idioma más eficiente en tokens. Solo quedaron algunos ejemplos puntuales en otro idioma, donde la formulación exacta era importante. Los usuarios no notan nada de esto — el bot sigue generando las respuestas en el idioma de cada usuario de todas formas.

El momento que se me quedó grabado

Uno de los primeros usuarios reales me escribió después de varias sesiones:

«La verdad es que entrena muy bien dar respuestas más completas. Y también la habilidad de presentarte a ti mismo.» — Uno de los primeros usuarios

Esto no habla de las funciones del producto. Habla de que algo cambió en cómo esa persona piensa y habla sobre su trabajo. Era justo lo que quería lograr desde el principio — solo que no estaba seguro de conseguirlo.

Lo que sé ahora

Algunas cosas que no esperaba aprender en el camino:

La parte más difícil de un producto con IA no es la arquitectura ni los prompts. Es encontrar el tono correcto entre la honestidad y la dureza. Eso no se le puede enseñar al modelo directamente — solo se llega ahí iterando a mano.
Las decisiones tomadas por principio suelen resultar técnicamente correctas. No guardar los archivos de los usuarios no es solo una cuestión de seguridad — es simplicidad arquitectónica.
Detenerte y eliminar algo en lo que invertiste tiempo es una habilidad. No llega sola, aunque hayas leído sobre ella mil veces.
El primer feedback real vale más que cualquier analítica al inicio. Es lo que te dice si diste con una necesidad real o no.