Come intervistare ingegneri di applicazioni LLM (non ingegneri ML)

Il ruolo che stai veramente cercando

"Ingegnere LLM" o "ingegnere di applicazioni AI" è una figura che non esisteva nemmeno tre anni fa e ora si trova in ogni product organization. Non è lo stesso lavoro di un ingegnere di machine learning. Le competenze si sovrappongono probabilmente al 30%.

Un ingegnere di machine learning addestra e serve modelli. Un ingegnere di applicazioni LLM prende modelli pre-addestrati e li trasforma in feature di prodotto: design dei prompt, framework di valutazione, pipeline di recupero dati, scaffolding per l'uso di tool, ottimizzazione della latenza e dei costi, gestione elegante dei fallimenti quando il modello esce dal copione. I più senior dedicano il loro tempo alla metà noiosa del lavoro — valutazione, osservabilità, guardrail — non alla genialità dei prompt.

Se valuti questi candidati con il kit di intervista per ingegneri ML, assumerai ricercatori che non riescono a lanciare feature e rifiuterai chi sa davvero spedire il codice ma non ha mai addestrato un modello. Se li valuti con il kit standard per ingegneri software, perdi completamente la superficie di competenze specifiche dell'IA.

Cinque competenze che vale la pena testare

Il ruolo si scompone in cinque aree testabili. La maggior parte dei loop può coprire quattro di cinque in tre ore di tempo del candidato.

1. Design e iterazione dei prompt. Riescono a scrivere un prompt che produce in modo affidabile output strutturato, e sanno iterare quando non funziona?
2. Capacità di valutazione. Riescono a progettare una valutazione che rileva una regressione che una valutazione basata sulla sensazione non coglierebbe?
3. Ragionamento sui casi di errore. Quando il modello ritorna risultati inutili, hanno un modello mentale del perché e un piano per correggerlo?
4. Integrazione di sistema. Riescono a integrare il modello in una vera superficie di prodotto — recupero dati, tool call, streaming, retry, caching — senza che ceda in produzione?
5. Consapevolezza di costi e latenza. Sanno quanto costano le loro scelte? Sanno quale impatto ha un'attesa di 30 secondi sulla fiducia dell'utente?

La capacità cognitiva e l'ingegneria software generale rimangono importanti. Considerale come prerequisiti, non come focus dei round specifici per LLM.

Un loop a quattro stadi che funziona

Questo è il loop che consigliamo per un ruolo di ingegnere di applicazioni LLM di livello intermedio-senior.

Stadio 1: Campione di lavoro asincrono sulla progettazione di prompt (90 minuti)

Dai al candidato un piccolo dataset — 30-50 coppie di input-output che rappresentano un compito di prodotto realistico. Esempi: estrarre campi strutturati da email di supporto clienti, classificare un ticket di supporto in una di sette categorie con un punteggio di confidenza, generare un riassunto email personalizzato da un registro di eventi clienti.

Il loro compito: scrivere un prompt (o una breve pipeline di prompt e codice) che produca l'output desiderato sul dataset, più una nota di un paragrafo su dove ancora fallisce e perché.

Consenti qualsiasi strumento di IA. Questo è un round di Policy B — vedi la nostra guida sulla politica di uso dell'IA per la formulazione esatta. La competenza che stai misurando è come usano gli strumenti per costruire con gli strumenti, non se riescono a farlo da soli.

Valuta in base a:

• Affidabilità dell'output su tutto il dataset
• Qualità dell'analisi dei casi di errore (il paragrafo è più rivelatrice del prompt stesso)
• Se hanno cercato valutazioni, o solo hanno osservato i risultati

Stadio 2: Design della valutazione dal vivo (45 minuti)

Mostra loro il prompt dello Stadio 1 e una versione deliberatamente compromessa dello stesso. Chiedi loro di progettare una valutazione che rilevi la regressione — non solo verbalmente, ma scrivendo il codice del test di valutazione in un editor vero.

Questo è il round più discriminante del loop. I candidati forti:

• Distinguono gli stili di valutazione exact-match, somiglianza semantica e valutazione con rubrica, e scelgono quello giusto per il compito
• Costruiscono casi positivi distinti, casi limite e casi avversariali
• Parlano di come la suite di valutazione verrà eseguita in CI, quale deve essere la soglia di fallimento, e come la aggiorneranno nel tempo

I candidati deboli scriveranno tre assert che testano solo il percorso felice e lo considerano fatto.

Esegui questo in un editor di codice collaborativo così puoi osservare il processo di pensiero del candidato keystroke per keystroke. Le pause ti dicono molto.

Stadio 3: Design di sistema — costruire con il modello (60 minuti)

Fornisci loro una brief di prodotto: "Progetta il backend per una feature che consenta a un rappresentante di vendita di incollare gli ultimi 90 giorni di ticket di supporto di un cliente e ottenere un'analisi di un paragrafo 'dobbiamo preoccuparci dell'abbandono' che può condividere con il manager dell'account."

Indaga su:

• Come strutturerebbero il prompt (system, user, tool call?)
• Come gestirebbero il profilo di costi e latenza (sincrono? asincrono con webhook? in streaming?)
• Come lo testerebbero (esempi d'oro, A/B contro una baseline, loop umano?)
• Come rileverebbero una regressione dopo il prossimo aggiornamento del modello
• Cosa farebbero se il modello allucinasse uno specifico nome di account

L'artefatto è la conversazione, non un diagramma. Vedi la nostra rubrica per il system design per guida al punteggio.

Stadio 4: Presentazione più comportamentale strutturato (45 minuti)

Un singolo round diviso in due metà. Prima, 25 minuti per presentare il campione di lavoro dello Stadio 1 con il modello di domande di follow-up. Poi 20 minuti di domande comportamentali strutturate sulla collaborazione con stakeholder non-engineering — product, design, support — poiché la maggior parte dei casi di errore nelle feature LLM vengono rilevati da persone che non scrivono codice.

Pattern di domande che producono vero segnale

Tre pattern che meritano di essere rubati per qualsiasi round di ingegneria di applicazioni LLM.

"Mostrami un prompt che hai scritto che si è rotto in produzione. Cosa hai cambiato?" Questa è la singola domanda migliore nel kit. I candidati forti hanno storie specifiche con correzioni specifiche. I candidati deboli parlano di prompt design in astratto.

"Qual è il modello più economico che potresti usare per questa feature? Perché non lo stai usando?" Testa la consapevolezza dei costi e li obbliga a articolare il compromesso qualità-costo che implicitamente hanno scelto. La risposta "raggiungo sempre il modello più grande" è preoccupante a qualsiasi livello di seniority.

"Come sai che il tuo prompt è migliore della versione precedente?" Testa se effettivamente eseguono valutazioni o solo si fidano della sensazione. Una frazione sorprendente di candidati ha lanciato feature con LLM senza mai misurare la qualità.

Cosa non funziona

Alcuni approcci che abbiamo visto i team provare e abbandonare.

• Interviste di algoritmi in stile LeetCode. Quasi nessun lavoro di applicazione LLM è algoritmico. Il segnale che ricevi è scorrelato dal ruolo. Vedi fare screening degli sviluppatori senza LeetCode per l'argomento più ampio.
• "Costruisci un chatbot da zero in 90 minuti." Testa la velocità di digitazione, non l'ingegneria. Le decisioni interessanti vivono nel design della valutazione e nella gestione dei fallimenti, non nel collegamento di una chiamata API.
• Screen su trivia sui prompt. "Cos'è la temperatura?" testa il vocabolario, non il giudizio. Testa il giudizio direttamente.
• Lavagne di matematica sugli interni dei transformer. Utile se assumi un ricercatore di modelli. Irrilevante per qualcuno che passerà la sua settimana su pipeline di recupero dati e suite di valutazione.

La questione dell'integrità per un ruolo che usa l'IA

Questa è la domanda di round-tripping che ogni team affronta: se il candidato è autorizzato a usare Claude o ChatGPT durante il campione di lavoro, cosa lo impedisce di far fare il lavoro semplicemente dal modello?

Tre cose, in combinazione:

1. La presentazione dello Stadio 4. Un candidato che non riesce a difendere il proprio prompt, valutazione o system design non ha veramente fatto il lavoro — qualunque dica l'artefatto.
2. Il design della valutazione dal vivo dello Stadio 2. Questo round gira in un editor proctored senza strumenti di chat, in 45 minuti. È difficile fingere.
3. Analisi della coerenza del codice sulla presentazione dello Stadio 1. Il codice generato dall'IA ha indicatori strutturali anche quando il candidato ha usato anche l'IA per mascherarli.

Il punto non è catturarli con le mani nel sacco. È assicurarsi che il punteggio di ogni candidato rifletta quello che può fare in una vera settimana di ingegneria, con gli strumenti che effettivamente useranno.

Cosa fare dopo

Se stai lanciando hiring per LLM questo trimestre, la mossa con la massima leva è smettere di riutilizzare il loop per ingegneri backend senior. Scegli tre delle cinque competenze sopra per la tua prima versione della rubrica, scrivi un campione di lavoro e un esercizio di design della valutazione, ed eseguili su due ingegneri interni per calibrare.

Poi eseguili su cinque candidati esterni. Già dal candidato tre saprai se il loop è più acuto di quello che avevi prima. I ruoli cambiano. La disciplina — scegli metodi che producono vero segnale, poi verifica che il segnale sia del candidato — no.