Machine Learning Engineer Interview Prep: The Loop Nobody Standardised
Elena Rodriguez
Staff Engineer
Machine learning engineer interviews are the least standardised loop in the industry. Two companies will use the same job title for roles that share almost no interview content, and the most common reason strong candidates fail is that they prepared thoroughly for the wrong one.
Three roles, one job title
| Flavour | The loop is mostly | Tell from the posting |
|---|---|---|
| ML platform / infra | Backend engineering, distributed systems, pipelines | Mentions serving, latency, throughput, orchestration |
| Applied ML | Modelling judgement, metrics, ML system design | Mentions ranking, recommendations, experimentation |
| Research-leaning | Maths, papers, deriving things on a whiteboard | Mentions publications or a specific architecture |
Ask the recruiter directly which rounds you will get. It is a completely normal question, it is almost always answered, and it is the single highest-value thirty seconds in your preparation because it determines everything else.
ML system design, the round that separates people
"Design a recommendation system" is not a modelling question. Candidates who open by choosing an architecture have usually already lost the round, because the assessment is about everything surrounding the model.
The grey bar again. The architecture is the part candidates revise and the part interviewers care least about, because in practice a competent baseline plus good data beats a sophisticated model plus bad labels, and everyone senior has learned that the expensive way.
Start with the metric, always
The strongest opening move is to ask what success means and to notice when the obvious metric is wrong. Click-through rate optimises for clickbait. Accuracy is meaningless on a one percent positive class. Watch time optimises for length rather than value. Saying that unprompted is a seniority signal that arrives in the first two minutes.
| Naive metric | What it actually rewards | Better framing |
|---|---|---|
| Accuracy | Predicting the majority class | Precision and recall at a chosen operating point |
| Click-through rate | Sensational content | A downstream engagement or satisfaction signal |
| Offline AUC | Fitting the historical distribution | Online test against a business metric |
| Fraud caught | Blocking legitimate customers | Cost-weighted, with the false positive priced in |
"All models are wrong, but some are useful."
- George E. P. Box, Robustness in the Strategy of Scientific Model Building (1979)
Box's line is the correct posture for the whole round. You are not being asked for the right model. You are being asked whether you know what your model is wrong about, and whether you would notice when it stopped being useful.
The data questions people are unprepared for
Three come up constantly and all three punish a rehearsed answer. Where do your labels come from, and what is biased about them. What in your feature set would not have been available at prediction time. And what happens to this model six months after launch, when the distribution has drifted and nobody has retrained it.
๐ Leakage is the classic trap
Many ML design prompts contain a feature that quietly encodes the answer. Interviewers add it deliberately. Spotting it, saying "that would not exist at prediction time", and removing it is often the specific thing the question was built to test.
The coding round is still there
Nearly every ML engineer loop includes a normal coding round, and a proportion of candidates underprepare for it on the grounds that the role is about modelling. It is usually a standard data structures problem, sometimes with a numerical flavour, and occasionally implementing something like k-means or a simple gradient step by hand.
Prepare it exactly as any other engineer would, including out loud. The narration matters more here than usual, because the interviewer is trying to work out whether you write production code or notebooks, and the way you talk about your own code is the strongest available evidence.
