Clarifying requirements and scope
In one line
Spend the first five minutes turning a one-line prompt into a short, agreed list of features, numbers and qualities, because every later decision depends on it.
What it is
Interview prompts are vague on purpose: 'Design WhatsApp' or 'Design a food delivery app'. Clarifying requirements means asking targeted questions, then writing down what you will build (functional requirements), how well it must work (non-functional requirements: scale, latency, availability, consistency, durability) and what you will not build (out of scope).
The goal is not to collect every detail. It is to find the two or three requirements that shape the architecture. 'Messages must be delivered in order within a chat' and '1-on-1 only, no groups larger than 256' change the design far more than 'users have profile pictures'.
A good requirements step ends with a short written list on the whiteboard that you and the interviewer agree on. You will point back to it when you justify choices later.
Why interviewers ask
Interviewers watch this step to see if you behave like an engineer who builds the right thing, or one who starts coding before understanding the problem. Jumping straight to boxes is one of the most common reasons for a 'no hire'. It also protects you: with an agreed scope, you avoid spending 20 minutes on a feature the interviewer did not care about.
How it works
- 1Restate the problem in one sentence to confirm you understood it: 'So we are building the back end for 1-on-1 and small-group chat on mobile.'
- 2List core user actions (functional requirements) and ask which 3 to 5 matter most. Group them: write path (send, upload, post) and read path (view, search, feed).
- 3Ask about users and scale: daily active users, peak vs average (festive sale, IPL final, 10 AM Tatkal), read to write ratio, data size per item, growth over 3 to 5 years.
- 4Ask about quality needs per feature, not globally: which data must never be lost, where stale reads are fine, latency targets (p99), availability target (99.9% vs 99.99%).
- 5Ask about consistency where money, inventory or uniqueness is involved: can two users book the same seat? Can a balance go negative? These usually become the deep dive.
- 6Ask about clients and constraints: mobile on poor networks, web, third-party API, regions, regulation such as RBI data localisation for payment data.
- 7Agree on out of scope explicitly: auth, analytics dashboards, admin tools, ML ranking. Say 'I will assume these exist as services we can call.'
- 8Write the final list on the board in three groups (functional, non-functional with numbers, out of scope) and get a nod before moving on.
Worked example · Clarifying 'Design a movie ticket booking system (like BookMyShow)'
- Restate: users browse movies and shows in a city, pick seats and pay. Interviewer agrees.
- Functional: search shows by city and movie, view seat map, hold seats for a few minutes, pay, get a ticket. Out of scope: reviews, food add-ons, recommendations.
- Scale question: about 5M bookings a day normally, but a big release opening can bring 1M users to the same few hundred shows within minutes.
- Key consistency question: 'Two users must never get the same seat, right?' Interviewer: yes. This becomes the main deep dive (seat holds with expiry and a unique constraint per show and seat).
- Latency: seat map in under 300 ms; payment can take up to 10 seconds because it waits for the payment gateway.
- Availability: browsing should stay up even if booking is degraded, so the read path and booking path can be separated.
- Written summary: 4 functional items, 4 non-functional items with numbers, 3 out-of-scope items. Took 5 minutes.
Picture it
It is like a tailor taking measurements. A tailor who starts cutting cloth without measuring may sew a beautiful shirt that does not fit. Five minutes with the measuring tape saves the whole job.
Key patterns
Ask questions that change the design
When: Choosing what to ask
How: Before each question, ask yourself 'would a different answer change my architecture?' If not, assume and move on. Peak traffic, consistency for money or inventory, and data size almost always matter.
Propose, do not just ask
When: The interviewer says 'you decide'
How: State a reasonable assumption with a number: 'I will assume 50M DAU and that feeds can be 10 seconds stale.' It shows judgement and keeps time moving.
Non-functional per feature
When: Discussing consistency and availability
How: Split the system into paths: 'Booking needs strong consistency; browsing can be eventually consistent and cached.' This sets up a design with separate read and write paths.
Real-world use
IRCTC Tatkal booking
Tatkal booking opens at 10 AM for AC classes and 11 AM for non-AC. Traffic for those minutes is many times the daily average, so 'what is the peak, and when' is the requirement that drives the whole design.
UPI payments
A payment flow has very different needs per step: the balance debit needs strong consistency and must never be lost, while the transaction history screen can be slightly stale. Asking per feature avoids making everything strongly consistent.
Design documents at large companies
Engineering design docs at companies like Google and Uber usually start with goals and non-goals sections. Interview requirements are a spoken version of the same habit.
In a project
Your product manager asks for 'a feature to show live order status to customers' in a food delivery app. The team is about to build it with WebSockets for every screen.
- Ask which statuses matter: order accepted, preparing, picked up, courier location. Courier location is the only high-frequency one.
- Ask about scale: 2M orders a day, peak 1,500 active orders per second created at dinner time, average order active for 40 minutes.
- Ask about freshness: status changes are fine within 5 seconds; courier location every 5 to 10 seconds is enough.
- Ask about clients: Android users on 4G with frequent drops in Tier-2 cities, so the design must reconnect and catch up.
- Agree out of scope: chat with courier, live ETA recalculation by ML.
- Conclude that push notifications plus polling every 10 seconds covers status, and a WebSocket is needed only on the tracking screen.
Impact: The team builds a smaller system: long-lived connections only for users on the tracking screen, which is a fraction of all users, cutting connection servers and on-call load while meeting the real freshness need.
Trade-offs
Use it when
- Every design interview, including when the prompt looks familiar
- When the interviewer gives numbers: still confirm peak, ratio and growth
- Real projects, before writing a design doc
Avoid it when
- Asking more than 8 to 10 minutes of questions; the interviewer wants to see a design
- Asking about details that do not affect architecture, such as button colours or exact profile fields
- Asking open questions with no proposal when the interviewer has already said 'you decide'
Common mistakes
- Starting to draw before asking anything.
- Asking only about features and never about scale, latency or consistency.
- Treating all data the same: making the whole system strongly consistent or the whole system eventually consistent.
- Forgetting peak traffic; designing for the average fails on the IPL final or the sale launch.
- Not writing the agreed list down, then drifting into out-of-scope features later.
- Long interrogation with no assumptions, which wastes time and shows no judgement.
Interview questions
Quick revision
- Restate the problem in one sentence.
- Functional: 3 to 5 core actions, split into write and read paths.
- Non-functional with numbers: DAU, peak QPS, p99 latency, availability, durability, consistency.
- Ask non-functional needs per feature, not for the whole system.
- Always ask about peak events and money, inventory or uniqueness rules.
- Clients and constraints: mobile networks, regions, data localisation.
- Out of scope: say it and write it.
- Ask only questions that change the design; otherwise assume.
- Budget about 5 minutes; get agreement before moving on.
Check yourself
1. Which question is most likely to change the architecture of a ticket booking system?
2. Which of these is a non-functional requirement?
3. The interviewer says 'you decide the scale'. What is the best response?
4. For a food delivery app, which data can usually be eventually consistent?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.