Most machine learning (ML) system design interviews open with something vague: "Our music-streaming service is losing subscribers. Reduce churn." There is no correct model for that sentence yet. Before you can talk about data or architecture, you have to turn the goal into a precise prediction problem, and the interviewer's first test is often blunter: "Should this even be ML?" ML problem framing is that translation step. It decides whether to use a model at all, what kind of output you need, exactly what you predict for whom and when, how you will know it worked, and which limits shape the design.

Framing takes the first 5-10 minutes of the round, and it decides whether the rest of your answer is aimed at the right problem. A mid-level answer gives a rule baseline, a task type, a precise target, and one business plus one model metric. A senior-level answer also checks whether the target measures what the business actually wants and whether improving the model metric is likely to improve the business result.

One example runs through the whole tutorial. A music-streaming service has 10m paying subscribers, about 3% of them (300k) cancel each month, and the retention team can afford 100k offers a month, each one a month at half price. By the end you will be able to frame a different vague ask, such as fraud or feed ranking, the same way. Where labels come from, how offline metrics are computed, and how A/B tests are run each have their own sections in this course.