Cómo escribir preguntas de entrevista técnica resistentes a la IA

La premisa ha cambiado

A mediados de 2026, la pregunta interesante no es si el candidato tiene ChatGPT abierto. Es si tu entrevista mide algo una vez que lo hace. La mayoría de equipos reaccionaron acumulando detección — biometría de pulsación, indicadores de pegado, puntuación de coherencia de código. La detección ayuda. El diseño de preguntas ayuda más. Un problema que una LLM resuelve en ocho segundos no te dice nada sobre la persona detrás del teclado, por mucho que señalices el pegado.

Esta es una guía de campo para escribir preguntas de entrevista técnica que sigan produciendo señal cuando se asume asistencia de IA.

Qué hace que una pregunta sea fácil para una LLM

Tres propiedades juegan en tu contra:

1. Aparece en el corpus de entrenamiento. LeetCode, HackerRank, Codeforces, repositorios trending de GitHub — todo está en los pesos. Si tu pregunta tiene un nombre con forma de Wikipedia (Two Sum, Word Ladder, Longest Increasing Subsequence), asume que la respuesta está memorizada.
2. La especificación completa se entrega de inicio. Un prompt completo y sin ambigüedades es exactamente la forma en que se entrena a una LLM para consumir. El modelo no necesita nada del candidato.
3. El resultado es de forma cerrada. Una función con una entrada, una salida, una respuesta correcta es trivialmente calificable — y trivialmente generable.

LeetCode #1 cumple los tres. También lo hace la mayoría de la biblioteca de preguntas que heredaste.

Principio de diseño 1: Oculta la especificación, expón el síntoma

En lugar de "implementa una función que devuelva la subcadena más larga sin caracteres repetidos," dales al candidato un caso de prueba fallido y un reporte de error vago: "Los clientes ven artículos duplicados en su carrito después de que se ejecuta este endpoint. Aquí hay una entrada fallida. Arréglalo."

El candidato ahora tiene que:

• Leer el código existente
• Formar una hipótesis sobre qué está mal
• Decidir qué significa "correcto"

El modelo aún puede ayudar — pero solo después de que el candidato encuadre el problema. Enmarcar el problema es la habilidad que querías medir de todas formas.

Principio de diseño 2: Entrega la base de código, no el prompt

Reemplaza acertijos independientes con un pequeño repositorio. 100–300 líneas, múltiples archivos, uno o dos errores intencionales, un README escaso. Pregunta: "Encuentra el error que causa el 500 en POST /orders y corrígelo."

Un modelo que no ha visto tu repositorio no es mejor en esto que el candidato. Adivinará de forma plausible y confiada — y estará equivocado — porque la respuesta está en el código circundante, no en el prompt.

Este formato también sirve como entrevista libre de LeetCode para equipos que quieren medir ingeniería real en lugar de velocidad de acertijos.

Principio de diseño 3: Incluye un giro a mitad de pregunta

A mitad de camino, cambia el requisito. "Ahora el cliente quiere soportar reembolsos parciales — extiende tu solución." O: "Este endpoint ahora necesita ser idempotente. ¿Qué cambia?"

El giro hace tres cosas:

• Obliga al candidato a demostrar que entiende su propio código (un pegado fresco de una ventana de chat no puede).
• Expone instintos arquitectónicos que una solución de un solo paso oculta.
• Hace obvio el uso de prompts a un modelo a mitad de la entrevista — el candidato se detiene, pide algunos minutos, o produce un segundo pegado limpio que no se parece al primero. Todo lo cual se convierte en señal en el reporte de integridad.

Principio de diseño 4: Pide criterio, no salida

Algunas de las preguntas con mayor señal no tienen código para escribir en absoluto:

• Ejercicios de revisión de código. Entrega un diff de 60 líneas. Pídele al candidato que deje comentarios como si fuera el revisor en un PR. Las LLMs producen revisiones de código sinceras y genéricas ("considera añadir un comentario aquí"). Los ingenieros senior producen crítica específica y priorizada ("este bloqueo se mantiene durante la llamada de red — eso causará un deadlock bajo carga").
• Conversaciones sobre tradeoffs. "Tienes dos opciones para esta invalidación de caché. ¿Cuál elegirías y por qué?" El candidato tiene que defender una elección. El modelo no tiene nada en juego y se cubrirá las espaldas.
• Leer un PR desconocido. "Explícame qué hace este cambio y qué podría salir mal."

Estos se agrupan mejor con rúbricas de diseño de sistemas que con tarjetas de algoritmos. Califícalos por el razonamiento, no por el veredicto.

Principio de diseño 5: Restricciones novedosas sobre problemas novedosos

No necesitas inventar una nueva clase de problema. Solo necesitas una restricción inusual en uno familiar.

• "Implementa un rate limiter — pero el reloj puede correr hacia atrás hasta 30 segundos por culpa de la deriva NTP."
• "Construye una cola — pero enqueue debe ser O(1) en el peor caso, no amortizado, porque ejecutamos esto en un bucle de control de tiempo real duro."
• "Analiza este archivo de configuración — pero la especificación evoluciona. Muéstrame cómo manejarías la compatibilidad hacia atrás tres versiones adelante."

Las LLMs pueden resolver estos. A menudo se pierden la restricción. El candidato que la detecta, pregunta sobre ella, y diseña alrededor de ella es el candidato que quieres.

Qué no hacer

Algunas reacciones comunes que tienen efecto contraproducente:

• Prohibir IA sin cambiar la pregunta. Perderás candidatos principales que ya usan IA bien, mantendrás a los tramposos que no les importan tus reglas, y no aprenderás nada nuevo.
• Hacer problemas gratuitamente difíciles para "adelantarse" al modelo. La dificultad adversarial selecciona para gente dispuesta a trabajar bajo presión, no para gente que puede hacer el trabajo. La tasa de aprobación se desploma y el embudo se atasca.
• Cambiar todo a entrevistas en pizarrón / sin laptop. Esta es una opción real, pero tiene sus propios tradeoffs — accesibilidad, estrés del candidato, y el hecho de que ningún ingeniero codifica de esa manera en su trabajo real.
• Confiar en etiquetas "resistentes a la IA" de vendedores de preguntas. Algunos vendedores verifican que una pregunta puntúa por debajo de un umbral cuando se alimenta a GPT-4 hoy. El modelo de mañana volverá a probar diferente. Trata la etiqueta como un punto de partida, no como una garantía.

Empareja el diseño de preguntas con la capa de medición

Incluso una pregunta bien diseñada se beneficia de una capa de integridad que te dé un segundo eje de señal. La IA de coherencia de código de ClarityHire lee la trayectoria de un envío, no solo el código final — ¿el candidato iteró, probó y refactorizó, o la solución llegó en un único pegado coherente grande? Combinado con cronometraje de pulsación y eventos de pegado/cambio de pestaña, obtienes una puntuación de confianza que se empareja con las opciones de diseño anteriores en lugar de reemplazarlas.

El patrón más fuerte que vemos: una pregunta resistente a la IA para la etapa asíncrona, seguida por un seguimiento en vivo de 30 minutos donde el candidato tiene que explicar decisiones que tomó horas antes. La combinación es significativamente más difícil de falsificar que cualquiera de los pasos solos.

Qué hacer después

Elige las tres preguntas que asignas más a menudo y califícalas contra los principios anteriores:

1. ¿Cada pregunta oculta alguna parte de la especificación que el candidato debe obtener?
2. ¿La pregunta requiere leer código que el candidato no ha visto antes?
3. ¿Hay un giro o una llamada de criterio que un modelo disponible no pueda asumir fácilmente?

Para cada pregunta que puntúe bajo, rescríbela una vez y pilota la nueva versión en cinco candidatos reales antes de implementarla. Mide dos cosas: la calidad promedio de envío de tu cuartil superior, y la tasa de aprobación hacia la siguiente ronda. Si la calidad sube y la tasa de aprobación se mantiene estable, tienes una pregunta mejor. Si la tasa de aprobación colapsa, la nueva versión es adversarial, no selectiva — revisa e intenta de nuevo.

La IA en entrevistas técnicas no es el problema. Las preguntas moldeadas por la IA lo son. Arregla las preguntas y el resto de la pila de integridad comienza a hacer lo que siempre se suponía que debía hacer: confirmar la señal, no generarla.