Contratación · August 2, 2026 · 13 min de lectura

Preguntas de entrevista para ingenieros de IA: cómo evaluar las respuestas

Preguntas de entrevista para ingenieros de IA dirigidas a responsables de contratación: cómo suenan las respuestas fuertes y débiles en RAG, diseño de agentes y fiabilidad, más un enfoque de puntuación.

← Parte de Los cinco pilares de la contratación: qué miden las evaluaciones

Esta guía está escrita para el responsable de contratación o líder de ingeniería que lleva el proceso para un ingeniero de IA — la persona que va a insertar en funcionalidades LLM de producción y que tiene que mantenerlas honestas, rápidas y asequibles. No está escrita para el candidato, aunque un candidato puede leerla y conocer exactamente qué busca usted. Esa admisión importa, porque nombra el problema que estas preguntas de entrevista para ingenieros de IA deben sobrevivir: en 2026, los candidatos se preparan con un asistente, y cualquier pregunta que pueda redactar de forma ordenada puede responderse de forma ordenada por alguien que nunca ha lanzado un pipeline de recuperación en su vida. Una lista de preguntas memorizable es un examen filtrado. Así que esta guía le da más que una lista. Para cada pregunta le dice qué cubre una respuesta fuerte, cómo suena una débil, dónde divergen las respuestas junior y senior, un enfoque de puntuación que mantiene honestos a sus entrevistadores y — para las habilidades que deciden la contratación — el punto en que deja de preguntar y empieza a verlos trabajar. Úsela en el proceso, después de una muestra de trabajo corta y antes de la oferta, no como un filtro por sí sola.

¿Cómo se puntúan las respuestas de la entrevista de forma consistente?

Decida cómo suena una buena respuesta antes de conocer al candidato, no mientras está hablando. Ese único hábito es la diferencia entre una entrevista estructurada y un concurso de simpatía. El resto se deriva de él: haga a cada candidato las mismas preguntas en el mismo orden y puntúe cada respuesta contra rúbricas escritas en lugar de la intuición.

Una rúbrica funcional es una escala de uno a cinco con rúbricas conductuales escritas de antemano. Para una pregunta dada, un 5 podría decir «nombra el modo de fallo sin que se lo indiquen, da un ejemplo concreto de su propio trabajo y describe cómo midió la corrección»; un 3, «da una respuesta de libro de texto correcta sin ejemplo vivido»; un 1, «recita una definición o desvía la pregunta». Escriba esas rúbricas para cada pregunta que planee hacer. Requiere una tarde y es la hora de mayor impacto en todo el proceso, porque convierte una impresión vaga en una puntuación comparable. Esta es ciencia genérica de entrevistas estructuradas, nada que nos sea propio — la guía de entrevistas estructuradas cubre la práctica. Cada entrevistador puntúa de forma independiente y solo compara notas después, para que la voz más alta en el debate no se convierta silenciosamente en la decisión.

Sistemas de recuperación aumentada

La recuperación es donde viven la mayoría de las funcionalidades de producto LLM y donde la mayoría de ellas falla silenciosamente. Estas preguntas evalúan si el candidato entiende la recuperación como un sistema de ingeniería con modos de fallo, o como una receta que memorizó. La señal es la especificidad: una respuesta fuerte nombra dónde falla la recuperación; una débil recita las etapas en orden y se detiene.

• Cuénteme qué ocurre entre la pregunta de un usuario y la respuesta del modelo en una funcionalidad de recuperación aumentada — las respuestas fuertes describen la fragmentación, la indexación, la clasificación y el ensamblaje del prompt como decisiones con trade-offs; señal de alerta: recitar las etapas como un pipeline fijo sin decisiones dentro.
• Su funcionalidad de recuperación devuelve respuestas seguras, fluidas e incorrectas. ¿Cómo lo diagnostica? — las respuestas fuertes separan un fallo de recuperación de un fallo de generación antes de tocar el prompt; señal de alerta: saltar directamente a ajustar el prompt sin comprobar qué se recuperó.
• ¿Cómo decide el tamaño del fragmento y la superposición para un corpus? — las respuestas fuertes lo vinculan a la forma de los documentos y las consultas y admiten que lo medirían; señal de alerta: citar un único número como universalmente correcto.
• ¿Qué hace cuando la recuperación no devuelve nada útil para una consulta? — las respuestas fuertes tienen un fallback diseñado y nunca dejan que el modelo invente el contexto; señal de alerta: asumir que la recuperación siempre devuelve algo relevante.
• ¿Cómo evalúa si su recuperación es realmente buena, independientemente de la respuesta del modelo? — las respuestas fuertes nombran métricas específicas de recuperación y un conjunto etiquetado; señal de alerta: juzgar la recuperación solo por si la respuesta final parecía correcta.
• ¿Cuándo no usaría la recuperación en absoluto y pondría el contexto directamente en el prompt? — las respuestas fuertes razonan sobre el tamaño del corpus, la actualidad y el coste; señal de alerta: tratar la recuperación como obligatoria para cada funcionalidad LLM.

La pregunta sobre el fallo de recuperación es su pregunta principal aquí, así que dedíquele tiempo real. Una respuesta junior trata toda la funcionalidad como una caja negra: la respuesta fue incorrecta, así que reescribe el prompt, añade una línea diciéndole al modelo que no invente cosas y espera. Una respuesta senior se niega a tocar el prompt hasta saber qué mitad falló. Extraen los fragmentos recuperados para la consulta fallida y los leen. Si el documento correcto nunca se recuperó, el prompt nunca fue el problema — el error está más arriba, y ninguna cantidad de reproches al prompt arreglará un documento que nunca llegó a la ventana de contexto. Si el documento correcto se recuperó y el modelo aun así respondió incorrectamente, ahora es un problema de generación. El candidato que recita las etapas de recuperación a la perfección pero no puede decir por qué su sistema devolvió el documento incorrecto ha memorizado el mapa y nunca ha pisado el terreno.

Diseño de agentes y herramientas

Los agentes son el patrón al que más se recurre en el campo ahora mismo, lo que convierte la contención en la señal. Los ingenieros de IA más fuertes le disuaden de usar agentes con tanta frecuencia como le animan a usarlos. Estas preguntas tratan menos de si el candidato puede conectar una llamada de herramienta y más de si sabe cuándo toda la arquitectura es un error. Si su equipo está construyendo productos genuinamente agénticos, combínelas con cómo contratar a un ingeniero de agentes de IA.

• ¿Cuándo no usaría un agente y optaría por un flujo de trabajo fijo en su lugar? — las respuestas fuertes usan por defecto lo más simple que funciona y reservan los agentes para tareas genuinamente abiertas; señal de alerta: tratar los agentes como la opción moderna obvia para todo.
• Una herramienta que llama su agente devuelve basura, pero el modelo lo cree y continúa. ¿Cómo diseña para eso? — las respuestas fuertes validan la salida de la herramienta y nunca asumen que una herramienta tuvo éxito; señal de alerta: confiar en las respuestas de la herramienta porque el modelo parecía seguro.
• ¿Cómo evita que un agente entre en bucle con una llamada de herramienta malformada a las 2 de la madrugada? — las respuestas fuertes describen límites de bucle, tiempos de espera y observabilidad; señal de alerta: sin contención de fallos y sin forma de ver qué hizo el agente.
• ¿Cómo decide qué acciones puede realizar un agente de forma autónoma frente a las que necesitan un humano en el proceso? — las respuestas fuertes razonan sobre el radio de impacto y la reversibilidad; señal de alerta: autonomía total sin pensar en el coste de un error irreversible.
• ¿Cómo prueba un agente cuando su ruta a través de las herramientas cambia en cada ejecución? — las respuestas fuertes evalúan el comportamiento y los resultados, no una única transcripción fija; señal de alerta: asumir que una demo de la ruta feliz significa que funciona.
• Describa un diseño de agente que descartó o simplificó. ¿Qué le hizo dar marcha atrás? — las respuestas fuertes muestran escepticismo ganado con experiencia real; señal de alerta: nunca haber cuestionado un enfoque agéntico.

«¿Cuándo no usaría un agente?» es la pregunta principal de este grupo, y es una trampa para el candidato a la moda. Una respuesta junior, especialmente la de alguien que ha leído la oleada actual de tutoriales de agentes, recurre a un agente por defecto y describe una orquestación elaborada de varios pasos para una tarea que son realmente tres llamadas API secuenciales. Confunden la sofisticación con el juicio. Una respuesta senior comienza desde el otro extremo. Se preguntan qué necesita realmente la tarea, señalan que los agentes añaden latencia, coste, no-determinismo y toda una categoría de modos de fallo, y los reservan para problemas donde el camino genuinamente no puede conocerse de antemano. Con gusto le dirán que lo último que lanzaron podría haber sido un agente pero era mejor como un flujo de trabajo simple. El ingeniero que le disuade de usar un agente generalmente ha limpiado después de uno.

Evaluación y fiabilidad

Esta es la competencia definitoria del puesto, así que pésela en consecuencia. El valor total de un ingeniero de IA es saber si una funcionalidad funciona — y poder demostrarlo — antes de que llegue a un usuario. Lo más útil que puede preguntar es cómo supieron que una funcionalidad pasada funcionaba; la respuesta separa a los genuinos de los rebautizados más rápido que cualquier otra cosa en el proceso.

• ¿Cómo supo que su última funcionalidad LLM realmente funcionaba antes de lanzarla? — las respuestas fuertes describen un conjunto de evaluación, comprobaciones offline y online y una métrica en la que confiaban; señal de alerta: «parecía correcta cuando la probé unas cuantas veces».
• ¿Cuál es la diferencia entre la evaluación offline y la online, y cuándo necesita ambas? — las respuestas fuertes usan cada una para lo que es buena; señal de alerta: confundir una demo con una evaluación.
• ¿Cómo construye un conjunto de evaluación para una funcionalidad que nunca ha tenido uno? — las respuestas fuertes comienzan con ejemplos fallidos reales y lo hacen crecer deliberadamente; señal de alerta: sin método más allá de inspeccionar visualmente las salidas.
• El modelo subyacente es actualizado silenciosamente por el proveedor y su funcionalidad se degrada silenciosamente. ¿Cómo lo detectaría? — las respuestas fuertes tienen una suite de regresión que se ejecuta de forma continua; señal de alerta: asumir que una funcionalidad que funcionó la semana pasada sigue funcionando hoy.
• ¿Cómo se protege contra la inyección de prompts en una funcionalidad que acepta input no confiable del usuario? — las respuestas fuertes tratan el input del modelo como hostil y diseñan límites; señal de alerta: no tener conciencia de que el texto del usuario puede secuestrar el modelo.
• ¿Cómo mide la alucinación de una forma en que pueda actuar sobre ella? — las respuestas fuertes anclan la afirmación en fuentes recuperables y la cuentan; señal de alerta: tratar la alucinación como inconmensurable y por tanto ignorada.

«¿Cómo supo que funcionaba?» merece su propio sondeo porque es el detector de impostores más rápido en el proceso. Pregúntelo y luego quédese en silencio y deje que lo llenen. El candidato rebautizado — el cuya ingeniería de IA es en realidad una tarde siguiendo un tutorial de API — habla del prompt del que estaba orgulloso y de la demo que impresionó a un stakeholder. Un ingeniero de IA genuino habla del conjunto de evaluación: cómo lo ensambló con casos fallidos reales, qué regresiones detectó, el número incómodo que le dijo que la funcionalidad era peor de lo que todos asumían. La versión junior sabe que la evaluación importa pero solo la ha ejecutado offline, una vez, antes del lanzamiento. La versión senior tiene una evaluación que nunca deja de ejecutarse, porque ha sido quemado por un proveedor que actualiza un modelo debajo de una funcionalidad que funcionaba el día anterior. La misma pregunta, tres respuestas diferentes, y puede escuchar la seniority en cuál dan.

Juicio de producción: coste, latencia y fallback

El último grupo separa a las personas que han lanzado funcionalidades LLM a usuarios reales de las que han construido prototipos impresionantes. El juicio de producción se muestra en tokens, milisegundos y el plan para el día en que algo se rompe. Estas son preguntas poco glamurosas, y eso es exactamente por qué discriminan — nadie las ensaya, así que las respuestas suelen ser honestas.

• ¿Cuánto le cuesta su funcionalidad por cada mil llamadas y cómo lo averiguaría? — las respuestas fuertes razonan en tokens y saben dónde se esconde el coste; señal de alerta: nunca haber mirado el coste de una funcionalidad que construyeron.
• ¿Cómo decide cuándo un modelo más barato y pequeño es suficientemente bueno para parte de una funcionalidad? — las respuestas fuertes enrutan por dificultad de la tarea y miden el trade-off de calidad; señal de alerta: usar por defecto el modelo más grande en todas partes.
• El proveedor del modelo tiene una interrupción en medio de su pico. ¿Qué le pasa a su funcionalidad? — las respuestas fuertes tienen un fallback y se degradan con elegancia; señal de alerta: una dependencia única sin plan B.
• ¿Cómo pone bajo control la latencia de una cadena de prompts lenta? — las respuestas fuertes nombran el caché, el paralelismo y reducir la cadena; señal de alerta: aceptar la lentitud como inherente a los LLMs.
• ¿Cómo versiona y hace rollback de un prompt de la misma forma que haría con código? — las respuestas fuertes tratan los prompts como artefactos versionados con un camino de rollback; señal de alerta: prompts editados en vivo en producción sin historial.
• ¿Qué registra para poder depurar una funcionalidad LLM después de que se haya comportado mal con un usuario real? — las respuestas fuertes capturan inputs, contexto recuperado y salida del modelo; señal de alerta: sin registro más allá de un indicador de éxito o fallo.

La pregunta sobre el coste es silenciosamente una de las más reveladoras en el proceso, porque tan pocos candidatos han tenido que gestionar un presupuesto. Pregunte cuánto cuesta una funcionalidad por cada mil llamadas y un candidato junior suele parpadear — construyeron la cosa, la lanzaron y nunca miraron la factura, porque alguien más era dueño de esa línea. No descalificador en un junior, pero le dice dónde están. Un candidato senior responde en la moneda del trabajo: esta funcionalidad es cara porque mete todo el documento en cada prompt, así que cachearía la recuperación, enrutaría las consultas fáciles a un modelo más barato y recortaría la cadena primero. Han sentido doler la línea de costes y cambió cómo construyen. No está poniendo a prueba la aritmética. Está poniendo a prueba si el número es real para ellos.

¿Cuándo debe dejar de preguntar y empezar a evaluar?

El momento en que un candidato puede responder todas las preguntas anteriores sin dudar es el momento en que debe confiar menos en las preguntas. Las entrevistas muestrean afirmaciones; las muestras de trabajo muestrean el trabajo. Una descripción segura de cómo diagnosticaría una funcionalidad de recuperación rota es una afirmación. Ver a alguien extraer los fragmentos recuperados, leerlos y solo entonces decidir si tocar el prompt es evidencia — y en 2026, con asistentes capaces de producir la descripción segura a demanda, la brecha nunca ha importado más.

Así que ejecute la muestra de trabajo antes de la entrevista, no después. Entréguele al candidato una tarea con forma de trabajo real — una funcionalidad de recuperación que devuelve respuestas fluidas e incorrectas, un agente que entra en bucle con una llamada de herramienta errónea, una cadena de prompts que silenciosamente está desbordando el presupuesto de latencia — dentro de un entorno donde un modelo esté genuinamente disponible en lugar de prohibido, porque prohibir la IA en la evaluación de un ingeniero de IA pone a prueba un trabajo que nadie hace. Una prueba de muestra de trabajo como esta predice el comportamiento en el trabajo mucho mejor que cualquier pregunta, y le dice qué sondeos valen su escaso tiempo de entrevista. Si la muestra ya muestra una sólida disciplina de evaluación, profundice en cambio en el juicio de producción o la contención de agentes que dejó ambiguos. Deje que el informe elija sus preguntas.

Este es el punto donde una plataforma de evaluación se gana su lugar en el proceso, incluida la nuestra. Nuestro AI Sandbox ejecuta exactamente este tipo de sesión con forma de trabajo real para puestos de ingeniería de IA, y el informe le dice dónde apuntar la entrevista después — a nivel de capacidad, sin dictar su decisión. El caso de contratación más amplio para el puesto está en cómo contratar a un ingeniero de IA; la disciplina de leer cómo alguien trabaja con un modelo, en lugar de si puede hacerlo, está en cómo evaluar la fluidez en IA, puntuada contra el Marco 4D de Delegation, Description, Discernment y Diligence — las dos últimas tienen más peso para un ingeniero de IA, porque detectar cuando el modelo se equivoca es el trabajo completo. Puede construir una versión casera con un repositorio roto y un cronómetro; si prefiere ver la nuestra, reserve una demo. De cualquier manera el principio se sostiene: haga las preguntas para abrir la conversación, luego deje de preguntar y empiece a observar.

Los mejores ingenieros de IA no son los que tienen las respuestas más fluidas. Son los que, al entregarles una funcionalidad que parece bien, se niegan a confiar en ella hasta haberla medido — y que le dirán el número incómodo que ocultó la demo. Entreviste buscando ese instinto, luego verifíquelo en una muestra de trabajo, o seguirá confundiendo una respuesta bien preparada con lo que se lanza.