Module 11 - Interview Prep

Requirement Clarification

The most important 5-10 minutes of your interview-never skip this.

1Why Requirements Matter

Simple Analogy
"Design a parking lot" could mean a 10-spot street parking or a 10,000-spot airport garage with dynamic pricing, reservations, and EV charging. The architecture is completely different. Clarifying requirements shows you understand that context drives design.

Requirements clarification transforms vague prompts into specific, measurable constraints. It demonstrates product thinking and prevents wasted effort on wrong solutions.

2Functional Requirements

What should the system DO? Core features and user actions.

Example: "Design Twitter"
Q:Can users post tweets?→ Yes, 280 chars, with images/videos
Q:Can users follow other users?→ Yes, asymmetric follow
Q:Is there a home timeline?→ Yes, showing followed users' tweets
Q:Search functionality?→ Yes, but can be v2 feature
Q:Direct messages?→ Out of scope for this interview

Tip: List 3-5 core features. Confirm what's in scope and what's NOT. "Should I focus on feed, or include notifications too?"

3Non-Functional Requirements

HOW should the system behave? Quality attributes.

Scale

  • • How many users (DAU/MAU)?
  • • How many requests per second?
  • • Data volume?

500M DAU, 10K tweets/sec, 1PB storage

Performance

  • • Latency requirements?
  • • Acceptable response time?
  • • Real-time needs?

Feed load < 200ms, tweet appears within 5s

Availability

  • • Uptime target?
  • • Acceptable downtime?
  • • Disaster recovery?

99.99% availability, multi-region

Consistency

  • • Strong or eventual consistency?
  • • Read-after-write needed?
  • • Global ordering?

Eventual consistency OK for feed

4Questions to Always Ask

Users & Scale

•How many users? DAU? MAU?
•Geographic distribution?
•Read vs write ratio?
•Peak vs average traffic?

Features

•What are the core features?
•What's explicitly out of scope?
•MVP or full product?
•Mobile, web, or both?

Constraints

•Latency requirements?
•Consistency requirements?
•Any existing infrastructure?
•Budget or cost constraints?

Data

•What data needs to be stored?
•How long to retain data?
•Data access patterns?
•Privacy requirements?

5Real Interview Example

Interviewer: "Design a URL shortener"
You: Let me understand the scope. Is this just shortening URLs, or also analytics on clicks?
Interviewer: Good question. Let's include basic analytics: click count and maybe location.
You: What scale are we designing for? How many URLs per day, and how many redirects?
Interviewer: Let's say 100M new URLs per day, 10B redirects per day.
You: Should shortened URLs expire, or persist forever?
Interviewer: They persist forever. Good catch-that affects storage.
You: Any latency requirements for redirects?
Interviewer: Redirects should be under 100ms.

In 2 minutes, you've defined: scope (shortening + analytics), scale (100M/day, 10B redirects), data retention (forever), and SLA (100ms). Now you can design.

6Common Pitfalls

Not Asking at All

Jumping straight to architecture. Interviewer wonders if you understand the problem.

Asking Too Many Questions

Spending 15 minutes on requirements. Keep it to 5-10 min, then iterate.

Asking Obvious Questions

'Should users be able to log in?' Yes, obviously. Ask non-obvious ones.

Not Confirming Assumptions

Assuming 'high scale' means 1M users when it means 1B. Always get numbers.

7Key Takeaways

1Never skip requirements. 5-10 minutes well spent.
2Functional: What features? Non-functional: Scale, latency, availability
3Get specific numbers: users, QPS, storage, not "a lot" or "fast"
4Clarify scope boundaries: what's IN and what's OUT
5Good requirements clarification demonstrates seniority

?Quiz

1. 'Design Instagram'. Your first question should be:

2. Interviewer says 'high availability'. You should: