Requirement Gathering in System Design Interviews

Picture this. You sit down for a system design interview, the interviewer smiles, and says, “Design Twitter for me.” Then they lean back and wait.

• And your brain just starts firing in every direction, right?
• Databases? Servers? The feed? Followers? Where do you even begin?
• It feels like they handed you a giant, fuzzy cloud and asked you to build it.

Here’s the thing. The very first move, before any boxes or arrows, is to figure out what you’re actually being asked to build. That move is called requirement gathering, and it’s the part that separates a calm candidate from a panicking one. Let’s learn how to do it well.

🎯 Why Start Here

It’s tempting to start drawing the moment they finish talking. Resist that. Here’s why this step comes first:

• “Design Twitter” could mean a tiny app or a global giant. Until you nail down which one, you’re just guessing.
• If you guess wrong, you might spend twenty minutes designing the wrong system. That’s the most common way people fail.
• Good engineers don’t jump to solutions. They first understand the problem, then solve it. Interviewers are watching for exactly that habit.

So requirement gathering is step one of the whole flow. If you haven’t seen the full picture yet, the The System Design Interview Process lays out every step. This lesson zooms into that crucial first one.

❓ Ask Clarifying Questions

A vague prompt like “design Twitter” is your cue to ask questions, the same way a real engineer would on day one of a project. You’re trying to turn that fuzzy cloud into something solid:

• Who uses it? Regular people posting updates? Just a small team? This tells you the audience and roughly the scale.
• What are the core features? Posting, following, a timeline, likes, search? You want the handful that matter most, not every bell and whistle.
• How big is it? A few thousand users, or hundreds of millions? The size changes almost every decision you’ll make later.

Never assume the scope on your own. Asking is a strength here, not a weakness:

• Each question shows the interviewer you think before you build.
• The answers shrink that huge cloud down to something you can actually finish in the time you have.
• And often the interviewer drops hints in their answers, so listen closely.

Here’s how that opening exchange looks as a flow. You start with the vague prompt, ask your way to clarity, and end with an agreed scope.

✅ Functional Requirements

Once you’ve asked around a bit, you sort what you learned into two buckets. The first bucket is the functional requirements. These are simply what the system must do, the features the user can see and use:

• Think of them as the verbs of your system, the actions a user can take.
• For Twitter, that’s things like “post a tweet”, “follow someone”, “see a timeline”.
• Each one maps to something concrete the user does, so they’re easy to list out loud.

A short, clear list for a trimmed-down Twitter might be:

• A user can post a short tweet.
• A user can follow other users.
• A user can see a timeline of tweets from people they follow.

That’s plenty to design around. Notice we left out direct messages, notifications, and search for now, because those aren’t core to the basic experience. You can always add them back if time allows.

⚙️ Non-Functional Requirements

The second bucket is the non-functional requirements. These aren’t features. They’re the qualities the system must have, the “how well” rather than the “what”. Let’s define the ones that come up most:

• Scale. How many users and how much traffic? A million users a day needs a very different design from a thousand.
• Latency. How fast must it respond? Latency is the wait time between a request and its answer. A timeline that takes five seconds to load feels broken.
• Availability. How often must it stay up and working? A site that goes down a lot loses users fast.
• Consistency. Does everyone need to see the exact same data at the exact same moment, or is a slight delay okay? On Twitter, it’s fine if your tweet shows up for followers a second later.

Here’s the difference between the two buckets, side by side, so it sticks.

🎯 Agree on Scope

You can’t build all of Twitter in forty-five minutes. Nobody can. So once your two buckets are filled, you narrow things down to the core:

• Pick the few features that make the system what it is, and set the rest aside.
• Say plainly what’s in and what’s out, so you and the interviewer aim at the same target.
• This isn’t cutting corners. It’s smart scoping, and it shows you understand time and priorities.

The way to lock it in is to say it out loud. Something like:

“Okay, so let’s focus on posting tweets, following users, and showing a timeline. We’ll skip search and direct messages for now. We’ll assume a large user base, and the timeline needs to load fast. Sound good?”

That one sentence does a lot. It confirms the features, names the key qualities, and gives the interviewer a chance to nudge you before you’ve drawn a thing. Agreeing on scope out loud keeps you both pointed the same way.

📋 Capturing Assumptions

Sometimes the interviewer won’t give you a clear answer. They might say “you decide” or stay quiet on purpose. That’s fine. You just make an assumption and say it out loud:

• An assumption is a reasonable guess you make to fill a gap, stated openly so it can be checked.
• Writing it down, or saying it clearly, means you and the interviewer agree on the same starting point.
• If your guess is off, they’ll correct you right there, before it costs you any time.

For example, you might say things like:

• “I’ll assume around a hundred million daily users, since it’s a big platform.”
• “I’ll assume people read their timeline far more often than they post, so this is read-heavy.”
• “I’ll assume tweets are text-only for now, and we can add images later.”

Notice each one is a guess, but a stated guess. That’s the whole point. Silent assumptions are dangerous; spoken ones are safe. They keep both of you on the same page.

🧩 A Quick Example

Let’s put it all together. The interviewer says “design Twitter”. After a couple of minutes of good questions, here’s the crisp requirements list you’d walk away with.

Functional:
  - Post a short tweet
  - Follow other users
  - See a timeline of followed users' tweets

Non-functional:
  - Scale: ~100 million daily users
  - Latency: timeline loads fast (low wait)
  - Availability: should rarely go down
  - Consistency: a small delay in seeing a tweet is okay

Out of scope (for now):
  - Search, direct messages, notifications

Assumptions:
  - Read-heavy (more viewing than posting)
  - Tweets are text-only to start

Look at what just happened. A giant fuzzy prompt became a short, sharp list you can design against. You know the features, the qualities, what to ignore, and where your guesses sit. Now you’re ready to estimate and design, and you haven’t wasted a single minute.

⚠️ Common Mistakes and Misconceptions

A few habits trip people up right at this first step. Let’s clear them out:

• “Start designing immediately.” Drawing boxes before asking questions means you might solve the wrong problem entirely. Slow down and clarify first.
• “Assume the scale.” Guessing a thousand users when they meant a billion ruins your whole design. Ask, or state your assumption out loud so it can be corrected.
• “Build every feature.” Trying to cover search, messages, notifications, and everything else means you finish nothing well. Pick the core and scope the rest out.
• “Skip the non-functional needs.” Listing only features and ignoring scale, latency, and availability leaves out half the design. The qualities matter just as much as the features.

🛠️ Practice Challenge

Time to try it yourself. Take this prompt: “Design a photo-sharing app like a simple Instagram.”

Walk through requirement gathering on paper, in order:

• Clarify. What questions would you ask? Who uses it? Can people comment, or just post and view? How many users?
• Functional. List the few core features. Maybe “upload a photo”, “follow users”, “see a feed”.
• Non-functional. Note the qualities. Is it read-heavy? How fast must the feed load? How big is the scale?
• Scope. Say plainly what’s in and what’s out. Maybe skip stories and messaging for now.
• Assumptions. State your guesses out loud, like “I’ll assume photos are stored as files and the feed is read far more than it’s written.”

Do this out loud, as if someone’s listening. The more you rehearse on small prompts, the calmer you’ll be when a big one lands in a real interview.

🧩 What You’ve Learned

You now know how to take a fuzzy prompt and turn it into a clear plan. Here’s what you’ve picked up.

• ✅ Requirement gathering comes first, before any boxes or arrows.
• ✅ Ask clarifying questions about who uses it, the core features, and how big it is. Never assume the scope.
• ✅ Functional requirements are what the system does, the features.
• ✅ Non-functional requirements are how well it does it, like scale, latency, availability, and consistency.
• ✅ Agree on scope out loud, naming what’s in and what’s out.
• ✅ State your assumptions clearly so you and the interviewer start from the same place.

🚀 What’s Next?

You’ve scoped the problem. Now you need to get a feel for how big it really is, in numbers.

• Capacity Estimation shows you the quick back-of-the-envelope math for users, reads versus writes, and storage.
• The System Design Interview Process zooms back out to the full step-by-step flow, so you see where requirement gathering fits in the whole interview.

Nail the requirements first, every time, and the rest of the design has a solid foundation to stand on.