Cómo entrevistar ingenieros de IA (Roles de LLM, RAG e Ingeniería Prompt)

"Ingeniero de IA" son tres roles diferentes disfrazados

Antes de diseñar el loop, decide cuál de los siguientes roles estás realmente contratando:

1. Ingeniero de IA aplicada — construye características de producto sobre modelos de fundación. Propietario de prompts, evals, retrieval, latencia, coste. Vive en tu codebase de aplicación.
2. Ingeniero ML (lado del modelo) — entrena, fine-tunea o destila modelos. Propietario de datasets, infraestructura de entrenamiento, suites de evaluación. Vive en tu stack de entrenamiento.
3. Ingeniero de infraestructura de IA — gestiona la inferencia, vector DB y la capa de observabilidad. Propietario de presupuestos de latencia, utilización de GPU, pipelines de despliegue. Vive en tu plataforma.

Estos tres roles no comparten nada de su trabajo diario. Un loop diseñado para uno evaluará mal los otros dos. El resto de esta guía se enfoca en el ingeniero de IA aplicada, porque es lo que el 80% de los equipos que contratan "ingenieros de IA" en 2026 realmente necesitan.

Los cuatro signals que predicen realmente el desempeño en el trabajo

Después de auditar docenas de loops de contratación de IA aplicada, cuatro signals separan consistentemente ingenieros que lanzan características LLM funcionales de ingenieros que lanzan demos que se ven plausibles:

1. Disciplina en iteración de prompts. ¿Pueden convertir un requisito de producto vago en un prompt, un eval y un loop de mejora medible?
2. Razonamiento de modos de fallo. ¿Asumen por defecto que el modelo alucinará, filtrará tokens o elegirá la herramienta equivocada — y diseñan en consecuencia?
3. Diseño de evals. ¿Pueden diseñar una evaluación que detecte la regresión que realmente les importa, no solo la puntuación BLEU?
4. Conciencia de coste y latencia. ¿Razonan sobre tokens, caching, selección de modelo y batch shape — o alcanzan GPT-5 para cada llamada?

Ninguno de estos es testeable con una pregunta de LeetCode. Los cuatro requieren un formato de entrevista diferente.

El loop de cuatro rondas que funciona

Ronda 1: Take-home asincrónico (90 minutos, pagado si tu cultura lo permite)

Proporciona al candidato un pequeño sistema RAG roto y una queja real de usuario. Ejemplo:

Nuestro bot de soporte al cliente sigue citando confiadamente una característica de producto que no existe. Aquí está el repo, el prompt, el pipeline de retrieval y tres ejemplos de fallos. Encuentra la causa raíz y propone un arreglo que puedas defender.

Qué buscar:

• ¿Leen los resultados del retrieval antes de culpar al prompt?
• ¿Identifican que el modelo de embeddings probablemente es incorrecto para este dominio?
• ¿Proponen un eval para detectar la regresión la próxima vez?
• ¿Distinguen "arreglar el síntoma" de "arreglar el sistema"?

Un take-home es el único formato que te da una lectura limpia sobre disciplina de debugging. Las rondas de live coding son demasiado cortas y tienen demasiada presión para ver si alguien realmente lee los datos. Emparéjalo con un seguimiento en vivo para que no escapen los envíos generados por IA.

Ronda 2: Sesión en vivo de ingeniería de prompts (60 minutos)

Empareja al candidato con un entrevistador y una tarea real: tomar un brief de producto vago y convertirlo en un prompt funcional con evals medibles, en tiempo real, en tus herramientas actuales.

Subtareas útiles:

• Escribe el prompt de primer borrador.
• Escribe tres casos de eval — incluyendo uno que debería fallar.
• Itera el prompt hasta que los evals pasen.
• Discute qué medirían en producción más allá del conjunto de eval.

Signal que buscas: ¿piensan en evals primero, prompts segundo? Los ingenieros que han lanzado características LLM saben que el prompt es derivado del eval. Los ingenieros que solo han prototipado hacen lo opuesto.

Una sala de codificación colaborativa con Monaco + Yjs funciona para esto — el candidato escribe prompts y scaffolding de eval en tiempo real, y el entrevistador puede intervenir exactamente cuando importa.

Ronda 3: Diseño de sistema — pero hecha a medida de IA (60 minutos)

Coloca al candidato en un prompt realista de diseño de IA aplicada:

Diseña un resumidor de reuniones orientado al cliente que ingiera una transcripción de 60 minutos y produzca una lista de elementos de acción. Debe ejecutarse en menos de 30 segundos, costar menos de $0.05 por llamada y rechazar resumir contenido fuera del dominio de nuestro producto.

Esta es una entrevista de diseño de sistema con restricciones específicas de IA. Puntuarla con las mismas dimensiones — aclaración, trade-offs, modos de fallo, coste — pero observa los movimientos específicos de IA:

• ¿Consideran chunking y map-reduce versus single-shot?
• ¿Razonan sobre selección de modelo (modelo más pequeño + mejor prompt versus modelo más grande)?
• ¿Proponen un guardrail para contenido fuera de dominio (clasificador? prompt? eval de rechazo)?
• ¿Diseñan observabilidad para tasa de alucinación, no solo latencia?

Los malos candidatos por defecto "usa GPT-5, hazle un prompt, devuelve la respuesta." Los buenos candidatos gastan 10 minutos en el presupuesto de coste/latencia antes de dibujar un solo box.

Ronda 4: Conductal sobre una característica de IA lanzada (45 minutos)

Una ronda conductal estructurada anclada en una característica específica que lanzaron. Las preguntas que funcionan:

• "Camina por la suite de evals que construiste. ¿Cómo cambió con el tiempo?"
• "Cuéntame sobre una regresión que se envió a producción. ¿Cómo la encontraste?"
• "Describe un tiempo que usaste un modelo más pequeño donde uno más grande hubiera sido más fácil. ¿Por qué?"
• "Cuéntame sobre una característica donde el LLM era la herramienta equivocada. ¿Qué lanzaste en su lugar?"

Esa última pregunta es la de mayor signal en el loop. Los ingenieros que solo han usado LLMs como un martillo no pueden responderla. Los ingenieros que han lanzado producto real generalmente pueden contarte sobre tres.

Preguntas que parecen inteligentes pero no lo son

Estas surgen constantemente en guías de entrevistas de ingenieros de IA y en su mayoría son ruido:

• "Explica cómo funcionan los transformers." Trivia. Cada candidato ha leído el mismo blog post. No te dice nada sobre si pueden lanzar.
• "¿Cuál es la diferencia entre RAG y fine-tuning?" Ya está en cada conjunto de entrenamiento. Usa un patrón de seguimiento en su lugar: "cuéntame sobre un tiempo en que elegiste uno sobre el otro y por qué."
• "Escribe un transformer desde cero." Solo relevante para el rol de modelo-lado ingeniero ML. Para IA aplicada, esto es signal de trasfondo académico, no habilidad de lanzamiento.
• Ingeniería de prompts en pizarra ("escribe un prompt que haga X" sin eval y sin iteración). Desvinculado de cómo realmente funciona el trabajo. Un prompt en aislamiento, sin un eval, es teatro.

Calibración por antigüedad

El mismo loop funciona en todos los niveles — lo que cambia es qué pondera.

Un ingeniero de IA aplicada staff debe evaluarse principalmente en diseño de sistema y conductal — en ese nivel, estás comprando juicio, no velocidad de implementación. Un ingeniero de nivel mid debe evaluarse principalmente en take-home y sesión de prompt — ahí es donde su valor reside. Ver el loop de entrevista de ingeniero senior para el desglose equivalente en roles de ingeniería general.

Integridad, pero más inteligente

Para roles de IA aplicada específicamente, prohibir asistencia de IA durante la entrevista es incoherente. El trabajo es usar IA bien. La entrevista debe reflejar eso.

Lo que recomendamos en su lugar:

• Permite asistencia de IA abiertamente en el take-home. Puntuala el uso de IA, no su presencia. El candidato que usa Claude para explorar el codebase y luego escribe un análisis de causa raíz reflexivo es exactamente el candidato que quieres.
• Prohíbe IA en la sesión de prompt en vivo. El punto es verlos iterar. Usa signals de keystroke y pantalla para detectar uso silencioso de IA.
• Requiere un seguimiento en vivo en cada take-home. Esta es la entrevista de mayor signal que la mayoría de equipos omiten. Empareja un pase de coherencia LLM con un walkthrough en vivo de 30 minutos.

El candidato que puede defender su take-home durante 30 minutos lo escribió. El que no puede, no lo hizo — sin importar qué digan los signals de keystroke.

Qué hacer a continuación

Si estás configurando un loop de ingeniería de IA aplicada desde cero:

1. Elige una de las tres definiciones de rol y escribe una descripción de trabajo que coincida.
2. Construye (o reutiliza) un take-home de RAG roto. Iteralo en ingenieros internos primero.
3. Configura la sesión de prompt en vivo en un editor colaborativo con scaffolding de eval compartido.
4. Entrena entrevistadores en los cuatro signals anteriores antes de ejecutar una sola ronda.

Los equipos que contratan bien ingenieros de IA en 2026 no son los equipos con las preguntas más inteligentes. Son los equipos cuyos loops reflejan el trabajo real — iterar, evaluar, debugar, lanzar — y que puntúan por el juicio que toma años construir.