Come intervistare i Machine Learning Engineer: Una Guida 2026

Perché i cicli di colloqui ML del 2023 non funzionano più

Un colloquio standard del 2023 per machine learning chiedeva al candidato di spiegare bias-varianza, derivare la regressione logistica, codificare k-means e disegnare una pipeline di raccomandazione su una lavagna. Nel giugno 2026, tutte e quattro quelle domande vengono risolte in meno di trenta secondi da qualsiasi modello che il candidato ha aperto in un'altra scheda. Le domande sono ancora buone — il segnale è scomparso.

Quello che non è scomparso è la cosa per cui hai effettivamente bisogno di assumere gente: giudizio in condizioni di incertezza, padronanza di MLOps, capacità di debuggare un modello che si degrada in produzione, e disponibilità a dire "non abbiamo bisogno di machine learning per questo". Sotto è il ciclo che funziona nel 2026 per l'assunzione di ML engineer, la rubric per valutarlo, e dove applicare i segnali di integrità in modo che l'assistenza AI non renda il ciclo inutile.

Cosa è cambiato negli ultimi 24 mesi

Tre shift che il ciclo deve riflettere:

• I LLM hanno reso commodities i fondamenti. Le domande definitorie, le derivazioni classiche di algoritmi, e i writeup standard di model selection sono ormai table stakes — ogni candidato le prende giuste perché il modello le prende giuste. Non ti dicono nulla.
• La produzione è la maggior parte del lavoro. L'addestramento di un modello è forse il 10% del lavoro. Il resto è data pipeline, drift detection, feature store hygiene, eval harness, on-call per la latenza dell'inferenza. Un ciclo che non indaga il lavoro in produzione assume ricercatori in ruoli di ingegneria.
• "ML engineer" ora copre tre lavori. Classical ML / tabular, deep learning / vision-NLP, e applied LLM / RAG / agent engineering. Non eseguire lo stesso ciclo per tutti e tre. Scegli la lane prima di scrivere la rubric.

Il ciclo: quattro stage, ~5 ore totali

Un ciclo che produce vero segnale nel 2026:

1. Applied ML coding (live, 60 min). Un piccolo problema di ML realistico che il candidato affronta con un intervistatore presente.
2. ML system design (live, 60 min). Design end-to-end di un sistema in produzione, con discussione esplicita di costo, drift e valutazione.
3. Production debugging (async + live walk-through, 90 min). Una pipeline rotta o un modello degradato che il candidato diagnostica.
4. Behavioral / collaboration (live, 45 min). Ownership di progetti passati, conflitto, esperienza on-call.

Se puoi eseguire solo due stage, esegui il #2 e il #3. Hanno la validità predittiva più alta per il lavoro di ML engineering e il rischio di leakage di LLM più basso.

Stage 1: Applied ML coding — rendilo specifico, non algoritmico

Sostituisci il classico "implementa regressione logistica da zero" con un compito applicato di 45 minuti: ecco un piccolo dataset, ecco un target, costruisci una baseline, giustifica la metrica, e spedisci un notebook che un altro ingegnere potrebbe revisionare. Il candidato usa un editor reale con pandas, scikit-learn, e PyTorch installati. Viene incoraggiato a usare la documentazione. Se possono o meno incollare completamenti da un LLM è una tua scelta — ma sii esplicito in entrambi i casi (vedi la nostra presa di posizione su AI in coding rounds).

Cosa stai valutando:

• Problem framing. Hanno chiesto a cosa serve la prediction prima di allenare qualcosa?
• Eval choice. Perché questa metrica? Che aspetto ha la confusion matrix alla soglia operativa?
• Iteration discipline. Hanno validato la baseline prima di fare tuning? Hanno fatto leak del test set?
• Code quality. Riproducibile? Un secondo ingegnere potrebbe eseguire questo notebook? Le celle hanno senso?

Un candidato che esegue silenziosamente otto celle di model tuning e produce un AUC di 0.94 non ti ha mostrato nulla. Un candidato che inquadra il problema, costruisce una baseline stupida, e arriva a 0.78 con ragionamento chiaro è un'assunzione più forte.

Usa una rubric strutturata in modo che due intervistatori che valutano lo stesso notebook convergano su un punteggio.

Stage 2: ML system design — l'ora di segnale più alto che eseguirai

Scegli un problema che si mappa sulla superficie del tuo prodotto reale: "progetta una pipeline di churn prediction che gira quotidianamente e alimenta il sistema di marketing del ciclo di vita." Oppure per ruoli LLM: "progetta un sistema RAG per i ticket di supporto con un budget di latenza p95 di 200ms."

Il candidato deve parlare di:

• Fonti di dati, requisiti di freschezza, evoluzione dello schema
• Feature engineering, protezione da leakage, scelta del feature store (o nessun feature store, e perché)
• Model selection con trade-off espliciti di costo / latenza / accuratezza
• Eval harness: metriche offline, metriche online, il gap tra di loro
• Deployment: shadow mode, canary, criteri di rollback
• Monitoring: data drift, prediction drift, business-metric drift, soglie di allerta
• On-call: cosa sveglia qualcuno, quale runbook seguono

Una failure mode comune: i candidati descrivono l'architettura ma non nominano mai un singolo numero — nessun target QPS, nessun budget di latenza, nessuna cadenza di retraining. Spingi per i numeri. ML system design senza numeri è creative writing.

Questo stage è l'analogo più vicino al lavoro che l'ingegnere farà il lunedì. Pesalo di più nella tua scorecard.

Stage 3: Production debugging — quello che il LLM non può fingere

Invia al candidato un take-home: ecco un notebook + un piccolo dataset + un artefatto di modello. La metrica di valutazione del modello sul set di holdout sembra fantastica. La metrica di produzione del modello si è silenziosamente degradata per sei settimane. Trova il bug.

Pianta un fallimento realistico: una feature che era popolarizzata il 99% delle volte è ora popolarizzata il 60%, con i valori mancanti che vengono silenziosamente riempiti con la media della colonna (e la media è sbagliata). O i dati di addestramento hanno fatto leak dell'etichetta attraverso una feature quasi-duplicata. O il modello di embedding che il team usa è stato scambiato con una nuova versione e l'indice non è stato ricostruito.

Il candidato spedisce una diagnosi scritta e una correzione proposta, poi la difende in un walk-through di 30 minuti. Questo è il round dove scopri se hanno effettivamente posseduto un sistema in produzione. È anche il round dove l'assistenza LLM aiuta meno — il bug non è nel codice, è nei dati e nella storia della distribuzione. Il candidato deve ragionare su un sistema, non rigurgitare una definizione.

Segui il pattern di walk-through: sonda specificamente, chiedi loro di difendere la loro ipotesi, chiedi cosa avrebbero spedito per primo.

Stage 4: Behavioral — scegli collaboration e incident stories

Salta "raccontami di un progetto che hai guidato." Chiedi:

• "Raccontami dell'ultimo incident in produzione di cui eri proprietario. Cosa è andato male, cosa hai spedito, cosa hai cambiato nel processo dopo?"
• "Raccontami di un momento in cui hai deciso di non usare ML per un problema. Cosa hai spedito al suo posto?"
• "Quando è stata l'ultima volta che hai terminato un modello in produzione? Perché?"

Queste domande filtrano per ingegneri che hanno spedito, non ricercatori che hanno pubblicato. Valuta con una rubric strutturata in modo che non crolli in vibes.

Mantenerlo onesto: dove i segnali di integrità contano di più

Il round dei fondamenti è sparito perché i LLM l'hanno vinto; questo lascia gli Stage 1 e 3 come i round dove l'assistenza AI distorce materialmente il segnale. Due cose da fare:

• Esegui keystroke biometrics e code coherence sul round di applied coding. Burst-paste events, authorship drift a metà notebook, e code-comment fluency mismatches emergono tutti nel report di integrità.
• Usa il walk-through di production-debug come il vero controllo. Un candidato che ha incollato la loro diagnosi da un LLM non può difenderla quando chiedi "qual è il prossimo esperimento che eseguiresti?" Il walk-through è più affidabile di qualsiasi classificatore.

L'obiettivo non è vietare l'assistenza AI — gli ingegneri la usano sul lavoro. L'obiettivo è confermare che la persona che stai assumendo è la persona che può fare il lavoro.

Cosa saltare

• "Codifica la regressione lineare da zero." Chiunque può incollarla. Non ti dice nulla.
• "Qual è la differenza tra la regolarizzazione L1 e L2?" Lo stesso.
• Puzzle algoritmici in stile LeetCode. Gli ML engineer occasionalmente hanno bisogno di strutture dati, ma un daily-leet grind non predice ML engineering. Se vuoi uno schermo di codifica, usa un piccolo problema di manipolazione dati con pandas.
• Take-home di due ore senza walk-through. Il walk-through è quello che fa funzionare il take-home.

Cosa fare dopo

Scegli la lane (tabular / DL / LLM-applied), scrivi una rubric per ogni stage prima del primo colloquio, ed esegui il ciclo end-to-end su un ingegnere interno per calibrare. Traccia la correlazione score-to-performance a sei mesi — quel feedback loop è quello che rende il ciclo migliore il prossimo trimestre.

I team che assumono bene nel 2026 non stanno facendo domande più difficili. Stanno facendo domande dove la risposta richiede al candidato di pensare ad alta voce, difendere scelte, e ragionare su sistemi che l'LLM non ha mai visto. Il ciclo sopra è costruito attorno a quel principio.