Preparar una entrevista de AI Engineer: los tres ejes que se evalúan de verdad

Qué evalúa realmente un proceso de AI Engineer

Los títulos cambian de una empresa a otra, pero la entrevista casi siempre busca responder a tres preguntas: sabes diseñar un sistema alrededor de un modelo, sabes medir si funciona y sabes mantenerlo cuando hay usuarios reales dependiendo de él.

Eso explica una frustración habitual: perfiles técnicamente sólidos quedan fuera porque tratan la entrevista como un examen de conocimientos. Conocer familias de modelos, bases vectoriales o marcos de orquestación se da por supuesto. Lo que se evalúa es cómo decides bajo restricción.

• Diseño: convertir una necesidad difusa en un sistema cuyos componentes tienen una razón de ser.
• Evaluación: definir qué significa «funciona» y luego medirlo.
• Explotación: sostener el sistema en el tiempo, con un coste, una latencia y regresiones.

Casi siempre hay además una conversación de producto o de negocio. No es un trámite: ahí se juzga si sabes discutir un caso de uso sin reducirlo a una implementación.

La primera llamada: sitúa tu ámbito en una frase

La primera conversación sirve para saber dónde encajas. Recorrer el CV en orden cronológico la desaprovecha. Sitúa primero tu ámbito actual —qué tipo de sistemas construyes, para qué uso, con qué nivel de responsabilidad— y conéctalo con la necesidad descrita en la oferta.

Diseñar un sistema basado en un LLM

El ejercicio más frecuente es abierto a propósito: «¿cómo construirías un asistente que responda a las preguntas de nuestros clientes a partir de nuestra documentación?». Lo que se observa es el orden en que trabajas. Empezar nombrando una arquitectura antes de encuadrar el problema suele penalizar.

1. 1

   Encuadrar el uso

   5 min

   Quién pregunta, con qué frecuencia y qué pasa si la respuesta es incorrecta. El coste del error determina lo demás: salvaguardas, presencia humana y exigencia de trazabilidad.

2. 2

   Encuadrar el dato

   5 min

   Quién posee los documentos, cómo cambian, si están limpios, versionados o sujetos a permisos distintos. Muchos sistemas fallan aquí, no en el modelo. El caso más delicado: que el sistema devuelva a un usuario un documento al que no tiene acceso. Explica cómo los permisos acompañan al dato hasta la respuesta: filtrado en la recuperación, índices separados y trazabilidad de las fuentes citadas.

3. 3

   Proponer una primera versión sencilla

   10 min

   Una arquitectura mínima que resuelva la necesidad, con cada componente justificado. Di explícitamente qué dejas fuera de la versión 1 y por qué.

4. 4

   Nombrar los puntos de ruptura

   5 min

   Volumen, frescura, preguntas ambiguas, documentos contradictorios. Describe qué se rompería primero y cómo lo detectarías.

Un buen candidato también dice qué descarta: nada de agentes con varias herramientas mientras una recuperación simple no sea fiable; nada de fine-tuning si el problema es de contexto y no de comportamiento del modelo. Un arbitraje explícito llega más lejos que una respuesta exhaustiva. Si el ejercicio se convierte en un system design completo, nuestra guía dedicada al system design en entrevistas de IA desarrolla ese formato; aquí no lo repetimos.

La evaluación: lo que más rápido diferencia

«¿Cómo sabías que estaba bien?» Esa pregunta parte la entrevista en dos minutos. Una respuesta vaga —«lo probamos y el feedback fue bueno»— señala un prototipo. Una respuesta precisa señala un sistema.

• Un conjunto de ejemplos representativos, construido con quien conoce el negocio, no muestreado al azar.
• Criterios explícitos: respuesta correcta, fundamentada en las fuentes, sin invención y en un formato utilizable.
• Una mezcla asumida de medición automática y revisión humana, indicando el peso de cada una.
• Comparación entre versiones: qué cambia realmente al tocar el prompt, el modelo o la recuperación.
• Casos difíciles a propósito: preguntas fuera de alcance, documentos contradictorios, formulaciones ambiguas.

Si nunca has montado una evaluación formal, dilo y describe cómo la montarías para el caso que se está discutiendo. Un razonamiento estructurado sobre una carencia asumida convence más que una respuesta genérica.

Explotación: coste, latencia y regresiones

Muchas organizaciones ya han superado la fase exploratoria. Buscan a alguien capaz de sostener un sistema existente, no solo de arrancarlo. Prepara un incidente real: qué pasó, cómo lo viste y qué cambiaste.

• Qué impulsaba el coste: tamaño del contexto, número de llamadas, elección de modelo, caché.
• Qué vigilabas de forma continua y por qué: la latencia de extremo a extremo porque condiciona el uso real, la tasa de llamadas fallidas o fuera de formato porque delata una deriva del proveedor, y la proporción de preguntas sin respuesta o sin fuente citada porque anticipa una pérdida de calidad antes de que los usuarios la reporten.
• Cómo detectabas una regresión tras cambiar un prompt o subir de versión de modelo.
• Qué disparaba una vuelta atrás y quién tomaba esa decisión.

Un cambio de versión de modelo que degrada la calidad en silencio es de los temas más comentados en estas entrevistas. Saber decir cómo lo detectarías suele bastar.

La prueba de código: qué se mira de verdad

El ejercicio de código de un proceso de AI Engineer rara vez es un problema algorítmico difícil. Suele girar alrededor de la llamada al modelo: un contrato de salida que respetar, un servicio que responde mal, un resultado que cambia entre dos ejecuciones.

• Una respuesta fuera de formato: valida el esquema esperado y define qué ocurre cuando la validación falla, en lugar de parsear con optimismo.
• Una llamada al modelo o al servicio que falla o expira: di qué reintentas, qué degradas y qué recibe el usuario cuando no responde nada.
• Salidas no deterministas: muestra cómo haces posible la prueba igualmente — casos congelados, tolerancia explícita, comprobar una propiedad en vez de una cadena exacta.
• Un repliegue asumido cuando la calidad no acompaña: devolver «no lo sé» citando los documentos encontrados es preferible a una respuesta inventada.

Prepara tres ejemplos, no diez proyectos

Un proceso completo se cubre con tres ejemplos trabajados a fondo: un sistema que diseñaste, una evaluación que implantaste y un problema de producción que resolviste. Pueden venir del mismo proyecto.

Usa la misma estructura en los tres: el problema, la restricción dominante, dos decisiones con su motivo, cómo se medía la calidad y un límite asumido. Esa estructura permite responder a preguntas muy distintas sin recitar. Nuestra guía sobre cómo presentar un proyecto de IA en entrevista desarrolla el método completo para construir esos ejemplos.

Las preguntas que conviene hacer al final

Tus preguntas señalan tu nivel tanto como tus respuestas. Con tres basta, siempre que traten sobre lo real.

• ¿Quién posee los datos de los que depende esto y en qué estado están hoy?
• ¿Hay ya algo en producción y quién lo explota en el día a día?
• ¿Quién decide la hoja de ruta y cómo se juzga internamente el valor del sistema?

Las respuestas dirán más que el título del puesto: una organización sin datos disponibles ni nada en producción suele necesitar a alguien que abra camino, no a quien explote un sistema —y al revés también.

• Entrevistas
• AI Engineering
• Evaluación
• Producción