Preguntas de Entrevista Técnica a Prueba de IA: Lo Que Sigue Funcionando en 2026

El problema con "a prueba de IA"

Estrictamente hablando, ninguna pregunta de entrevista es completamente a prueba de IA. Un candidato decidido con un segundo monitor y un mecanógrafo rápido puede blanquear casi cualquier respuesta a través de un LLM. El objetivo realista no es la imposibilidad, sino la economía desfavorable: preguntas donde el coste de usar IA bien es mayor que el coste de solo responder.

Cuando el uso de IA deja de ser un atajo, deja de ser un problema. Los patrones siguientes son los que vemos que se mantienen en toda nuestra biblioteca de evaluaciones y en los procesos de entrevista de nuestros clientes en 2026.

Patrón 1: Ancla cada pregunta en un fragmento de código que el candidato debe leer primero

Un prompt independiente —"escribe una función que haga X"— está en el conjunto de entrenamiento. Un prompt que depende de 80 líneas de código que el candidato nunca ha visto no lo está.

Forma concreta:

• Proporciona un pequeño repositorio o archivo (40-200 líneas).
• Haz una pregunta cuya respuesta requiera entender ese código específico: "¿qué pasaría si dos solicitudes golpean processOrder concurrentemente con el mismo id de pedido?"
• Luego pide una corrección.

Un LLM sin vista del archivo puede adivinar una respuesta genérica. Un candidato que ha leído el código puede dar una específica. La brecha entre los dos es la señal.

Esta es la misma lógica detrás del formato fix-the-codebase, aplicada a la redacción de preguntas en lugar de al formato de preguntas.

Patrón 2: Requisitos ambiguos que castigan la codificación prematura

Los LLM están entrenados para producir soluciones confiadas y de apariencia completa. Son malos para lidiar con la ambigüedad. Las preguntas que recompensan hacer preguntas aclaratorias antes de escribir código seleccionan naturalmente contra el pegado de IA.

Ejemplo de prompt: "Queremos añadir una función de 'marcar como favorito' en nuestra aplicación de notas. Explícame cómo la construirías."

Un ingeniero senior pregunta: ¿por usuario o global? ¿Sincronización entre dispositivos? ¿Se mantiene el orden? ¿Qué pasa cuando se elimina una nota? Cada pregunta aclaratoria es señal. Una respuesta pegada de IA salta directamente a un esquema de tabla favorites y nunca expone un solo compromiso.

Puntúa el número de aclaraciones significativas antes del código, no solo el código. Este es el mismo principio detrás de una rúbrica de diseño de sistemas que no premia palabras clave, ambos castigan respuestas que suenan confiadas pero son ciegas al contexto.

Patrón 3: Preguntas de seguimiento que requieren propiedad de la respuesta anterior

El movimiento más resistente a la IA en cualquier entrevista es el seguimiento en vivo. Un LLM puede escribir código. No puede hacer un seguimiento de su propio código en tiempo real, con el entrevistador observando.

Patrones de seguimiento útiles:

• "¿Por qué elegiste un mapa hash aquí? ¿Qué cambiaría si las entradas estuvieran ordenadas?"
• "Explícame qué sucede si esta función se llama desde dos hilos."
• "Voy a cambiar los requisitos: en lugar de un usuario, son un millón. ¿Qué se rompe primero?"
• "Escribiste const result = x ?? 0. ¿Cuál es la diferencia entre ?? y || aquí?"

Los candidatos que escribieron su propio código pueden improvisar sobre él. Los candidatos que pegaron pueden responder usualmente un seguimiento, a veces dos, y luego colapsan. Tres seguimientos es un filtro casi perfecto, y el mismo manual que funciona en envíos para llevar funciona dentro de rondas en vivo.

Patrón 4: Preguntas con restricciones novedosas, no temas novedosos

No necesitas un algoritmo exótico para derrotar la memorización del conjunto de entrenamiento. Necesitas un pequeño giro en un problema familiar. El giro fuerza el razonamiento real en lugar del recuerdo basado en patrones.

Giros concretos que funcionan:

• Una forma de datos personalizada ("la entrada es un flujo de objetos {userId, eventType, ts}, no una matriz de enteros").
• Un modelo de coste inusual ("las lecturas son gratuitas, las escrituras cuestan 100x, diseña en consecuencia").
• Una restricción que invierte la solución obvia ("no puedes usar ninguna estructura basada en hash").
• Una dimensión del mundo real ("la función se ejecutará en una Lambda con un límite de memoria de 6 MB").

El problema clásico ("encontrar duplicados") está en los datos de entrenamiento de cada modelo. El mismo problema con eventos de {userId, ts} y un límite de memoria no lo está, al menos no en una forma que el modelo pueda pegar directamente. El candidato tiene que adaptarse, y la adaptación es la habilidad por la que realmente estás contratando.

Patrón 5: Preguntas "Explica un compromiso que has hecho personalmente"

Las preguntas puras de elicitación de experiencia son extremadamente difíciles de fingir sobre la marcha. El LLM puede generar una historia de guerra que suena plausible; no puede hacer que la historia sea específica para un sistema que este candidato realmente envió, y definitivamente no puede responder cuatro seguimientos dirigidos sobre ese sistema específico.

El patrón:

1. Haz una pregunta de compromiso: "Cuéntame sobre una vez que elegiste una solución peor sobre el papel porque la mejor era incorrecta para el contexto."
2. Después de que respondan, pregunta: "¿Cuál era la métrica que estabas optimizando?"
3. Luego: "¿Cuál fue el argumento más fuerte en contra de tu elección?"
4. Luego: "¿Qué harías diferente ahora?"

Combinadas con una rúbrica de comportamiento estructurado, estas preguntas son casi imposibles de fingir con la resolución en que las entrevistas realmente se ejecutan. El candidato que realmente envió el sistema responde en 90 segundos. El candidato que está pidiendo ChatGPT en otra pestaña tarda 30 segundos en empezar, da una respuesta genérica y falla el segundo seguimiento.

Lo que no funciona en 2026

Para ser completamente exhaustivos, los patrones que ahora son mayormente señales muertas:

• Prompts de algoritmo al estilo LeetCode clásico — pegados en cualquier LLM, resueltos en segundos.
• "Escribe una función que…" sin código circundante — mismo problema.
• Preguntas de trivia sobre lenguaje ("¿cuál es la diferencia entre let y var?") — resuelta por el primer token del modelo.
• Prompts "Diseña Twitter" / "Diseña Uber" — cada canal de preparación de entrevistas de YouTube cubre estos, y cualquier LLM devolverá la arquitectura de referencia.

Si tu ciclo actual se basa en estos, tu señal de contratación se está degradando tanto si lo has notado como si no. Cubrimos la pregunta más amplia de si las evaluaciones de codificación siguen funcionando con IA en otro lugar, la respuesta corta es sí, pero solo si rediseñas las preguntas.

Empareja diseño con detección

Incluso las preguntas bien diseñadas se benefician de una segunda capa. Calificamos cada evaluación con biometría de pulsaciones para patrones de ráfagas de pegado y ejecutamos una pasada de coherencia de LLM en el envío final. El punto no es atrapar a cada estafador, es eliminar el camino fácil para que los candidatos se autoseleccionen hacia hacer el trabajo real.

Si quieres la taxonomía completa de señales, el informe de integridad explicado recorre qué exponemos y cómo leerlo.

Qué hacer a continuación

Audita tu banco de preguntas actual contra los cinco patrones anteriores. Cualquier cosa que:

1. No tiene código o contexto que leer antes de responder,
2. Tiene una única solución de libro de texto "correcta",
3. No puede ser seguida durante tres rondas, o
4. Es reconociblemente un problema de referencia de Big Tech,

ahora es una pregunta de baja señal. Reescríbela o retírala. Reemplázala con una pregunta que sea anclada, ambigua, amigable para seguimiento, retorcida, o impulsada por la experiencia, idealmente varias a la vez.

Los equipos cuya señal de contratación se mantiene en 2026 son los equipos que hicieron este trabajo en 2024 y 2025. Los equipos que se quejan "los candidatos pasan nuestra entrevista y no pueden codificar el primer día" en su mayoría no lo han hecho.