47 - Interview Strategy & Frameworks

Previous: 46 - ML System Design Basics | Next: 00 - Roadmap Overview

---

1. The 4-Step Framework (35-45 Minutes)

Every system design interview follows this structure. Master it and you'll never feel lost.

+--------------------+------+------------------------------------------+
| Step               | Time | What to Do                               |
+--------------------+------+------------------------------------------+
| 1. Requirements    | 5min | Clarify scope, constraints, scale         |
| 2. High-Level      | 10min| Core components, API, data model          |
| 3. Deep Dive       | 15min| Detailed design of 2-3 key components     |
| 4. Wrap-Up         | 5min | Trade-offs, bottlenecks, scaling, summary  |
+--------------------+------+------------------------------------------+

---

2. Step 1: Requirements (5 Minutes)

Never skip this. Jumping into design without requirements is the #1 mistake.

Functional Requirements

Ask: "What should the system DO?"

Template questions:
  - Who are the users? (end users, internal, B2B)
  - What are the core use cases? (list 3-5)
  - What are the inputs and outputs?
  - Do we need real-time or near-real-time?
  - Any specific features the interviewer wants to focus on?

Non-Functional Requirements

Ask: "How should the system PERFORM?"

Template questions:
  - Scale: How many users? DAU? QPS?
  - Latency: What's acceptable? (<100ms, <500ms, <2s?)
  - Availability: 99.9%? 99.99%?
  - Consistency: Strong or eventual?
  - Durability: Can we lose data?

Back-of-the-Envelope Estimation

Useful numbers to memorize:

  1 day = 86,400 seconds ~ 100K seconds
  1M requests/day = ~12 QPS
  100M requests/day = ~1,200 QPS
  1B requests/day = ~12,000 QPS

  1 char = 1 byte (ASCII), 2-4 bytes (UTF-8)
  1 image (compressed) = 200KB - 1MB
  1 video minute (720p) = 10-30MB
  
  Read from memory: 100ns
  Read from SSD: 100us
  Network roundtrip (same DC): 0.5ms
  Network roundtrip (cross-region): 50-150ms

  Single server: ~10K-50K concurrent connections
  Single DB node: ~5K-10K QPS (depends heavily on query)
  Redis: ~100K ops/sec
  Kafka: ~1M messages/sec per broker

Interview Tip

Write your requirements on the whiteboard/doc. This shows structured thinking and gives you a reference during the design. Interviewers love candidates who organize their thoughts visibly.

---

3. Step 2: High-Level Design (10 Minutes)

Draw the System Diagram

Standard components to consider:

  Client -> CDN -> Load Balancer -> API Gateway
                                       |
                              +--------+--------+
                              |                 |
                         Service A          Service B
                              |                 |
                         Database A         Database B
                              |
                         Cache Layer
                              |
                         Message Queue -> Workers

Define the API

List 3-5 core API endpoints:

  POST   /api/v1/resource          -- create
  GET    /api/v1/resource/{id}     -- read
  PUT    /api/v1/resource/{id}     -- update
  DELETE /api/v1/resource/{id}     -- delete
  GET    /api/v1/resource?query=X  -- search/list

For each: method, path, key parameters, response shape

Define the Data Model

List 2-4 core entities with key fields:

  User:    user_id, name, email, created_at
  Post:    post_id, user_id, content, media_urls, created_at
  Follow:  follower_id, followee_id, created_at

Mention: which DB type (relational, NoSQL, graph) and why

---

4. Step 3: Deep Dive (15 Minutes)

This is where you differentiate yourself. Pick 2-3 areas to go deep.

How to Choose What to Deep Dive

Priority order:
  1. Whatever the interviewer hints at ("tell me more about X")
  2. The hardest/most interesting part of the system
  3. Where the scale or consistency challenges are
  4. Where trade-offs are most nuanced

Common deep dive topics:
  - Database schema and indexing strategy
  - Caching layer (what to cache, invalidation)
  - Data partitioning / sharding strategy
  - Consistency guarantees (how to prevent data loss/duplication)
  - Real-time components (WebSocket, SSE, push notifications)
  - Search/ranking algorithms
  - Rate limiting / abuse prevention
  - Failure handling and recovery

---

5. Step 4: Wrap-Up (5 Minutes)

Identify Bottlenecks

"The potential bottlenecks in this design are:
  1. Database writes under peak load (solution: sharding + write-behind cache)
  2. Hot partitions for viral content (solution: consistent hashing + replication)
  3. Cross-service latency (solution: async processing where possible)"

Discuss Trade-offs

"Key trade-offs I made:
  1. Chose eventual consistency over strong for the feed (faster reads)
  2. Chose NoSQL over relational for the activity store (write scalability)
  3. Chose push model for feed generation (lower read latency, higher write cost)"

Mention What You'd Add with More Time

"If we had more time, I'd design:
  - Monitoring and alerting (SLOs, dashboards)
  - Graceful degradation under load
  - Multi-region deployment for lower latency
  - Security: authentication, rate limiting, encryption"

---

6. Common Mistakes to Avoid

---

7. Communication Tips

Think Aloud

BAD:  *silently draws boxes for 2 minutes*

GOOD: "I'm thinking about whether to use a relational or NoSQL database here.
       The access pattern is mostly key-value lookups by user_id, and we need
       to handle 50K writes per second. I think DynamoDB would be a better
       fit than PostgreSQL because of the write scalability. The trade-off
       is we lose JOIN capability, but we can denormalize the data."

Use Diagrams

  - Draw as you explain (not after)
  - Label everything (component names, data flow arrows)
  - Use consistent notation
  - Keep it clean (messy diagrams = messy thinking)

Ask Clarifying Questions

Good clarifying questions:
  - "Should we focus on the write path or read path?"
  - "Is this a global system or single-region?"
  - "Do we need to support real-time notifications?"
  - "What's the read:write ratio?"
  - "Is there a specific part you'd like me to dive deeper into?"

---

8. Trade-off Discussion Framework

For every major decision, use this structure:

Decision: [What you're deciding]
Option A: [First option]
  Pros: ...
  Cons: ...
Option B: [Second option]
  Pros: ...
  Cons: ...
Choice: [Your pick]
Reason: [Why, given the requirements]

Common Trade-offs to Prepare

---

9. Handling Questions You've Never Seen

Step 1: Don't panic. The framework works for ANY system.

Step 2: Map the unknown problem to known patterns:
  "Design a collaborative whiteboard"
    -> Real-time sync (like chat/messaging)
    -> Conflict resolution (like Google Docs)
    -> Canvas rendering (like any rich media system)

Step 3: Apply the 4-step framework:
  1. Requirements: what can users do? how many concurrent users?
  2. High-level: client, server, database, real-time sync layer
  3. Deep dive: conflict resolution (CRDTs), real-time transport (WebSocket)
  4. Wrap-up: trade-offs, scaling

Common building blocks that recur across designs:
  - Load balancer + API gateway
  - Consistent hashing for sharding
  - Message queue for async processing
  - Cache layer (Redis) for hot data
  - CDN for static content
  - WebSocket/SSE for real-time
  - Search index (Elasticsearch) for full-text search
  - Object storage (S3) for media
  - Rate limiter for abuse prevention

---

10. The STAR Method Adapted for System Design

---

11. How Different Companies Evaluate

Interview Tip

Research the company's tech blog before the interview. Knowing that Netflix uses EVCache, Zuul, and Cassandra lets you reference their architecture naturally. Knowing that Meta uses TAO, Scribe, and Thrift shows you've done your homework.

---

12. Practice Plan: 8 Weeks

Week 1-2: Foundations
  - Review: CAP theorem, consistency models, database types
  - Practice: Design URL Shortener, Design Pastebin
  - Focus: Getting comfortable with the 4-step framework

Week 3-4: Core Designs
  - Practice: Design Twitter/Feed, Design Chat System
  - Practice: Design Rate Limiter, Design Notification System
  - Focus: Data modeling, API design, caching strategies

Week 5-6: Complex Systems
  - Practice: Design YouTube, Design Uber/Lyft
  - Practice: Design Search Engine, Design Typeahead
  - Focus: Deep dives, sharding, real-time processing

Week 7-8: Advanced + Mock Interviews
  - Practice: Design Payment System, Design Distributed Cache
  - Practice: Design Ticket Booking, Design ML Recommendation
  - Focus: Trade-off discussions, handling follow-ups
  - Do 2-3 mock interviews with peers or platforms

Cadence: 2 designs per week
  - Day 1: Attempt design (45 min timer, no references)
  - Day 2: Review solution, identify gaps
  - Day 3: Re-attempt, focusing on weak areas

---

13. Top 20 Most-Asked Design Questions (Ranked by Frequency)

---

14. Mock Interview Tips

As the Interviewee

  1. Set a 45-minute timer
  2. Spend 5 min on requirements (don't skip!)
  3. Draw before you talk (visual > verbal)
  4. Check in with interviewer every 5-10 min
  5. When stuck: "Let me think about this for a moment" (better than silence)
  6. Always discuss trade-offs for major decisions
  7. End with a summary: "To recap, the system handles X by doing Y"

As the Interviewer (For Practice Partners)

  1. Don't give answers, ask probing questions:
     - "What happens if this component fails?"
     - "How would you handle 10x the traffic?"
     - "What are the trade-offs of this choice?"
  2. Push on weak areas
  3. Give hints if completely stuck (like a real interview)
  4. Evaluate: requirements, architecture, deep dive, communication

Where to Practice

---

15. Day-of Interview Checklist

Before:
  [ ] Review your notes on 5-6 common designs
  [ ] Practice the 4-step framework one last time
  [ ] Have pen/paper ready (or whiteboard tool open)
  [ ] Research the company's tech stack and blog posts
  [ ] Get good sleep (seriously)

During:
  [ ] Listen carefully to the question
  [ ] Ask 3-5 clarifying questions before designing
  [ ] Write requirements visibly
  [ ] Draw the high-level diagram first
  [ ] Think aloud throughout
  [ ] Check in with the interviewer regularly
  [ ] Discuss trade-offs for every major decision
  [ ] Summarize at the end

After:
  [ ] Note down the question and your approach
  [ ] Identify areas where you struggled
  [ ] Review and improve for next time

---

16. Resources

Books

Courses

YouTube Channels

Blogs & References

---

Previous: 46 - ML System Design Basics | Next: 00 - Roadmap Overview