Hoe Machine Learning Engineers Interviewen: Een Speelboek voor 2026

Waarom ML hiring loops van 2023 niet meer werken

Een standaard machine learning interview van 2023 vroeg de kandidaat om bias-variance uit te leggen, logistische regressie af te leiden, k-means te coderen en een recommender pipeline op een whiteboard te schetsen. In juni 2026 worden al vier deze vragen in minder dan dertig seconden opgelost door elk model dat de kandidaat in een ander tabblad open heeft. De vragen zijn nog steeds goed — het signaal is verdwenen.

Wat niet verdwenen is, is het waar je eigenlijk voor wilt inhuren: beoordelingsvermogen onder onzekerheid, MLOps vaardigheid, het vermogen om een verslechterd model in productie op te sporen en de bereidheid om te zeggen "we hebben machine learning hier niet nodig." Hieronder staat de loop die we in 2026 voor het inhuren van ML engineers zien werken, de rubric om het mee te scoren en waar je integriteitssignalen toepast zodat AI-hulp de loop niet zinloos maakt.

Wat veranderd is in de afgelopen 24 maanden

Drie verschuivingen waar de loop rekening mee moet houden:

• LLM's hebben de fundamentals gecommoditiseerd. Definitievragen, klassieke algoritme afleidingen en standaard model selectie write-ups zijn nu standaard — elke kandidaat haalt ze goed omdat het model ze goed haalt. Ze zeggen je niets.
• Productie is het grootste deel van het werk. Een model trainen is misschien 10% van het werk. De rest is datapijpleidingen, drift detection, feature store onderhoud, eval harnesses en on-call voor inference latency. Een loop die productiewerk niet onderzoekt, huurt onderzoekers aan voor engineering rollen.
• "ML engineer" omvat nu drie banen. Klassieke ML / tabellaire data, deep learning / vision-NLP en applied LLM / RAG / agent engineering. Voer niet dezelfde loop uit voor alle drie. Kies de kant voordat je de rubric schrijft.

De loop: vier stadia, ~5 uur totaal

Een loop die in 2026 echt signaal produceert:

1. Applied ML coding (live, 60 min). Een klein, realistisch ML probleem dat de kandidaat met een interviewer aanwezig doorwerkt.
2. ML system design (live, 60 min). End-to-end ontwerp van een productie systeem, met expliciete cost, drift en eval discussie.
3. Production debugging (async + live walk-through, 90 min). Een verbroken pijplijn of een verslechterd model dat de kandidaat diagnoseert.
4. Behavioral / collaboration (live, 45 min). Eerdere project ownership, conflict, on-call ervaring.

Kun je maar twee stadia uitvoeren, voer dan #2 en #3 uit. Deze hebben de hoogste predictieve validiteit voor ML engineering werk en het laagste LLM-lekkage risico.

Stadium 1: Applied ML coding — maak het specifiek, niet algoritmisch

Vervang de klassieke "implementeer logistische regressie from scratch" met een 45-minuten applied taak: hier is een kleine dataset, hier is een doel, bouw een baseline, rechtvaardig de metric en ship een notebook dat een ander engineer zou kunnen beoordelen. De kandidaat gebruikt een echte editor met pandas, scikit-learn en PyTorch geïnstalleerd. Ze worden aangemoedigd om documentatie te gebruiken. Of ze completions van een LLM kunnen plakken of niet, is jouw keuze — maar wees expliciet hoe dan ook (zie ons standpunt over AI gebruik in coding rounds).

Wat je beoordeelt:

• Problem framing. Vroegen ze wat de voorspelling voor was voordat ze iets trainden?
• Eval choice. Waarom deze metric? Hoe ziet de confusion matrix eruit op de operating threshold?
• Iteration discipline. Valideerden ze baseline voordat ze tuning deden? Hebben ze de test set gelekt?
• Code quality. Reproduceerbaar? Een tweede engineer zou dit notebook kunnen uitvoeren? Hebben de cellen zin?

Een kandidaat die zwijgend acht cellen model tuning uitvoert en een 0.94 AUC produceert, heeft je niets laten zien. Een kandidaat die het probleem frameert, een domme baseline bouwt en tot 0.78 komt met duidelijke redenering, is een sterkere hire.

Gebruik een structured rubric zodat twee interviewers die dezelfde notebook beoordelen convergeren op een score.

Stadium 2: ML system design — het signaal-sterkste uur dat je zult uitvoeren

Kies een probleem dat aansluit bij je werkelijk product oppervlak: "ontwerp een churn prediction pijplijn die dagelijks draait en het lifecycle marketing systeem voedert." Of voor LLM rollen: "ontwerp een RAG systeem voor support tickets met een 200ms p95 latency budget."

De kandidaat moet doorpraten over:

• Data sources, freshness vereisten, schema evolution
• Feature engineering, lekkage bescherming, feature store keuze (of geen feature store, en waarom)
• Model selectie met expliciete cost / latency / accuracy trade-offs
• Eval harness: offline metrics, online metrics, de kloof tussen hen
• Deployment: shadow mode, canary, rollback criteria
• Monitoring: data drift, prediction drift, business-metric drift, alerting thresholds
• On-call: wat wekt iemand op, welke runbook volgen ze

Een veelvoorkomend faalpatroon: kandidaten beschrijven de architectuur maar noemen nooit een enkel getal — geen QPS doel, geen latency budget, geen retraining cadence. Duw naar getallen. ML system design zonder getallen is creatief schrijven.

Dit stadium is de dichtstbijzijnde analoog aan het werk dat de engineer op maandag zal doen. Weeg het zwaarst in je scorecard.

Stadium 3: Production debugging — wat de LLM niet kan faken

Stuur de kandidaat een take-home: hier is een notebook + een kleine dataset + een model artifact. De eval metric van het model op de holdout set ziet er geweldig uit. De productie metric van het model verslechtert al zes weken zwijgend. Vind de bug.

Plant een realistisch falen: een feature die gebruikt werd ingevuld 99% van de tijd is nu ingevuld 60%, waarbij de ontbrekende waarden stilzwijgend met het kolom gemiddelde worden gevuld (en het gemiddelde is verkeerd). Of trainingsgegevens hebben het label gelekt door een bijna-duplicate feature. Of het embedding model dat het team gebruikt is omgewisseld naar een nieuwe versie en de index is niet herbouwd.

De kandidaat stuurt een geschreven diagnose en een voorgestelde fix in, verdedigt dit vervolgens in een 30-minuten walk-through. Dit is de round waar je erachter komt of ze werkelijk een productie systeem hebben bezeten. Het is ook de round waar LLM hulp het minst helpt — de bug zit niet in de code, het zit in de gegevens en het deployment verhaal. De kandidaat moet over een systeem nadenken, niet een definitie oplepelen.

Volg het walk-through patroon: onderzoek specifiek, dwing hen hun hypothese te verdedigen, vraag wat ze eerst zouden hebben shipped.

Stadium 4: Behavioral — kies collaboration en incident verhalen

Sla "vertel me over een keer dat je een project leidde" over. Vraag:

• "Loop me door de laatste production incident die je bezat. Wat brak, wat shipt je, wat veranderde je daarna in het proces?"
• "Vertel me over een keer dat je besloot ML niet voor een probleem te gebruiken. Wat shipt je in plaats daarvan?"
• "Wanneer was de laatste keer dat je een model in productie doodde? Waarom?"

Deze vragen filteren naar engineers die shipped hebben, niet onderzoekers die gepubliceerd hebben. Beoordeel met een structured rubric zodat het niet instort in vibes.

Het eerlijk houden: waar integriteitssignalen het meest uitmaken

De fundamentals round is weg omdat LLM's hem aced; dat laat stadia 1 en 3 achter als de rounds waar AI hulp materieel signaal vervormt. Twee dingen om te doen:

• Voer keystroke biometrics en code coherence uit op de applied coding round. Burst-paste events, authorship drift mid-notebook en code-comment fluency mismatches all surface in the integrity report.
• Gebruik de production-debug walk-through als de echte check. Een kandidaat die hun diagnose van een LLM plakte, kan niet verdedigen wanneer je vraagt "wat is het volgende experiment dat je zou uitvoeren?" De walk-through is betrouwbaarder dan elke classifier.

Het doel is niet AI hulp te verbieden — engineers gebruiken het op de baan. Het doel is te bevestigen dat de persoon die je huurt, de persoon is die het werk kan doen.

Wat je overslaat

• "Codeer lineaire regressie from scratch." Iedereen kan dit plakken. Het zegt je niets.
• "Wat is het verschil tussen L1 en L2 regularisatie?" Hetzelfde.
• LeetCode-stijl algoritmische puzzels. ML engineers hebben af en toe datastructuren nodig, maar een dagelijkse-leet grind voorspelt ML engineering niet. Als je een coding screen wilt, gebruik in plaats daarvan een klein data-manipulation probleem met pandas.
• Twee-uur take-homes zonder walk-through. De walk-through is wat de take-home laat werken.

Wat je vervolgens doet

Kies de kant (tabellaire / DL / LLM-applied), schrijf een rubric voor elk stadium voordat het eerste interview, en voer de loop end-to-end uit op een interne engineer om te kalibreren. Volg score-to-performance correlatie op zes maanden — die feedback loop is wat de loop volgende kwartaal beter maakt.

De teams die goed inhuren in 2026 stellen niet moeilijkere vragen. Ze stellen vragen waar het antwoord vereist dat de kandidaat hardop denkt, keuzes verdedigt en redeneert over systemen die de LLM nog nooit heeft gezien. De loop hierboven is rond dat principe gebouwd.