Come intervistare ingegneri AI (ruoli LLM, RAG e Prompt Engineering)

"Ingegnere AI" sono tre ruoli diversi travestiti

Prima di progettare il loop di interviste, decidi quale di questi stai effettivamente cercando:

1. Ingegnere AI applicativo — sviluppa funzionalità di prodotto su foundation model. Gestisce prompt, valutazioni, retrieval, latenza, costo. Lavora nella codebase dell'applicazione.
2. Ingegnere ML (model-side) — addestra, affina o distilla modelli. Gestisce dataset, infra di training, suite di valutazione. Lavora nello stack di training.
3. Ingegnere infrastruttura AI — gestisce l'inferenza, il vector DB e il layer di osservabilità. Gestisce budget di latenza, utilizzo GPU, pipeline di deployment. Lavora nella piattaforma.

Questi tre ruoli non condividono nulla del loro lavoro quotidiano. Un loop progettato per uno valuterà male gli altri due. Il resto di questa guida si concentra sull'ingegnere AI applicativo, perché è quello che l'80% dei team che assumono "ingegneri AI" nel 2026 effettivamente cercano.

I quattro segnali che effettivamente predicono la performance lavorativa

Dopo aver auditato dozzine di loop di hiring per AI applicativo, quattro segnali separano costantemente gli ingegneri che spediscono funzionalità LLM funzionanti da quelli che spediscono demo plausibili:

1. Disciplina di iterazione dei prompt. Riescono a trasformare un requisito di prodotto vago in un prompt, una valutazione e un loop di miglioramento misurabile?
2. Ragionamento sui failure mode. Presumono di default che il modello allucingerà, perderà token o sceglierà lo strumento sbagliato — e progettano di conseguenza?
3. Progettazione di valutazioni. Riescono a progettare una valutazione che cattura la regressione che effettivamente ti interessa, non solo BLEU score?
4. Consapevolezza di costo e latenza. Ragionano sui token, caching, selezione del modello e batch shape — oppure ricorrono a GPT-5 per ogni chiamata?

Nessuno di questi è testabile con una domanda LeetCode. Tutti e quattro richiedono un formato di intervista diverso.

Il loop a quattro round che funziona

Round 1: Esercizio asincrono da svolgere a casa (90 minuti, pagato se la tua cultura lo supporta)

Dai al candidato un piccolo sistema RAG rotto e un reclamo reale di un cliente. Esempio:

Il nostro chatbot di supporto clienti continua a citare con sicurezza una funzionalità di prodotto che non esiste. Ecco il repo, il prompt, la pipeline di retrieval e tre esempi di fallimenti. Trova la causa radice e proponi una correzione che tu possa difendere.

Cosa stai cercando:

• Legge i risultati del retrieval prima di incolpare il prompt?
• Identifica che il modello di embedding è probabilmente sbagliato per questo dominio?
• Propone una valutazione per catturare la regressione la prossima volta?
• Distingue "correggere il sintomo" da "correggere il sistema"?

Un esercizio da svolgere a casa è l'unico formato che ti dà una lettura pulita della disciplina di debug. I live coding round sono troppo brevi e sotto troppa pressione per vedere se qualcuno effettivamente legge i dati. Accoppialo con un seguire dal vivo così i prompt generati da AI non sfuggono.

Round 2: Sessione di prompt engineering dal vivo (60 minuti)

Affiancare il candidato con un intervistatore e un compito reale: prendere un brief di prodotto vago e trasformarlo in un prompt funzionante con valutazioni misurabili, in tempo reale, utilizzando il tuo vero tooling.

Sotto-compiti utili:

• Scrivi il prompt di prima bozza.
• Scrivi tre casi di valutazione — incluso uno che dovrebbe fallire.
• Itera il prompt finché le valutazioni non passano.
• Discuti cosa misurerei in produzione oltre il set di valutazione.

Segnale che stai cercando: pensano in valutazioni prima, prompt dopo? Gli ingegneri che hanno spedito funzionalità LLM sanno che il prompt è a valle della valutazione. Gli ingegneri che hanno solo prototipato fanno il contrario.

Una stanza di codifica collaborativa con Monaco + Yjs funziona per questo — il candidato scrive prompt e scaffolding di valutazione in tempo reale, e l'intervistatore può intervenire esattamente quando conta.

Round 3: System design — ma con forma di AI (60 minuti)

Butta il candidato in un prompt di design AI applicativo realistico:

Progetta un strumento di riassunto di riunioni rivolto al cliente che acquisisce una trascrizione di 60 minuti e produce un elenco di elementi d'azione. Deve funzionare in meno di 30 secondi, costare meno di $0,05 per chiamata e rifiutare di riassumere contenuti al di fuori del dominio del nostro prodotto.

Questo è un intervista di system design con vincoli specifici per l'AI. Valutalo con le stesse dimensioni — chiarificazione, compromessi, failure mode, costo — ma guarda le mosse specifiche per l'AI:

• Considerano chunking e map-reduce rispetto a single-shot?
• Ragionano sulla selezione del modello (modello più piccolo + prompt migliore vs modello più grande)?
• Propongono un guardrail per contenuto fuori dominio (classificatore? prompt? rejection eval)?
• Progettano osservabilità per tasso di allucinazione, non solo latenza?

I cattivi candidati ricorrono di default a "usa GPT-5, interrogalo, restituisci la risposta". I buoni candidati trascorrono 10 minuti sul budget costo/latenza prima di disegnare una singola scatola.

Round 4: Comportamentale su una funzionalità AI spedita (45 minuti)

Un round comportamentale strutturato ancorato su una funzionalità specifica che hanno spedito. Le domande che funzionano:

• "Raccontami la suite di valutazione che hai costruito. Come è cambiata nel tempo?"
• "Raccontami di una regressione che è arrivata in produzione. Come l'hai trovata?"
• "Descrivi un momento in cui hai usato un modello più piccolo quando uno più grande sarebbe stato più facile. Perché?"
• "Raccontami di una funzionalità dove l'LLM era lo strumento sbagliato. Cosa hai spedito invece?"

Quell'ultima domanda è quella con il segnale più alto nel loop. Gli ingegneri che hanno solo usato gli LLM come martello non possono rispondere. Gli ingegneri che hanno spedito vero prodotto riescono di solito a dirti di tre.

Domande che sembrano intelligenti ma non lo sono

Queste emergono costantemente nelle guide di interviste per ingegneri AI e sono per lo più rumore:

• "Spiega come funzionano i transformer." Trivia. Ogni candidato ha letto lo stesso articolo di blog. Non ti dice nulla se riescono a spedire.
• "Qual è la differenza tra RAG e fine-tuning?" Già in ogni training set. Usa un pattern di follow-up invece: "raccontami di un momento in cui ne hai scelto uno rispetto all'altro e perché."
• "Scrivi un transformer da zero." Rilevante solo per il ruolo model-side ML engineer. Per AI applicativo, questo è segnale di background accademico, non capacità di spedire.
• Prompt engineering su lavagna ("scrivi un prompt che fa X" senza valutazione e senza iterazione). Non ancorato al modo in cui il lavoro effettivamente accade. Un prompt in isolamento, senza una valutazione, è teatro.

Calibrazione per seniority

Lo stesso loop funziona a tutti i livelli — quello che cambia è cosa dai peso.

Un ingegnere AI applicativo staff dovrebbe essere valutato principalmente su system design e comportamentale — a quel livello, stai acquistando giudizio, non velocità di implementazione. Un ingegnere di livello mid dovrebbe essere valutato principalmente su esercizio da casa e sessione di prompt — è lì che sta il loro valore. Vedi il senior engineer interview loop per la suddivisione equivalente sui ruoli di ingegneria generale.

Integrità, ma più intelligente

Per ruoli di AI applicativo specificamente, vietare l'assistenza di AI durante l'intervista è incoerente. Il lavoro è usare bene l'AI. L'intervista dovrebbe riflettere questo.

Quello che consigliamo invece:

• Consenti assistenza di AI apertamente nell'esercizio da casa. Valuta l'uso di AI, non la sua presenza. Il candidato che usa Claude per esplorare la codebase e poi scrive un'analisi di causa radice ponderata è esattamente il candidato che vuoi.
• Vieta AI nella sessione di prompt dal vivo. Il punto è guardarli iterare. Usa segnali di keystroke e schermo per catturare l'uso silenzioso di AI.
• Richiedi un follow-up dal vivo su ogni esercizio da casa. Questo è il singolo intervista con segnale più alto che la maggior parte dei team salta. Abbina un pass di coerenza LLM con una walkthrough dal vivo di 30 minuti.

Il candidato che riesce a difendere il suo esercizio da casa per 30 minuti l'ha scritto. Quello che non riesce, no — indipendentemente da quello che i segnali di keystroke dicono.

Cosa fare dopo

Se stai configurando un loop di ingegneria AI applicativa da zero:

1. Scegli una delle tre definizioni di ruolo e scrivi una descrizione di lavoro che corrisponda.
2. Costruisci (o riusa) un esercizio da svolgere a casa con RAG rotto. Iteralo sugli ingegneri interni prima.
3. Configura la sessione di prompt dal vivo in un editor collaborativo con scaffolding di valutazione condiviso.
4. Allena gli intervistatori sui quattro segnali sopra prima che eseguano un singolo round.

I team che assumono ingegneri AI bene nel 2026 non sono i team con le domande più intelligenti. Sono i team i cui loop rispecchiano il lavoro effettivo — iterare, valutare, debuggare, spedire — e che valutano per il giudizio che richiede anni per costruire.