13.6 ML system design interviews
You can design a recommender or a fraud system on a whiteboard.
ML system design interviews test whether you can architect a recommender or a fraud system end to end — requirements, data, model, serving, monitoring, with scale and cost estimates — and a repeatable framing is the whole game. It sits in the interview run because the capstones supply its raw material. The opening mistake is diving into model choice; strong candidates spend the first minutes on requirements and data, because that is where real systems are actually decided.
Work through these
A repeatable framing: requirements, data, model, serving, monitoring
A repeatable structure for these interviews: clarify requirements, then data, model, serving and monitoring in order. Having a structure is what stops the conversation wandering.
Estimating scale, latency and cost
Estimating traffic, response time and cost from stated requirements. Interviewers ask for these because they separate people who have deployed something from people who have not.
Trade-off discussion and failure modes
Discussing what you gave up for what you gained, and what breaks first under load. This is the part being assessed, not the architecture diagram.
Practice problems: feed ranking, search, fraud, forecasting
The standard problems that recur across companies, worth practising until the structure is automatic. Four common ones are named here.
Sign in to keep your progress.
Free resources
We haven't checked most of these for screen reader use yet.
Links last checked 29 Aug 2026.
Stuck here?
Ask a mentor. A real person answers, and they can see exactly which topic you're on. Usually within a couple of working days.
Checking your session…
Topics shown in module order.