Clarifying a Vague Prompt
Turn a one-line prompt into a scoped problem with three to five sharp questions and explicit out-of-scope.
Turn a one-line prompt into a scoped problem
"Design Twitter." Four seconds in, and you already have everything you need to lose the round: a prompt so broad that any two engineers would build two different systems. The strongest candidates do not start drawing. They start scoping: turning a vague ask into a small, agreed problem they can actually finish in the time on the clock.
Scoping has three moves, and it should take three to five sharp questions, not fifteen.
1. Separate the product ask from the system ask
"Twitter" is a product with search, ads, direct messages, trends, and a home timeline. You are not designing all of it. Confirm the one slice the interviewer cares about ("Let us focus on posting a tweet and loading a home timeline, and treat search and ads as out of scope") and get a nod before you go further. Naming what you are not building is how you protect your time budget.
2. Pin down actors, scale, and the read/write mix
Three facts change the architecture more than anything else you will ask:
- Actors and use cases: who uses this, and what are the two or three things they do?
- Scale: roughly how many daily active users? This sets whether you need one database or a sharded fleet.
- Read/write ratio: a feed is read-heavy (you load far more than you post), which pushes you toward caching and fan-out on write. A logging system is the opposite.
You are not gathering trivia. Each answer eliminates whole branches of the design tree.
You get three to five questions for 'Design Twitter'. Sort these candidates: which answers eliminate whole branches of the design tree, and which just burn the clock?
3. Restate, then commit
Play the interviewer back their own problem in one sentence ("So: a home-timeline service for tens of millions of daily users, read-heavy, eventual consistency is fine for the feed"). If they agree, you have a shared contract and you move. If they correct you, you just avoided designing the wrong system.
The mindset that makes this work
Treat the interviewer as a collaborator, not an oracle. You are allowed to propose an assumption ("I will assume 100 million DAU and a 100:1 read/write ratio, is that reasonable?") instead of asking an open question and waiting. Proposing assumptions is faster, and it signals seniority.
The two failure modes to avoid: interrogating the interviewer with a dozen questions until the clock is gone, and jumping to boxes and arrows before anyone has agreed on what the system is. Three to five questions, a restated scope, then draw.
Apply
Your turn
The task this lesson builds to.
Write the 3 to 5 clarifying questions you would ask for the bare prompt 'Design Twitter', and for each one show how a likely answer narrows the design.
Think about
- Which product slice is actually in scope, and what will you explicitly defer?
- What do you need to know about actors, scale, and read/write mix before drawing anything?
- How do you avoid analysis paralysis and move within three to five questions?
Practice
Make it stick
A second problem on the same idea, so it survives past today.
The interviewer answers 'Assume a global user base and design for whatever scale you think is right.' Write how you would scope 'Design a ride-sharing dispatch service' under that vague answer: state the assumptions you would commit to, the one slice you would build, and the two things you would defer, all in under a minute of talking.
Think about
- When the interviewer refuses to constrain scope, how do you constrain it yourself without stalling?
- Which single assumption (scale, consistency, geography) most changes this design, and what value do you commit to?
- How do you name the deferred pieces so the interviewer can pull one back in if they want it?