Cómo contratar ingenieros LLM en 2026: cinco competencias, cinco preguntas

«Ingeniero LLM» es el título que más rápido crece en software y el menos estandarizado. Las mismas dos palabras cubren a alguien que ha mantenido sano un pipeline de retrieval bajo tráfico real durante un año — y a alguien que montó tres demos de chatbot y una opinión firme sobre frameworks. Sus CV son idénticos. Ambos dicen Python, LangChain, RAG, «experiencia en producción con GPT y Claude». La diferencia entre los dos es la diferencia entre que tu funcionalidad de IA llegue a producción o se sume al 95% de pilotos que nunca muestra retorno.

Entrevistar para este rol con el proceso genérico de backend no funciona, porque las partes difíciles de la ingeniería LLM no salen en LeetCode ni en una pizarra de system design sobre balanceadores de carga. Salen en cinco competencias. Aquí están, cada una con la pregunta que usamos para probarla y las respuestas que separan los niveles.

El trabajo es hacer que un componente probabilístico se comporte dentro de un sistema determinista

Empieza por lo que estás contratando en realidad, porque el título lo esconde. El trabajo de un ingeniero LLM no es escribir prompts. Es responder de un componente que falla en silencio, deriva con el tiempo, factura por petición y puede ser manipulado por sus entradas — y conseguir que ese componente cumpla el listón de fiabilidad del sistema aburrido y determinista que lo rodea. Una semana normal se parece a esto: revisar resultados de evals antes de que salga un cambio de prompt, perseguir una regresión de retrieval tras una actualización del corpus, ajustar un camino de fallback que saltó demasiadas veces y explicarle a finanzas por qué ha subido la factura de tokens del mes pasado. Todo lo que merece la pena evaluar en una entrevista deriva de esa descripción del puesto: lo que significa «AI-ready» en concreto es criterio sobre este componente, no entusiasmo por él.

Una consecuencia que conviene decir sin rodeos: este es un perfil senior. Cada tarea de arriba es una decisión con consecuencias en producción, y por eso un ingeniero junior con herramientas de IA no sustituye a un ingeniero LLM — las herramientas generan código, no criterio. Presupuesta en consecuencia, y entrevista buscando cicatrices, no vocabulario.

Competencia 1: Evals — pregunta cómo saben que un cambio no rompió nada

La pregunta: «Mejoraste el prompt y la salida se ve mejor. ¿Cómo sabes que nada más empeoró?»

Un aficionado a los prompts responde con adjetivos: miró algunas salidas, las respuestas parecen mejores. Un ingeniero LLM responde con una suite de regresión — un golden dataset de casos reales, puntuado automáticamente en cada cambio de prompt o de modelo, con umbrales que bloquean el despliegue. Distinguirá entre comprobaciones exactas, puntuación con LLM como juez y niveles de revisión humana, y conocerá el modo de fallo de cada uno (los jueces LLM también derivan). Pregunta qué hay dentro de su golden dataset: los candidatos fuertes incluyen los casos feos — entradas adversarias, peticiones ambiguas, las que fallaron en producción el trimestre pasado.

Sin historia de evals, cada cambio futuro a tu funcionalidad de IA se despliega a ciegas. Es la pregunta con más señal de toda la lista.

Competencia 2: Coste — pide un número del que hayan sido responsables

La pregunta: «¿Cuánto costaba una petición en la última funcionalidad LLM que llevaste a producción, y qué hiciste al respecto?»

La inferencia es un coste por petición que crece con la adopción, y alguien del equipo tiene que tratarlo como coste de ventas. Los ingenieros que han llegado a producción citan el número — y, más revelador aún, las palancas que accionaron: caché, enrutar el tráfico fácil a un nivel más barato, acotar la longitud de salida, agrupar peticiones. Los candidatos que nunca pensaron en el coste dirán que el modelo lo eligió otro, o que los costes son una optimización para más adelante. En producción, «más adelante» llega como una factura con curva de crecimiento.

Competencia 3: Retrieval — pregunta qué midieron, separado del modelo

La pregunta: «Tu funcionalidad RAG da respuestas incorrectas. Guíame por el diagnóstico.»

Los candidatos flojos van directos al prompt o culpan al modelo. Los fuertes parten el sistema en dos: ¿el retrieval está aportando el contexto correcto, medido por su cuenta — recall contra un conjunto etiquetado, no sensaciones — o el modelo está manejando mal un contexto bueno? Tendrán opiniones ancladas en detalles: el chunking que destrozó la estructura de unas tablas, búsqueda híbrida frente a embeddings puros, el corpus que se quedó viejo sin que nadie lo notara. El patrón que quieres contratar es la descomposición — tratar el pipeline como etapas medibles y no como una caja mágica. Es la misma disciplina por la que el contexto y la memoria, no el modelo, son el cuello de botella en los sistemas de agentes.

Competencia 4: Guardrails — pregunta qué pasa cuando el modelo falla a las 3 de la madrugada

La pregunta: «El modelo devuelve salida malformada, o nada, en el 2% de las peticiones. ¿Qué ve el usuario?»

Una funcionalidad LLM sin caminos de fallo diseñados es un generador de incidentes con buenas demos. Lo que quieres escuchar es la maquinaria: validación de esquema en cada salida, reintentos con tope de presupuesto, timeouts, un fallback determinista cuando la generación falla y alertas ligadas a métricas de calidad y no solo a errores HTTP — porque los fallos de un LLM suelen ser degradación silenciosa, no excepciones. Los candidatos que han operado estos sistemas hablan de ellos como los SRE hablan de sus runbooks; ya escribimos por qué los guardrails son el 80% de la ingeniería en sistemas agénticos, y la entrevista debería darles el mismo peso.

Competencia 5: Seguridad — pregunta qué puede conseguir la entrada de un atacante

La pregunta: «Tu funcionalidad LLM puede llamar a herramientas. ¿Qué es lo peor que la entrada de un usuario podría hacerle hacer?»

La prompt injection no es una preocupación teórica; cualquier sistema que mezcla entrada no confiable con acceso a herramientas tiene una superficie de ataque nueva. Los candidatos fuertes razonan sobre la estructura: permisos mínimos por herramienta, sandboxing, tratar el contenido recuperado como no confiable, no dejar nunca que el texto de un usuario autorice por sí solo una acción con consecuencias. Los flojos dicen que el system prompt le pide al modelo que tenga cuidado. Si la funcionalidad que construyes toca dinero, datos o decisiones de contratación, esta respuesta importa tanto como cualquier pregunta de arquitectura.

Las señales de alarma que sobreviven a una buena demo

Tres patrones predicen problemas incluso cuando el portfolio impresiona:

• Todo demos, nada de operación. Cada proyecto llegó a «funciona»; ninguno llegó al mes tres. El hueco entre esos dos estados es el trabajo.
• Sin números. No pueden citar una latencia, un coste por petición, una puntuación de eval, una tasa de error de nada que hayan construido. Quien ha pasado por producción tiene números en la cabeza.
• «El modelo se encargará.» Como respuesta a modos de fallo, coste o seguridad. El modelo no se encarga de nada; se encarga la ingeniería que lo rodea — y estás contratando a la persona que la construye.
• Vocabulario de frameworks, sin vocabulario de fallos. Fluidez en nombres de librerías de orquestación, vaguedad sobre qué se rompió al usarlas. Las herramientas cambian cada trimestre en este campo; los ingenieros que vale la pena contratar describen los sistemas por cómo fallan, porque esa es la parte que sirve de un sistema al siguiente.

Lo que pondríamos en tu circuito de entrevistas

1. Sustituye una ronda de algoritmos por una ronda de evals. Dale un golden dataset pequeño y un cambio de prompt; pídele que te diga si es seguro desplegarlo.
2. Un ejercicio de estimación de coste. Esboza una funcionalidad, pide el coste por petición y las tres palancas que accionaría para reducirlo a la mitad.
3. Una sesión de diseño de caminos de fallo. La pregunta de las 3 de la madrugada, en pizarra, de punta a punta.
4. Una conversación de post-mortem real. Su peor incidente con LLM, qué se coló, qué cambió después. Que no haya historias de incidentes es en sí una señal.
5. Verifica referencias sobre operar, no sobre construir. Pregunta a la referencia quién mantuvo la funcionalidad tras el lanzamiento — y durante cuánto tiempo.

Los títulos se inflan rápido en un mercado donde los especialistas en IA facturan 200–300 $/hora y cada generalista tiene incentivos para reetiquetarse como especialista; las cinco preguntas son la manera de pagar la prima solo por las competencias que la merecen.

Esa es también, por transparencia, nuestra manera de evaluar — nuestro proceso diseñado por CTOs acepta al 3% de los candidatos, y estas cinco competencias son las que ponemos a prueba en los candidatos a ingeniero LLM, sobre sistemas reales y no ejercicios de juguete. Si prefieres empezar por un match en lugar de por un pipeline, así funciona contratar un ingeniero LLM con Conectia — match en 72 horas, evaluado antes de que lo conozcas.