Clarifying Requirements

1Concept / Definition

Clarifying requirements in an architecture interview is the short, structured conversation at the start where you turn an ambiguous prompt into an agreed problem statement: who the users are, what they must be able to do, what is in and out of scope, and how success will be measured. Interview prompts are vague on purpose — the interviewer wants to see whether you can find the real problem before solving it, which is exactly what solution architects do with stakeholders.

2Why It Exists

The same is true in real engagements: most failed architectures solved a problem nobody had, or ignored the one constraint that mattered. Interviewers use the clarification phase as a proxy for how you will behave in a discovery workshop.

3Core Concepts — The Clarification Funnel

The funnel works because each level narrows the next. Once actors are known, use cases follow; once the critical path is known, scope negotiation becomes easy — anything off the critical path is a candidate for "later".

4How It Works Internally — A Clarification Script

4ADeep Dive — Finding the Hard Part

Every good prompt has one or two aspects that make it genuinely hard. Naming them early shows seniority and focuses the rest of the interview.

Ask about the hard part as a question, not a declaration: "I think seat contention during big on-sales is the hard part — is that where you'd like me to go deep?" The interviewer may redirect you, which is valuable information.

4BDeep Dive — Negotiating Scope

4CDeep Dive — Functional vs Non-Functional Clarification

Candidates often clarify only functions. Ask at least two non-functional questions (scale and one quality attribute) in the first minutes; they will change the design more than any feature.

4DDeep Dive — System Design vs Solution Architect Interviews

In a solution architect interview, ask about existing systems and business outcomes early: "Is this greenfield, or do we integrate with an existing order system?" often changes the design more than traffic numbers.

4EDeep Dive — Recovering From a Misunderstanding

4FDeep Dive — Time-Boxing

5APIs / Features / Syntax

SCOPE BOX (written top-left of the whiteboard) — QuickBite food delivery
Actors: customers · restaurants · riders · (support: out)
P0: browse → order → pay (PSP) → restaurant accepts → rider assigned → track → deliver
P1: scheduled orders, cancellations/refunds
Out: reviews, ads, rider payroll, restaurant onboarding UI
Hard part: dispatch + live tracking at lunch/dinner peaks
Success: 1M orders/day; peak 400 orders/s; 99.95% ordering; ETA ±5 min for 90%

RESTATEMENT (say it, then pause)
"To confirm: we're designing the ordering-to-delivery path for a food delivery platform
across customers, restaurants and riders, at about a million orders a day with sharp
meal-time peaks. Payments go through a provider. The part you'd like depth on is dispatch
and tracking. Reviews, ads and payroll are out. Does that match your expectations?"

CLARIFICATION CHECKLIST (mental)
[ ] actors named            [ ] critical path identified
[ ] hard part confirmed     [ ] scope box written (in/out/P0-P2)
[ ] 1–2 scale numbers       [ ] 1–2 quality targets
[ ] greenfield or existing? [ ] restated and confirmed

6Practical Examples

6.1 Strong opening — food delivery

A candidate restated the prompt, named four actors, asked whether support tools were in scope, proposed dispatch and tracking as the hard part and wrote a scope box by minute six. The interviewer later said the design felt "aimed" — every component had a reason tied to the box.

6.2 Weak opening — payment system

Another candidate began drawing an API gateway and microservices within a minute. At minute twenty the interviewer asked about marketplace payouts; the design had no ledger and no split payments. The candidate never recovered the lost time.

6.3 Solution architect case — existing systems

In a 90-minute case, a candidate asked "What exists today?" and learned that a legacy order system handled 70% of volume and could not be replaced for two years. The design shifted from greenfield to strangler — the interviewer's intended hard part.

6.4 Worked example — clarification dialogue (payment system)

Scenario. A candidate is asked to "design a payment system" with no other detail, and has about six minutes before the design discussion should begin.

What it shows. Five well-chosen questions turn a vague prompt into concrete design constraints. Learning that it is a marketplace means the ledger must handle splits between sellers and payouts. Cards and UPI, with wallets later, call for adapters per payment service provider and tokenisation. A peak of 5,000 payments per second on sale days calls for asynchronous processing, idempotency keys and partitioning. Holding funds in escrow until delivery adds ledger states and daily reconciliation. Operating in India under RBI payment aggregator rules requires data localisation and keeping card data with a PCI-compliant provider. Each answer is written on the board next to its design impact, so the interviewer can see how the questions shaped the design.

Common mistake. Asking generic questions, such as "how many users?", without explaining how each answer will change the design.

Takeaway. Ask a few questions whose answers change the design, and connect each answer to its design consequence.

6.5 Worked example — finding the hard part (URL shortener)

Scenario. A candidate is asked to design a URL shortener, a prompt that sounds simple and invites a generic answer.

What it shows. Focused clarification finds where the real difficulty lies. Checking that reads dominate writes, perhaps 100 to 1, points the design towards fast reads and caching. Asking about custom aliases affects how IDs are generated and checked for conflicts. Asking about link expiry and analytics affects storage and whether an event pipeline is needed. The candidate then names the hard parts: generating unique IDs without collisions at scale, and handling very popular "hot" links. Naming them tells the interviewer where the deep dive will go and shows judgement, rather than spending the interview on easy parts.

Common mistake. Treating a short prompt as trivial and never finding the parts that make it hard.

Takeaway. Use clarification to find and name the hard parts, then spend your depth there.

6.6 Worked example — scope negotiation (ticket booking)

Scenario. A candidate designing a ticket booking system has 45 minutes, far too little to cover every feature.

What it shows. Scope negotiation produces a clear scope box. Browsing events, the seat map, holding seats, payment and ticket issue form the P0 path, which must work. A virtual queue for very popular on-sales is P1 and is chosen as the hard part, because it prevents the system from collapsing when thousands of fans arrive at once. The organiser portal is out of scope, with events assumed to exist. A resale marketplace and dynamic pricing are out, mentioned only as future evolution. The interviewer agrees, and the remaining time goes into designing the core path and the queue properly.

Common mistake. Trying to include every feature, leaving no time to design any of them well.

Takeaway. Negotiate a scope box with clear priorities, and write it down where both sides can see it.

6.7 Worked example — interview whiteboard

Scenario. In interviews, candidates are asked: "You have 45 minutes to design a food delivery platform. How do you start?"

Why it works. The outline gives a disciplined opening. The candidate restates the prompt, names the actors, such as customers, restaurants, riders and possibly support staff, and identifies the critical path: order, accept, dispatch, deliver. They propose the hard part, rider dispatch and live tracking at peak times, and check that the interviewer wants depth there. They negotiate scope into P0, P1 and out-of-scope items, ask one or two questions about scale and quality targets or state assumptions, then restate and confirm. About six minutes are used before moving on to estimation and design.

Common mistake. Spending fifteen minutes on questions, or starting to draw services in the first minute.

Takeaway. Use a short, structured clarification routine and keep to a time budget.

6.8 Worked example — recovering

Scenario. Partway through a food delivery design, the interviewer introduces new information that changes the picture.

What it shows. Good candidates adjust openly and quickly. At minute 18, when asked about group orders, the candidate points to the scope box where they were placed as P2, then shows where a cart-sharing service would attach to create one combined order. At minute 25, when told the platform handles 10 million orders a day, ten times the assumption, the candidate updates the numbers on the board and explains the consequences: dispatch must be partitioned by city and the order store sharded. Interviewers value this ability to absorb change calmly.

Common mistake. Ignoring the new information, or restarting the whole design from the beginning.

Takeaway. When requirements change, update the scope and numbers visibly and explain what changes in the design.

6.9 Worked example — anti-patterns spotted by interviewers

Scenario. Interviewers at large technology companies use common notes to evaluate how candidates handle clarification.

What it shows. The table shows how each anti-pattern is judged. Asking twenty questions before any design suggests the candidate cannot prioritise and stalls. Asking no questions suggests they make assumptions and may design the wrong thing. Asking "what should I design?" pushes the work back to the interviewer. Making silent assumptions hides key decisions the interviewer wanted to discuss. Letting scope grow shows poor time management. Avoiding all five is often what separates a strong opening from a weak one.

Common mistake. Believing that more questions always look better.

Takeaway. Clarify efficiently: enough to shape the design, visible assumptions and controlled scope.

6.10 Worked example — solution architect variant questions

Scenario. A solution architect candidate receives a design prompt that resembles a real client engagement rather than a pure technical puzzle.

What it shows. The variant questions add business and delivery context that system design interviews often skip. Asking what business outcome the system should change aligns the design with value. Asking which existing systems must be integrated or replaced reveals whether it is greenfield or brownfield. Asking who the key stakeholders are and who decides identifies governance and trade-off owners. Regulatory and residency constraints shape deployment and data design, and team size, skills and timeline influence architecture style and build-or-buy choices.

Common mistake. Answering a solution architect prompt as if it were only a scaling exercise.

Takeaway. In solution architect interviews, clarify business outcomes, existing systems, stakeholders, regulation and delivery constraints.

6.11 Worked example — success measures

Scenario. Candidates often finish clarification without agreeing how success will be judged.

What it shows. Success measures turn goals into testable targets. For food delivery, they include orders per minute at peak, delivery time and ordering availability. For payments, success rate, zero lost or duplicate payments and settlement accuracy. For chat, message delivery latency, correct ordering and accurate online presence. For ticket booking, zero double bookings, seat hold latency and a fair queue. Writing these on the board gives the design clear targets and shows the interviewer that the candidate thinks about verification.

Common mistake. Leaving quality goals vague, such as "fast and reliable", which cannot guide or test the design.

Takeaway. Agree a few measurable success criteria before designing.

6.12 Worked example — real engagement parallel

Scenario. A candidate asks whether interview clarification has anything to do with real architecture work.

What it shows. Each interview step has a real discovery equivalent. Restating the prompt corresponds to agreeing a problem statement with the sponsor. Naming actors and use cases corresponds to stakeholder mapping and journey mapping. Finding the hard part corresponds to identifying key risks and architecturally significant requirements. The scope box corresponds to a scope statement and a MoSCoW-prioritised backlog, and success measures correspond to business KPIs and non-functional targets. The interview is the same skill compressed into minutes.

Common mistake. Treating interview technique as a trick unrelated to real work.

Takeaway. Practise clarification as a real architecture skill; interviews test it in compressed form.

7Common Problems & Mistakes

8Performance & Production Considerations

9Architecture & Design Considerations

10Interview Questions & Answers