"Design a video recommender." The interview question that sinks strong engineers isn't hard because of the model — it's that they dive straight into "I'd use a transformer" and skip everything that actually matters. The people who pass follow a framework: a fixed running order that starts with the problem, not the model. Learn the order and the question stops being scary.
Every good answer walks the same seven stations, in order. The model is one of them, and it's in the middle — the stations before it decide whether you're even solving the right problem, and the ones after decide whether it survives contact with reality. Step through the framework:
The two stations candidates skip are the first and the last. Clarify requirements first — scale, latency budget, and above all what "good" means as a metric — because "recommend videos" could mean maximise watch time, diversity, or new-creator discovery, and they lead to different systems. And monitoring last, because a model that isn't watched for drift silently rots. Say those two out loud and you're already ahead of most candidates.
The power of a framework is that it transfers. Pick a different "design X" and the seven stations stay put — only the answers change. See the whole design fill in for a concrete problem:
Notice what changes between problems and what doesn't. Fraud is extreme class imbalance and a hard latency budget (score before the transaction clears), so precision/recall trade-offs and real-time serving dominate. Recommendation is a two-stage candidate-generation-then-ranking design at massive scale. Search is learning-to-rank with relevance as the metric. Different answers, identical stations — that's the whole point of having a framework.
Second opinion (taught here — these corroborate): Chip Huyen — ML Systems Design · System Design Primer.