Machine Learning Engineer interviewvragen en antwoorden

Voorbeeldantwoord

Ik begin met reproduceerbaarheid: vaste data-versies, versiebeheer van code en een duidelijke evaluatie-opzet. Daarna pak ik de inference-kant aan met een stabiele API, identieke preprocessing voor training en serving en checks op training-serving skew. Tot slot voeg ik monitoring toe op latency, fouten, inputdrift en modelprestatie, en roll ik uit via shadow of canary zodat ik risico's klein houd.

Voorbeeldantwoord

Ik monitor drie lagen: inputfeatures, outputdistributies en waar labels beschikbaar zijn de echte performance. Als die afwijken van een baseline, onderzoek ik of de data, de wereld of de pipeline is veranderd. Daarna bepaal ik of bijsturen, retrainen of een pipeline-fix nodig is. Belangrijk is dat je drift vroeg signaleert, nog voordat gebruikers er last van hebben.

Voorbeeldantwoord

Ik kijk eerst of het probleem echt een patroon in data heeft, of een regelgebaseerde oplossing al genoeg is, en of de businesswaarde opweegt tegen de complexiteit. ML vraagt data, onderhoud, infrastructuur en monitoring, dus het moet aantoonbaar beter zijn dan een simpeler alternatief. Ik check ook of labelkwaliteit en meetbaarheid haalbaar zijn. Soms is het beste advies juist om geen ML te gebruiken.

Voorbeeldantwoord

Ik vertaal eerst de producteis naar een helder budget voor latency en kosten. Daarna vergelijk ik opties zoals een kleiner model, quantisation, batching, caching of distillation. Ik kijk naar de echte trade-off tussen kwaliteit en operationele haalbaarheid, in plaats van te veronderstellen dat het grootste model het beste is. Het juiste model is het model dat binnen de technische en zakelijke grenzen goed genoeg presteert.

Voorbeeldantwoord

Ik noem een project waarbij het model gekoppeld was aan een meetbare businessmetric, bijvoorbeeld conversie, engagement of foutreductie. Ik leg uit hoe ik de data- en featurepipeline heb opgezet, hoe ik training en serving consistent hield en hoe ik via monitoring en evaluatie de impact aantoonde. Daarbij benoem ik niet alleen het algoritme, maar vooral de engineering eromheen. Dat maakt duidelijk dat ik niet alleen experimenteer, maar ook echt oplever.

Training-serving skew ontstaat wanneer features of preprocessing tijdens inference anders zijn dan tijdens training, waardoor het model in productie slechter presteert. Dat gebeurt vaak door dubbele implementatie van dezelfde logica of verschillen in realtime feature-berekening. Je voorkomt het door dezelfde transformaties te delen tussen training en serving, bijvoorbeeld via een gedeelde pipeline of feature store, en door featurewaarden actief te valideren.

Batch inference draait periodiek grote hoeveelheden data en is efficiënt voor gebruikssituaties zoals nachtelijke segmentatie of recommendations. Online inference geeft per request direct een voorspelling terug en is nodig voor interactieve features, maar vraagt lage latency en hoge beschikbaarheid. De keuze hangt af van freshnesseisen, trafficpatronen en kosten; veel teams combineren beide.

Een feature store is een centrale plek voor het definiëren, berekenen, opslaan en serveren van features voor training en inference. Daarmee voorkom je duplicatie, reduceer je training-serving skew en kun je features hergebruiken over meerdere modellen. Een goede feature store helpt ook met point-in-time correctness, zodat je geen toekomstinformatie lekt in je training data.

Ik kies metrics die passen bij de kosten van fouten, zoals precision, recall, AUC of calibration, in plaats van blind op accuracy te sturen. Daarnaast test ik op een representatieve hold-out set en kijk ik naar slices per belangrijk segment om robuustheid en mogelijke fairness-problemen te zien. Ook check ik of offline winst waarschijnlijk doorvertaalt naar online impact, want dat is in productie uiteindelijk het belangrijkst.

Bagging traint meerdere modellen onafhankelijk op bootstrap-samples en middelt de uitkomsten, zoals bij random forests, om variantie te verlagen. Boosting traint modellen sequentieel waarbij elk model de fouten van het vorige probeert te corrigeren, zoals bij gradient boosting, om bias te verlagen. Boosting haalt vaak hogere scores, maar is lastiger te paralleliseren en gevoeliger voor overfitting dan bagging.

Ik had een model dat sterke offline metrics liet zien, maar live achterbleef. De oorzaak bleek training-serving skew in een feature die online net anders werd berekend. Ik heb de featurelogica samengevoegd in één gedeelde pipeline en validatie toegevoegd die online en offline featurewaarden vergelijkt. Daarna sloot de live performance weer aan op de verwachting en heb ik skew-checks standaard in de deployment-flow gezet.

Ik werkte aan een classificatieprobleem met weinig gelabelde voorbeelden. Ik begon met een eenvoudig model en gebruikte data augmentation en weak supervision om labels sneller op te bouwen. Tegelijk prioriteerde ik via active learning de meest waardevolle nieuwe labels. Ik was open over de onzekerheid, maar leverde wel een bruikbaar model op terwijl we de labelling-pipeline verbeterden.

Voor een realtime feature zat het model boven de latency-budgetten. Ik heb het model kleiner gemaakt via distillation, quantisation toegepast en caching toegevoegd voor veelvoorkomende inputs. Daarna heb ik gecontroleerd dat de kwaliteitsdaling binnen de acceptabele marge bleef. Daardoor haalde het model de latency-eis en kon de feature live.

Bij een deployment werkte ik nauw samen met backend- en platform engineers die weinig ML-achtergrond hadden. Ik schreef een duidelijke inference contract, documenteerde preprocessing en foutafhandeling en deed mee in de integratie. Ook zette ik monitoring op die het team zelf kon beheren. Daardoor kon de oplossing netjes live en bleef het beheer niet alleen bij mij liggen.