10 ML Interview Mistakes Even Senior Engineers Make

These aren't mistakes made by junior candidates who don't know the material. These are the subtle, frustrating errors that sink engineers who absolutely know what they're talking about — but don't know how to show it in 45 minutes.

1. Starting architecture before framing the problem.

The single most common mistake at Staff level. An interviewer says "design a recommendation system for Spotify." The candidate immediately starts drawing boxes: two-tower model, HNSW index, Redis feature store. The interviewer asks: "what latency constraint are you designing for?" Silence.

Fix: spend the first 8 minutes on problem framing. Users and their goals. Latency. Scale. Constraints. The architecture flows from the constraints.

2. Treating AUC as the only metric.

Recommending AUC when asked "how would you evaluate this model" signals shallow evaluation knowledge. Real answer: what does success mean for the business? CTR? Session length? Revenue? Then: what offline proxy best predicts online success? Then: how do you validate that the offline metric actually predicts the online metric?

3. Not knowing what P99 latency means for your system.

If you can't give a rough latency budget for your design (e.g., "10ms feature fetch + 45ms retrieval + 8ms ranking = 63ms total, P99 should be under 100ms"), you don't have a production ML system — you have a notebook experiment.

4. Saying "I'd use a transformer" without justification.

Transformers are powerful. They're also slow, expensive, and overkill for tabular data, sparse feature models, and many production ranking systems. "I'd use a transformer" without latency/scale analysis signals that you're applying learned patterns, not reasoning.

5. Confusing offline and online evaluation.

"Our model has AUC 0.96" — offline metric. "Our CTR increased 3%" — online metric. The gap between them is where production ML fails. Interviewers at senior levels will probe: how do you know your offline metrics predict online improvement? What have you seen break this correlation?

6. Ignoring data quality and label noise.

Strong candidates mention: what are the label sources? What biases do they have? Position bias, selection bias, label delay. "Implicit feedback (clicks) is biased toward popular items" demonstrates practical knowledge. Ignoring it signals academic exposure only.

7. Not knowing when NOT to use ML.

A question like "how would you personalise the home feed for a platform with 100 users?" should be answered with "I wouldn't use ML yet — build good heuristics, instrument them, collect data, then train a model once you have 10,000+ users and a defined success metric." Applying ML to every problem signals poor engineering judgment.

8. Describing monitoring as an afterthought.

Saying "and then we'd monitor it" at minute 42 of a 45-minute interview. Strong candidates allocate time for monitoring because they've been paged at 2am. What specific metrics would you alert on? What's the threshold? What do you do when an alert fires?

9. Not discussing failure modes.

"What happens if the model is down? What happens if the feature store returns stale data? What happens if a new item has no embedding?" These aren't trick questions — they're the most important questions. Production ML engineers have been burned by these.

10. Not asking clarifying questions when uncertain.

Spending 20 minutes designing a batch inference system when the interviewer had real-time in mind. Or vice versa. Clarifying questions aren't a sign of weakness — they're a sign you understand that requirements matter. Ask once, confirm your understanding, then proceed.