Cómo entrevistar a ingenieros de aplicaciones LLM (no ingenieros de ML)

El rol que en realidad estás contratando

"Ingeniero LLM" o "ingeniero de aplicaciones de IA" es un rol que apenas existía hace tres años y ahora está en todas partes en cualquier producto. No es lo mismo que ingeniero de machine learning. Las competencias se solapan tal vez un 30%.

Un ingeniero de machine learning entrena y sirve modelos. Un ingeniero de aplicaciones LLM toma modelos preentrenados y los convierte en características de producto: diseño de prompts, marcos de evaluación, pipelines de recuperación, scaffolding de uso de herramientas, optimización de latencia y coste, fallos elegantes cuando el modelo se sale del guion. Los más senior gastan su tiempo en la mitad aburrida del trabajo —evaluaciones, observabilidad, guardias de seguridad— no en la astucia de los prompts.

Si evalúas a estos candidatos con el kit de entrevista de ingeniero de ML, contratarás investigadores que no pueden hacer ship a producción y rechazarás hacedores que nunca entrenaron un modelo. Si los evalúas con el kit de ingeniero de software genérico, pierdes toda la superficie de competencias específica de IA.

Cinco competencias que vale la pena evaluar

El trabajo se descompone en cinco áreas evaluables. La mayoría de procesos pueden cubrir cuatro de cinco en tres horas de tiempo del candidato.

1. Diseño e iteración de prompts. ¿Pueden escribir un prompt que produzca de forma fiable una salida estructurada y pueden iterar cuando no lo hace?
2. Pensamiento en evaluaciones. ¿Pueden diseñar una evaluación que detecte una regresión que una comprobación de vibes no captaría?
3. Razonamiento de modos de fallo. Cuando el modelo devuelve basura, ¿tienen un modelo de por qué y un plan para arreglarlo?
4. Integración de sistemas. ¿Pueden conectar el modelo en una superficie de producto real —recuperación, llamadas a herramientas, streaming, reintentos, cachés— sin que se rompa en producción?
5. Conocimiento de coste y latencia. ¿Saben qué cuesta cada decisión? ¿Saben qué hace una espera de 30 segundos a la confianza del usuario?

La capacidad cognitiva y la ingeniería de software general siguen importando. Trátals como requisitos previos, no como el foco de las rondas específicas de LLM.

Un proceso de cuatro fases que funciona

Este es el proceso que recomendamos para un rol de ingeniero de aplicaciones LLM de nivel medio a senior.

Fase 1: Muestra de trabajo de ingeniería de prompts asincrónica (90 minutos)

Proporciona al candidato un pequeño conjunto de datos —30 a 50 pares de entrada-salida que representen una tarea de producto realista. Ejemplos: extraer campos estructurados de correos de soporte al cliente, clasificar un ticket de soporte en una de siete categorías con una puntuación de confianza, generar un resumen de correo personalizado a partir de un registro de eventos de cliente.

Su tarea: escribir un prompt (o un pequeño pipeline de prompt y código) que produzca la salida deseada en el conjunto de datos, más una nota de un párrafo sobre dónde aún falla y por qué.

Permite cualquier herramienta de IA. Esta es una ronda de Política B —consulta nuestra guía de política de uso de IA para el framing exacto. La competencia que estás midiendo es cómo usan las herramientas para construir con las herramientas, no si pueden hacerlo sin ayuda.

Evalúa en:

• Confiabilidad de la salida en todo el conjunto de datos
• Calidad del análisis de modo de fallo (el párrafo es más revelador que el propio prompt)
• Si llegaron a las evaluaciones o simplemente miraron los resultados

Fase 2: Diseño de evaluación en vivo (45 minutos)

Muéstrales el prompt de la Fase 1 y una versión deliberadamente rota del mismo. Pídeles que diseñen una evaluación que detecte la regresión —no solo verbalmente, sino escribiendo el código de test de evaluación en un editor real.

Esta es la ronda más discriminadora en el proceso. Los candidatos fuertes:

• Distinguen entre coincidencia exacta, similitud semántica y estilos de evaluación con rúbrica, y eligen el correcto para la tarea
• Construyen casos positivos distintos, casos extremos y casos adversariales
• Hablan sobre cómo se ejecutará el conjunto de evaluación en CI, cuál debería ser el umbral de fallo y cómo lo actualizarán con el tiempo

Los candidatos débiles escribirán tres asserts que prueben el caso feliz y lo llamarán hecho.

Ejecuta esto en un editor de código colaborativo para que puedas observar el proceso de pensamiento del candidato golpe a golpe. Las pausas te dicen mucho.

Fase 3: Diseño de sistemas —construyendo con el modelo (60 minutos)

Proporciónales un resumen del producto: "Diseña el backend para una característica que permite a un representante de ventas pegar los últimos 90 días de tickets de soporte de un cliente y obtener un análisis de una oración de 'deberíamos estar preocupados por la pérdida de clientes' que puedan compartir con el gestor de cuentas."

Investiga en:

• Cómo estructurarían el prompt (sistema, usuario, llamadas a herramientas?)
• Cómo manejarían el perfil de coste y latencia (síncrono? asincrónico con un webhook? streamado?)
• Cómo lo probarían (ejemplos de oro, A/B contra una línea base, con el humano en el bucle?)
• Cómo detectarían una regresión después de la próxima actualización del modelo
• Qué harían si el modelo alucina un nombre de cuenta específico

El artefacto es la conversación, no un diagrama. Consulta nuestra rúbrica de diseño de sistemas para orientación de puntuación.

Fase 4: Recorrido más comportamental estructurado (45 minutos)

Una única ronda dividida en dos mitades. Primero, 25 minutos recorriendo la muestra de trabajo de la Fase 1 con la plantilla de preguntas de seguimiento. Luego 20 minutos de preguntas conductuales estructuradas sobre colaboración con stakeholders no técnicos —producto, diseño, soporte— ya que la mayoría de modos de fallo en características LLM son detectados por personas que no escriben código.

Patrones de preguntas que producen señal real

Tres patrones que vale la pena robar para cualquier ronda de entrevista de ingeniería de aplicaciones LLM.

"Muéstrame un prompt que escribiste que se rompió en producción. ¿Qué cambiaste?" Esta es la mejor pregunta en todo el kit. Los candidatos fuertes tienen historias específicas con arreglos específicos. Los candidatos débiles hablan sobre prompting en abstracto.

"¿Cuál es el modelo más barato que podrías usar para esta característica? ¿Por qué no lo estás usando?" Prueba la conciencia de costes y los obliga a articular el compromiso calidad-coste que eligieron implícitamente. La respuesta "Siempre voy a por el modelo más grande" es preocupante en cualquier nivel de antigüedad.

"¿Cómo sabes que tu prompt es mejor que la versión anterior?" Prueba si en realidad ejecutan evaluaciones o simplemente confían en vibes. Una fracción sorprendentemente grande de candidatos han puesto en producción características LLM sin medir nunca la calidad.

Lo que no funciona

Algunos enfoques que hemos visto que los equipos intentan y abandonan.

• Entrevistas de algoritmos al estilo LeetCode. Casi ningún trabajo de aplicaciones LLM es algorítmico. La señal que obtienes no está correlacionada con el trabajo. Consulta seleccionar desarrolladores sin LeetCode para el argumento más amplio.
• "Construye un chatbot desde cero en 90 minutos." Prueba la velocidad de escritura, no ingeniería. Las decisiones interesantes viven en el diseño de evaluación y el manejo de fallos, no en conectar una llamada a API.
• Pantallas de trivial de prompts. "¿Qué es la temperatura?" prueba vocabulario, no juicio. Prueba el juicio directamente.
• Pizarras de matemáticas sobre internals de transformers. Útil si estás contratando un investigador de modelos. Irrelevante para alguien que pasará su semana en pipelines de recuperación y suites de evaluación.

La pregunta de integridad para un rol que usa IA

Esta es la pregunta de ida y vuelta que todos los equipos encuentran: si se permite al candidato usar Claude o ChatGPT durante la muestra de trabajo, ¿qué los detiene de simplemente dejar que el modelo haga el trabajo?

Tres cosas, en combinación:

1. El recorrido de la Fase 4. Un candidato que no puede defender su propio prompt, evaluación o diseño de sistema realmente no hizo el trabajo —sea lo que sea lo que diga el artefacto.
2. El diseño de evaluación en vivo de la Fase 2. Esta ronda se ejecuta en un editor supervisado sin herramientas de chat, en 45 minutos. Es difícil falsificar.
3. Análisis de coherencia de código en el envío de la Fase 1. El código generado por IA tiene indicios estructurales incluso cuando el candidato también usó IA para disfrazarlo.

El punto no es atraparlos en flagrante delito. Es asegurar que la puntuación de cada candidato refleje lo que pueden hacer en una semana de ingeniería real, con las herramientas que en realidad usarán.

Qué hacer a continuación

Si estás configurando la contratación de LLM este trimestre, el movimiento de mayor apalancamiento es dejar de reutilizar el proceso de ingeniero senior de backend. Elige tres de las cinco competencias anteriores para tu primera versión de la rúbrica, escribe una muestra de trabajo y un ejercicio de diseño de evaluación, y ejecútalo en dos ingenieros internos para calibrar.

Luego ejecútalo en cinco candidatos externos. Para el candidato tres ya sabrás si el proceso es más agudo que el que tenías antes. Los roles cambian. La disciplina —elegir métodos que produzcan señal real, luego verificar que la señal sea la del candidato— no.