Functional Requirements
The first five minutes of a system design interview decide the next thirty-five. Functional requirements are where you take control of the problem instead of letting it sprawl.
What you’re actually doing
You are converting a vague prompt (“design Twitter”) into a short, agreed list of capabilities:
- Users can post tweets (text, ≤280 chars)
- Users can follow other users
- Users see a home timeline of accounts they follow
Three to five requirements. Not ten. Every requirement you accept is something you must design for later — so accepting fewer, deliberately, is a senior signal, not a cop-out.
The script
“Before I design anything, let me scope the functional requirements. I’ll propose a core set, and you tell me if I’m missing something you care about.”
Then propose, confirm, and write them down where both of you can see them. Numbered. You’ll refer back to these numbers for the rest of the interview.
What to explicitly cut
Say what you’re not building, out loud: “I’ll treat search, ads, and DMs as out of scope unless you want one of them.” Interviewers often have a hidden requirement they want you to find — asking directly is allowed and looks confident.
Common failure modes
- Designing while scoping. Don’t mention Kafka yet. Requirements are about what, never how.
- Accepting everything. If the interviewer keeps adding features, negotiate: “Happy to cover that in deep dives if we have time.”
- Skipping the write-down. Unwritten requirements get silently dropped, and dropped requirements get noticed in feedback.
Practice: take three products you use daily and write exactly four functional requirements for each, in under three minutes per product. Speed at this step buys you time everywhere else.