Cómo diseñar preguntas de entrevista de codificación resistentes a la IA

No puedes prohibir la IA. Puedes diseñar alrededor de ella.

En 2026, pedir a los candidatos que renuncien a los asistentes de IA para una entrevista es teatro. El nivel que los candidatos alcanzan con ChatGPT en otra pestaña es el nivel contra el que contratan tus competidores. La pregunta no es cómo detectar el uso de IA — esa es la mitad del trabajo, y la cubrimos en cómo detectar ChatGPT en entrevistas de codificación. La otra mitad es diseñar problemas que no colapsen cuando el candidato tiene un LLM disponible.

Esta es una guía para la segunda mitad: cómo escribir problemas de entrevista de codificación que produzcan información real incluso cuando la IA está activada, y dónde la ayuda de la IA se mapea limpiamente con las habilidades que realmente quieres contratar.

Por qué los problemas estándar ya no funcionan

Un problema típico de LeetCode tiene tres propiedades que lo hacen trivial para un LLM:

1. Está en el conjunto de entrenamiento. Cada problema clásico de dos punteros, ventana deslizante y programación dinámica ha sido resuelto, explicado y re-explicado en todo internet.
2. La entrada está bien especificada. Dos matrices de enteros, un objetivo, devuelve los índices. El modelo sabe exactamente qué producir.
3. La salida es binaria. Las pruebas se pasan o fallan. No hay juicio en la respuesta que el candidato tenga que defender.

Un problema con las tres propiedades es, en 2026, una prueba de habilidad de ChatGPT, no una prueba de habilidad de programación. Cada propiedad que elimines hace el problema más difícil de tercerizar.

Principio 1: ancla el problema en código que el LLM nunca ha visto

La forma más limpia de eliminar la ventaja del conjunto de entrenamiento es hacer que el candidato trabaje dentro de una base de código específica. Un LLM puede escribir un recorrido de grafos en frío. No puede extender de manera confiable un repositorio de 400 líneas donde dos de los módulos usan una convención interna que nunca ha encontrado.

Así se ve en la práctica:

• Corregir el bug. Un repositorio de 200–400 líneas con un bug no obvio. El síntoma se proporciona, la causa no. El candidato tiene que leer, hacer una hipótesis, probar y parchar. Describimos el formato en nuestra guía de entrevistas sin Leetcode.
• Extender la característica. Una aplicación que funciona con una solicitud de característica pequeña y bien definida. La calidad del diff es la evaluación. Un LLM puede generar un diff plausible; no puede garantizar que el diff se ajuste a las convenciones existentes y pase las pruebas existentes en el primer intento.
• Refactorizar bajo una restricción. "Este archivo tiene 600 líneas y es difícil de leer. Divídelo en tres archivos sin cambiar el comportamiento. Las pruebas aún deben pasar." La respuesta correcta es un juicio. No hay una solución canónica para memorizar.

Estos formatos neutralizan la ventaja del conjunto de entrenamiento porque el LLM no podría haber visto el repositorio. La capacidad del candidato para navegar el código desconocido se convierte en la información útil.

Principio 2: haz la entrada ambigua a propósito

Los LLM son más fuertes cuando la especificación es precisa. Son más débiles cuando la especificación carece de información que un humano notaría y preguntaría.

Un problema estándar: "Dado un CSV de órdenes, calcula el ingresos mensuales."

Una versión más difícil de tercerizar: "Aquí hay un CSV de órdenes. Calcula los ingresos mensuales. Algunas filas son reembolsos y se representan como cantidades negativas. Algunas filas son reembolsos parciales y usan un valor status diferente. Algunas filas son de una línea de productos descontinuada que en realidad nunca fue enviada. Decide cuáles de estas incluir y explica tu razonamiento antes de escribir ningún código."

El paso de razonamiento es la evaluación. Un LLM producirá felizmente código que maneja el caso canónico y silenciosamente deja el resto. Un ingeniero real hará una pausa, enumerará las ambigüedades y hará una pregunta aclaratoria — o documentará las suposiciones que hizo.

Califica los aclaraciones y supuestos del candidato por separado del código que sigue. La lista de aclaraciones es más difícil de falsificar que la implementación.

Principio 3: traslada el peso hacia la conversación alrededor del código

Un envío es una muestra, no una respuesta. Un LLM puede producir un envío. Solo el candidato puede defenderlo bajo cuestionamiento en vivo.

Dos formas de aprovechar esto:

• Asincrónico y luego sincrónico. Ejecuta la tarea para hacer en casa o la ronda de codificación asincrónica primero, luego programa una ronda en vivo de 30 minutos donde el candidato te camina a través de su envío. Pídeles que lo extiendan, cambien una restricción o argumenten por qué eligieron una estructura de datos sobre otra. Desempacamos este formato en preguntas de seguimiento para envíos de tareas para hacer en casa.
• Pairing en vivo sobre el código propio del candidato. A mitad de la entrevista, cambia un requisito y pídeles que refactoricen frente a ti. El candidato que pegó la solución original de un LLM tendrá dificultades para evolucionarla sin re-preguntar.

En ClarityHire instrumentamos la ronda en vivo con comprobaciones de coherencia de código en el envío original, por lo que el entrevistador entra sabiendo qué secciones del código del candidato parecen generadas por LLM y cuáles parecen escritas a mano. La conversación puede entonces dirigirse específicamente a las secciones sospechosas.

Principio 4: elige problemas donde la ayuda de la IA es una característica, no un problema

Si tu publicación de trabajo dice "usarás herramientas de IA todos los días en este rol," entonces diseña problemas que te permitan observar cómo realmente los candidatos las usan. Esto no es lo mismo que permitirles pegar la respuesta.

• Libro abierto con atribución. Establece explícitamente: "Puedes usar ChatGPT o cualquier documentación. Documenta cada prompt que usaste y la parte de la solución que produjo." Un candidato fuerte usa el modelo de manera quirúrgica; uno débil pregunta cinco veces para la misma función rota. El rastro es la información útil.
• IA como oponente. Dale al candidato una función generada por IA defectuosa como punto de partida. Su trabajo es identificar qué es lo incorrecto, por qué, y arreglarlo. Esto prueba la habilidad que el rol realmente requiere: revisar críticamente la salida de IA antes de enviarla.
• Depuración asistida por IA. Entrégales un repositorio desconocido con un bug real, permite el uso de herramientas, y observa cómo identifican la causa. Los ingenieros que se basan en el modelo para preguntas estrechas ("¿qué significa este seguimiento de pila?") se ven muy diferentes de los que pegan todo el archivo y oran.

Exploramos la imagen más grande de este formato en evaluaciones de codificación de libro abierto.

Principio 5: combina prevención con detección — nunca dependa de solo una

Incluso el problema mejor diseñado filtra información en solo una dirección. Empareja las opciones de diseño anteriores con señales de integridad pasivas:

• Biometría de pulsaciones marca eventos de pegado en ráfaga que no coinciden con la autoría humana.
• Análisis de coherencia de código atrapa cambios de estilo a mitad del envío.
• Un seguimiento en vivo atrapa a los autores que no pueden defender su propio código.

Cada uno es débil solo. Juntos hacen el costo del engaño más alto que el costo de hacer el trabajo.

Una lista de verificación corta antes de que envíes la pregunta

Antes de poner un problema de codificación frente a un candidato en 2026, pregúntate:

1. ¿Podría ChatGPT resolver esto solo a partir de la declaración del problema? Si es que sí, rediseña o reduce su peso en el bucle.
2. ¿Es la especificación ambigua de una manera que recompensa las preguntas aclaratorias? Si no, agrega ambigüedad.
3. ¿Tiene el candidato que defender o evolucionar su solución en vivo? Si no, programa un seguimiento.
4. ¿Estás midiendo cómo usan la IA, o pretendiendo que no lo harán? Sé honesto con el candidato de cualquier forma.
5. ¿Tienes una señal de integridad que confirme que la misma persona escribió el envío y ejecutó el seguimiento? Si no, agrega una.

Qué hacer a continuación

Si tu ronda de codificación actual es un único problema de estilo LeetCode con un dropbox para hacer en casa, estás probando ingeniería de prompts en este punto, no ingeniería. Elige uno de los formatos anteriores, escribe un problema en él, y ejecútalo en tres ingenieros internos antes de ponerlo frente a un candidato. La primera versión será demasiado fácil o demasiado poco clara; la tercera será la que produzca información real.

Para un contexto más amplio sobre dónde encaja lo asincrónico en el bucle, consulta entrevistas técnicas asincrónicas vs en vivo. Para la mitad de detección de este mismo problema, comienza con cómo detectar ChatGPT en entrevistas de codificación.