How to Answer Decomposition Questions

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

1. Clarify the constraints

Estimated time: 1-2 min (depends on how vague the prompt is)

For every decomposition prompt, begin by identifying three key constraints: the stakeholder, the available resources, and the timeline. For more on why these constraints matter, see the “What Are Decomposition Questions?” lesson.

Consider the following prompt:

“A major city wants to reduce 911 emergency response times given call data, traffic data, and ambulance GPS data.”

After reviewing the prompt and clarifying any missing details with the interviewer, you might define the constraints as follows:

• Stakeholder: Emergency response units (inferred from the prompt and confirmed with the interviewer)
• Available resources: Call data, traffic data, and ambulance GPS data (provided in the prompt)
• Timeline: One week (clarified with the interviewer)

2. Understand the stakeholder

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

Once you’ve identified the stakeholder, work with the interviewer to understand the problem in greater detail:

Identify the stakeholder’s primary pain point. Put yourself in the stakeholder’s position and consider what they are struggling with. You do not need to produce a comprehensive list of pain points. Instead, identify the most important one and investigate it thoroughly.

Understand how they address the pain point today. Ask the interviewer about the stakeholder’s current process, existing solutions, and workarounds. For the 911 example, you might ask: “What are emergency response units already doing to reduce response times, and where do delays occur in the current process?”

The answer may reveal that the time between receiving a call and mobilizing an ambulance is already short. The real bottleneck is travel time after the ambulance is dispatched, particularly when traffic is heavy. This reframes the broad pain point “Emergency response times are too slow” as a more specific one: “Emergency response units need to reduce ambulance travel time after dispatch.”

A sharper problem definition gives you a clearer target for the solution you design.

3. 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.

For example, in the 911 prompt, 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.

4. 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.

5. 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.

6a. 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.

6b. 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.