Requirements and estimates in an interview

Requirements and estimates take the first eight minutes of a 45-minute design interview. Their job is to decide the shape of the design. A question whose answer doesn't change a box is wasted time.

Functional and non-functional requirements

Aim for three to five functional requirements, written as user-visible capabilities. "Users can create a short link." "Users see a home timeline of posts from people they follow." More than five and you won't finish. Pick the core ones, and say aloud which you are leaving out: "I'll skip editing posts and DMs unless you want them."

Non-functional requirements are where designs differ, so give them numbers. "Low latency" is not a requirement. "The feed loads in under 200 ms at p99" is.

Questions that change the design

Ask questions whose answers change your boxes.

Skip questions such as "what language is the backend in?" or "should I use AWS?". They rarely change the design.

If the interviewer says "you decide", decide quickly and state it: "I'll assume 100 million daily users, a 100:1 read-to-write ratio, and that a new post can take up to five seconds to reach followers' feeds." Stated assumptions are fine. Hidden ones are not.

Estimates that justify components

Compute the few numbers that matter, and say what each one implies. Here is a photo-sharing app with 100 million daily users, where each user views 50 photos and uploads 0.1 photos a day:

Reads:    100M × 50 / 86,400 s     ≈ 58,000 photo views/s  (peak ×3 ≈ 175,000/s)
Writes:   100M × 0.1 / 86,400 s    ≈ 116 uploads/s          (peak ≈ 350/s)
Storage:  10M uploads/day × 2 MB   = 20 TB/day ≈ 7.3 PB/year
Egress:   58,000/s × 200 KB (a resized view) ≈ 11.6 GB/s

Each line earns a decision. 175,000 reads a second means the read path needs a cache and a CDN, because one database can't serve that. Seven petabytes a year means object storage with lifecycle tiering. Uploads at 350 a second are trivial, so the write path can stay simple. Round aggressively. Nobody cares whether it is 58,000 or 50,000. For the method, see the estimation chain.

Common mistakes

• Asking trivia. Questions about tooling or language don't change the boxes.
• Hidden assumptions. State each one, so the interviewer can correct it.
• Computing numbers you never use. Every number should lead to a decision.

Check yourself

1. The interviewer says "you decide the scale." What do you do? Pick a number, say it aloud, and name the decision that depends on it.

2. Peak uploads are about 350 a second. What does that imply? Uploads are a small write load, so the write path can stay simple. The design effort goes to the read path and egress.

Key takeaways

• Keep requirements to three to five functional items, and give non-functional ones numbers.
• Ask only questions that change the design, and state every assumption.
• Compute the few numbers that justify a component, and say what each one implies.

Further learning

Hello Interview's preparation guide shows how to frame these first minutes. Another short walk through the four-step framework is also useful before an interview.

Next, define the interface and the data in APIs and data models.