An ML system design interview often starts with a broad, almost casual request: "Design a video recommendation engine," or "How would you build a system to detect fraudulent transactions?" The biggest mistake is to immediately jump into discussing models or infrastructure. The first and most critical step is problem formulation. This is where you translate a fuzzy business need into a precise, solvable machine learning problem.

Your goal is to methodically clarify the requirements. Think of yourself as a consultant, not just a candidate. You need to ask questions to narrow the scope and define what success actually looks like. The interviewer wants to see if you can connect business objectives to technical specifications before a single line of code is imagined.

Let's use an example: designing a system to recommend products on an e-commerce site. The business goal might be to increase sales. This immediately helps frame the ML task. We're not just showing users random products; we're trying to predict which products they are most likely to buy. This translates the business objective (more sales) into a potential ML task: predicting purchase probability. It could be framed as a classification problem (will the user buy this item?) or a ranking problem (which items, out of thousands, should be shown first?).

Once you have a business goal and a potential ML task, you need to define how to measure success. This requires two kinds of metrics: offline and online.

Offline metrics are used during model development, before the system is live. They are calculated on a static dataset. For our e-commerce example, if we frame it as a classification problem, we might use metrics like Precision, Recall, or F1-score to evaluate how well our model identifies products a user will purchase. If it's a ranking problem, we might use something like Mean Average Precision (MAP) or Normalized Discounted Cumulative Gain (nDCG).

Online metrics, on the other hand, measure the system's performance in the real world with actual users. These are directly tied to the business objective. For our e-commerce site, key online metrics would be click-through rate (CTR), conversion rate (the percentage of users who buy a recommended item), and average revenue per user. These metrics tell you if your technically sound model is actually delivering business value. A model with a great offline F1-score might not improve online CTR if its recommendations aren't compelling to users.

A perfect model is useless if it's too slow or expensive. The final part of problem formulation is defining the system's constraints. This is about establishing a Service Level Agreement (SLA) for your system.

These constraints have massive implications for your design. A strict latency budget of under 50ms might rule out complex, multi-stage models in favor of a simpler, faster one. A system needing to serve millions of users will require a different architecture than one serving a few thousand. For example, recommendations could be pre-computed in a batch process overnight if latency isn't critical, or they might need to be generated in real-time if they must react to a user's immediate actions.

By the end of the problem formulation phase, you should have a clear, one-page summary in your mind (or on the whiteboard) that details the business goal, the ML task, the online and offline metrics, and the key constraints. Only then are you ready to start discussing the 'how'.

With these foundational steps, you've turned an ambiguous request into a well-defined engineering problem, demonstrating the strategic thinking that separates senior-level talent from the rest.