Cómo entrevistar a ingenieros para la habilidad de programación asistida por IA

La habilidad que nadie está entrevistando

A mediados de 2026, la mayoría de ingenieros usa un asistente de IA para alguna parte de su trabajo diario. La pregunta que tu entrevista debe responder no es "¿puede este candidato programar sin uno?" — eso es un escenario hipotético. Es "¿puede este candidato enviar código más rápido y seguro con uno que el ingeniero sentado a su lado?"

Esa es una habilidad diferente, y requiere una entrevista diferente. Una prueba take-home con una regla oculta de no usar IA no la mide. Una pantalla de LeetCode no la mide. Incluso la mayoría de formatos open-book permiten que un candidato se deslice sin mayor esfuerzo tratando la IA como un motor de búsqueda potenciado. A continuación, una guía táctica para diseñar una ronda que mida directamente la fluidez en IA, y puntuarla sin recompensar representaciones teatrales.

Qué parece realmente la fluidez en IA

Observa a un ingeniero fuerte usar un asistente durante una hora. Verás que hace cinco cosas:

1. Enmarca el prompt alrededor de restricciones, no de soluciones. Le dice al modelo qué debe y qué no debe hacer el código, luego itera.
2. Rechaza con confianza. Cuando el modelo propone algo sutilmente incorrecto — una versión incorrecta de API, una librería alucinada, un patrón frágil — lo captan en segundos y corrigen la dirección.
3. Usa el asistente principalmente en las partes aburridas. Boilerplate, scaffolding de tests, conversiones de formato — usos de alto impacto. Escriben la lógica crítica ellos mismos o mantienen el modelo a una especificación ajustada.
4. Verifican antes de confiar. Ejecutan el código, leen el diff y comprueban los bordes. No comitean por intuición.
5. Saben cuándo dejar de usarlo. Cuando el modelo da vueltas, vuelven al pensamiento y la lectura.

Un usuario débil de IA hace lo contrario: hace preguntas amplias, acepta generaciones largas sin crítica, deja que el modelo arquitecte su solución y envía lo que funciona. El trabajo de la entrevista es distinguir estos dos perfiles.

El formato de pregunta que lo revela

La forma de la pregunta importa más que el problema específico. Elige uno con estas propiedades:

• La respuesta ingenua de la IA es incorrecta de forma sutil. No es un truco — es una restricción real que el candidato tiene que notar. Una versión común: pedirles que implementen algo contra una API reciente o inusual, donde los datos de entrenamiento del modelo están desactualizados.
• El problema es demasiado grande para que un candidato sin IA lo termine, y demasiado sutil para que un candidato que solo use IA lo resuelva de un disparo. Esto obliga a usar ambas herramientas y juicio.
• Los criterios de aceptación son claros. No "construye algo bonito" — debe-tener explícitos que el candidato pueda verificar.
• Hay una ambigüedad deliberada en la especificación. Un ingeniero razonable la resolvería pidiendo aclaraciones o estableciendo un supuesto. Un usuario débil de IA pega la especificación en el modelo y envía lo que sale.

Un ejemplo que funciona: "Construye un pequeño comando que lea un CSV de pedidos, calcule totales mensuales por cliente y devuelva JSON. Dos ambigüedades que deberías resolver: zonas horarias de pedidos y cómo manejar filas de reembolso. 60 minutos. Cualquier herramienta que quieras."

Ejecútalo en vivo, no de forma asincrónica

Una prueba take-home puramente asincrónica no puede distinguir los dos perfiles. El artefacto se ve igual de cualquier forma. Ejecútalo como una sesión de programación en vivo de 60–75 minutos con compartición de pantalla o editor colaborativo, con permiso explícito para usar IA.

Reglas base anunciadas de antemano:

• Cualquier herramienta de IA es válida. Dinos cuáles usas.
• No descontaremos por usar IA. Investigaremos cómo la usas.
• Investigaremos lo que la IA te dio. Prepárate para explicar cualquier cosa que mantengas.

Este enfoque cambia al candidato de la defensiva a la demostrativa. Los candidatos fuertes se sienten motivados. Los débiles se ponen nerviosos, porque su flujo de trabajo no resiste la inspección.

Qué observar en tiempo real

Cinco señales concretas durante la sesión:

• Calidad del prompt. ¿Explican restricciones, ejemplos y la forma de la salida deseada? ¿O pegan la especificación y esperan?
• Tasa de rechazo. ¿Con qué frecuencia descartan una generación? Los ingenieros fuertes rechazan al menos algunas — a veces en silencio, a veces en voz alta. Los ingenieros que se quedan con todo no están leyendo lo que envían.
• Dónde dejan la IA sola. ¿Escriben la lógica crítica ellos mismos? ¿O dejan que el asistente sea dueño de la parte que determina la corrección?
• Hábitos de verificación. ¿Ejecutan el código con entradas reales? ¿Leen el diff antes de aceptar? ¿Miran los bordes?
• Recuperación. Cuando el modelo da vueltas, ¿retroceden y piensan, o siguen prompteando?

Estas son observables en una ventana de 60 minutos si miras los keystrokes, no solo el artefacto. El editor colaborativo de ClarityHire registra la sesión completa con eventos de pegado etiquetados por separado de la entrada escrita — útil cuando quieres revisar una elección específica con el candidato durante el recorrido.

Una rúbrica de puntuación

Cinco dimensiones, 1–4 cada una, puntuadas antes del debriefing:

Puntúa cada uno de forma independiente. Las tarjetas de entrevista estructurada de ClarityHire structured interview bloquean estas para que los evaluadores no desvíen después de ver el artefacto.

El recorrido posterior a la sesión

Dedica los últimos 15 minutos a tres preguntas:

1. "Muéstrame una generación que rechazaste. ¿Por qué?"
2. "Recórrme la parte de esto que escribiste tú mismo, y por qué no dejaste que la IA lo hiciera."
3. "¿Cuál es la parte más frágil de lo que enviamos? ¿Qué arreglarías después?"

Los candidatos que realmente razonaron durante la sesión pueden responder estas sin vacilar. Los candidatos que aceptaron lo que el modelo produjeron no pueden — y la brecha se ve en los primeros diez segundos de cada respuesta. Esta es la misma prueba de autoría que ejecutarías en una prueba take-home, aplicada al uso de IA en vivo.

Dónde encaja esto en el ciclo

Trata esta ronda como un reemplazo de la pantalla de programación en vivo estándar, no como una adición. Tu ciclo debe incluir una ronda de diseño de sistemas y una ronda de comportamiento; la pregunta que esta ronda responde es la que manejaba anteriormente la pantalla de programación de libro cerrado, que ha perdido la mayoría de su señal en la era LLM.

Qué hacer después

Tres movimientos concretos antes de tu próxima ronda de IA permitida:

1. Elige un rol y reescribe la pregunta de programación en vivo a una que la IA no pueda resolver de un disparo pero que un candidato sin IA no pueda terminar.
2. Entrena a tus entrevistadores para puntuación del flujo de trabajo, no del artefacto. El artefacto es ahora table stakes. El flujo de trabajo es la señal.
3. Decide qué significa "verificado" antes de que el candidato llegue. Bloquear la rúbrica de antemano previene la racionalización post-hoc que arruina la calibración.

Los equipos que aciertan esto en 2026 contratarán mejor que los equipos que pretenden que el modelo no está en la sala. La habilidad es real, la brecha entre usuarios fuertes y débiles es enorme, y el formato de entrevista para medirla no es más difícil de ejecutar que el que reemplaza.