How to Answer Decomposition Questions

Here’s our five-step framework to answering any decomposition interview question. Notice how each step builds on the one before it.

1. Identify the stakeholder and pain points

Estimated time: 5-10 min (depends on how vague the prompt is)

Even when the stakeholder and pain points seem explicitly named in the prompt, ask investigative questions here. Prompts are often less complete than they look, and confirming your assumptions out loud is part of what the interviewer is evaluating.

Identify the main stakeholder. There may be multiple stakeholders, but a decomp question usually wants you optimizing for one. If the prompt names a stakeholder, that's your main one. If it doesn't, name the candidates you're considering, check with the interviewer, then state which one you'll focus on for the sake of scope. This shows mature product thinking.

Identify their main pain point. Put yourself in the stakeholder's shoes and think through what they're struggling with. This part is usually straightforward, and you don't need a comprehensive list. What matters more is drilling into that one main pain point, which is what the next step is for.

Find out how they solve this pain point today. Ask the interviewer what current solutions or workarounds are in place. For example, before you design an application that helps biologists document field findings, you need to know how they document findings now.

This step helps you to uncover sharper, more concrete pain points than the one you started with. For instance, you might assume the pain point is disorganized notes, but learn that biologists actually struggle to write in notebooks in muddy field conditions. The real pain point is the recording method, not the organization. That reframe changes what you design entirely.

2. Brainstorm the solution

Estimated time: 5 min

So, now that you have a good sense of the stakeholder and their main pain point, it’s time to brainstorm potential solutions to their pain point, using the resources available to you.

If your strongest option needs something the prompt didn't mention, don't assume it's off the table. Ask the interviewer whether that resource exists too.

For example, take this prompt: "A major city wants to reduce 911 emergency response times given call data, traffic data, and ambulance GPS data."

Walking through Step 1, let's say you've identified the emergency response units as the main stakeholder. Digging into their pain point, you learn that call-to-mobilization time is already fast, the real bottleneck is travel time once ambulances are en route. With that pain point in mind, two solutions come to mind:

1. A predictive model that pre-positions ambulances in high-likelihood areas before calls even come in, based on historical patterns.
2. A real-time video system that pulls live feeds from traffic intersections to reroute ambulances around accidents or congestion as they respond.

The prompt confirms you have enough data for solution 1, call, traffic, and GPS data all support it. Solution 2 is the one you actually prefer, but it depends on live video feeds, which the prompt never mentioned. Rather than dropping it outright, you ask: "My instinct is that live video feeds would strengthen this solution. Do we have access to something like that?" If the answer is no, you drop it and move forward with the predictive model. If the answer is yes, you've just expanded your resource set through a smart clarifying question and landed on a stronger solution.

3. Scope the MVP

Estimated time: 5 min

Once you've landed on a solution, this step is about figuring out what's realistically shippable in the given time frame. This is where your technical judgment matters most, scoping a shippable MVP means knowing what can actually get built in that window.

With AI, raw build time matters less than it used to for a lot of solutions, writing the core logic or a simple interface is often fast. But that shifts the real bottleneck elsewhere, and that's what you should be scoping for:

• Coordination time: how many teams or stakeholders do you need to loop in before you can move?
• Integration time: does the data source you need have a well-documented API you can query directly, or do you need to liaise with another team to get access or build a connector?
• Rollout time: if the solution needs to run on offline devices, how do you get it onto those devices in the field?

Narrate as you consider these factors because interviewers are assessing you on it e.g., "Coordination is minimal since this data already sits with a team we work with regularly. Integration is the bigger cost, the API isn't documented, so we'd need to build a connector ourselves. That alone probably eats most of the week."

Reasoning silently and presenting only the final scope gives the interviewer far less to evaluate.

Whatever gets cut from MVP 1.0 because of these constraints becomes the seed for MVP 2.0 and beyond, and it's often conditional on something specific happening first.

4. Design the high-level system

Estimated time: 5 min

In the process of scoping, you'll have implicitly worked out the functional and non-functional requirements of the MVP you're designing. Make these explicit: write them down and say them out loud to your interviewer so you're both working from the same page.

• Functional requirements are what the system must do.
• Non-functional requirements are how the system should perform, for example scalability, latency, or security.

If you scoped properly in the last step, you should land on at most one to two functional requirements and one to two non-functional requirements. Any more than that is a signal to revisit your scoping and cut further, a design with five requirements isn't an MVP anymore.

Once your requirements are locked in, gauge your own uncertainty about scale. The prompt often gives you a rough prior, "mid-sized city" or "internal tool for one team" implies an order of magnitude without any math. If that prior clearly rules out the expensive choices (you're not building a real-time streaming system), say so and move on. If you're genuinely unsure, that's when a quick back-of-envelope number earns its place, it's the fastest way to resolve the uncertainty before you commit to a design.

With requirements and estimates in hand, create a high-level design diagram that highlights the pieces most critical to satisfying those requirements. This isn't the place to design every service in detail, your interviewer wants to see that you understand how the overall system works end to end.

As you walk through it, narrate how each component you chose satisfies a specific requirement.

5a. Go deep on specific area

Estimated time: 15 min

The interviewer will want to deep dive into one aspect of the high-level design you proposed. The good news is that you, as the candidate, can greatly influence which aspect that is. Your decision comes down to three factors, in order of priority:

1. Does the role have a stated specialization? If the job description names this as an AI role, or you're interviewing at an AI-focused company or team, that's your deep dive. This is the strongest signal available, when it's present, it overrides the other two factors.
2. If the role is ambiguous, which part of the design is most important or complex? There will usually be a few options here, which is exactly why the third factor matters.
3. Where does your own expertise lie? If you're strong in ML, dive into model training and output (variables, model choice, training data quality, evaluation metrics). If you're strong in application development, dive into performance and reliability, caching, cron scheduling, and similar concerns.

Once you've decided, say so directly: "The [aspect] is an important part of this solution because it [reason]. I'll expand on that now. Is that okay with you?"

If your reasoning above was sound, the interviewer will usually let you proceed. But they may redirect you mid-deep dive if they've already gotten enough signal from your first area and want to gauge a different one. Follow their lead if this happens.

5b. Present back to “customer”

Estimated time: 10 min

Some companies replace the deep dive with a role play. Instead of going deep on one technical area, you present your solution back to the interviewer as if they were the customer.

Instead of testing how far your technical “spike” goes, this step checks whether you can take everything from the previous parts and make it land for a non-technical stakeholder.

Cover three things, in this order:

1. The solution, in the customer's terms. Lead with what they can now do that they couldn't before, not the architecture. Drop the jargon. If you'd say "vector store" to an engineer, say "a way to search past cases by meaning, not just keywords" to the customer.
2. The key trade-offs you considered. Name the one or two decisions that most shaped the solution and why you chose the path you did. This shows judgment and pre-empts the "why not X" question.
3. Next steps. What ships first, what comes after, and what you'd need from them to get there.

Keep it concise. You shouldn’t be parroting back everything you’ve done in the previous parts.

Handling follow-up questions

Here are the most common follow-up questions in a decomp interview and how to handle them.

Plan the next MVPs

Estimated time: 5 min

“What’s the next thing you’ll ship?”, “How long will it take to build out the full solution?”

There's no need to go into detail here. Interviewers simply want to see whether you can prioritize based on impact and on blockers.

First, compile your list. You should already have a list of pending changes and their blockers from Step 3 (scope the MVP). While going deep on your chosen area in Step 5, you'll likely also surface improvements worth making but too large to fit into MVP 1.0.

Then prioritize your list. Rank first by blocking requirements, you can't sequence a high-impact feature first if it depends on a lower-impact feature shipping beforehand. Then, within what's unblocked, rank by impact.

Let’s change a requirement

Estimated time: 5 min

“Another stakeholder wants to use this feature you are building out. Do we need to make any changes?”

Revisit your functional and non-functional requirements in step 4 (design the high-level system). The interviewer is testing whether you can trace a requirement change through to a concrete design change.

The change usually means swapping out or adding one to two components in your high-level design.