How to Prepare for a System Design Interview in 2 Weeks

Your system design interview is in 14 days. Panic is setting in. You've spent years writing code, but designing systems at scale? That's a different skill entirely.

Here's the truth: two weeks is enough time to pass a system design interview, if you focus on what actually matters.

I've seen engineers with 10 years of experience fail system design interviews. I've also seen engineers with 2 years of experience crush them. The difference isn't raw intelligence or years of experience. It's targeted preparation.

This guide gives you exactly that: a day-by-day plan to maximize your chances in 14 days.

---

Before We Start: What Interviewers Actually Evaluate

Understanding the rubric changes how you prepare. Here's what you're being scored on:

Notice: memorizing solutions isn't on the list. Interviewers can tell when you're reciting. Instead, they want to see you think through problems.

---

The 2-Week Plan Overview

Let's break it down day by day.

---

Week 1: Building Your Foundation

Day 1: The Building Blocks

Before you can design systems, you need to understand the components. Today is about building vocabulary.

Study these core concepts (3-4 hours):

1. Load Balancers , How do requests get distributed across servers?

   • Round-robin, least connections, IP hash
   • Layer 4 vs. Layer 7 load balancing
   • Health checks and failover

2. Caching , Why is caching everywhere?

   • Cache-aside, write-through, write-behind patterns
   • Redis vs. Memcached (when to use which)
   • Cache invalidation strategies (TTL, event-driven)

3. Databases , SQL vs. NoSQL isn't the full picture

   • When to use PostgreSQL, MySQL, MongoDB, Cassandra, DynamoDB
   • Indexing and query optimization basics
   • ACID vs. BASE properties

4. Message Queues , Async processing fundamentals

   • Kafka vs. RabbitMQ vs. SQS
   • Pub/sub vs. point-to-point
   • At-least-once vs. exactly-once delivery

Action item: Create a one-page cheat sheet with these concepts. You'll reference it all week.

---

Day 2: Scaling Fundamentals

Today you learn how systems handle growth. This is the language of system design interviews.

Study these concepts (3-4 hours):

1. Horizontal vs. Vertical Scaling

   • Why horizontal scaling wins at scale
   • Stateless vs. stateful services
   • Session management in distributed systems

2. Database Scaling

   • Read replicas for read-heavy workloads
   • Sharding strategies (hash-based, range-based, geographic)
   • Consistent hashing (why it matters)

3. CAP Theorem , The fundamental trade-off

   • Consistency, Availability, Partition tolerance
   • CP systems (banking) vs. AP systems (social media)
   • Real-world examples of each

4. CDNs and Edge Computing

   • How CDNs reduce latency
   • Push vs. pull CDN models
   • When to use edge computing

Action item: For each concept, write down one real-world example. "Consistent hashing is used by DynamoDB for distributing data across nodes."

---

Day 3: Your First System Design , URL Shortener

Time to apply what you learned. The URL shortener is the perfect starter problem.

Work through this problem (2-3 hours):

Requirements to clarify:

• How many URLs shortened per day? (100M)
• How many reads per shortened URL? (100:1 read:write ratio)
• How long should URLs be valid? (forever by default)
• Do we need analytics?

High-level design:

User → Load Balancer → API Servers → Database
                           ↓
                        Cache (Redis)

Key decisions:

• Generating short URLs: Base62 encoding of auto-increment ID vs. hashing
• Database choice: Key-value store (DynamoDB) or relational (PostgreSQL)
• Handling collisions: Check before insert vs. unique constraints
• Caching strategy: Cache-aside with TTL (most URLs are read multiple times)

Practice explaining out loud. Pretend you're in an interview. This builds communication skills.

---

Day 4: Design Twitter , The Fan-Out Problem

Twitter introduces the concept of fan-out, which appears in many interview questions.

Work through this problem (3-4 hours):

The core challenge: When someone with 10M followers tweets, how does it appear in 10M timelines?

Three approaches:

1. Fan-out on write (push model)

   • Pre-compute and store tweet in every follower's timeline
   • Fast reads, slow writes
   • Works for average users

2. Fan-out on read (pull model)

   • Compute timeline on demand
   • Slow reads, fast writes
   • Works for celebrity accounts

3. Hybrid approach (what Twitter actually does)

   • Push for users with < 1000 followers
   • Pull for celebrities
   • Best of both worlds

Components to discuss:

• Tweet service, Timeline service, User service
• Redis for timeline caching
• Message queue for async fan-out
• Read replicas for hot data

Action item: Draw the system on paper. Practice explaining the fan-out trade-offs.

---

Day 5: Design WhatsApp , Real-Time Systems

Messaging systems test your understanding of real-time communication and delivery guarantees.

Work through this problem (3-4 hours):

Key challenges:

• Maintaining WebSocket connections at scale
• Guaranteeing message delivery (what if user is offline?)
• Message ordering (what if network reorders packets?)
• End-to-end encryption

High-level design:

Client ←→ WebSocket Gateway ←→ Message Service ←→ Database
                                    ↓
                               Message Queue
                                    ↓
                             Notification Service

Key decisions:

• Connection management: One WebSocket per user, with heartbeats
• Offline messages: Store in queue, deliver on reconnect
• Ordering: Logical timestamps (Lamport clocks) or server-assigned sequence numbers
• Delivery receipts: Sent, delivered, read states

Practice question: "How do you handle the case where a user has 5 devices?"

---

Day 6: Design a Rate Limiter , Infrastructure Systems

Rate limiters are a building block that shows up everywhere.

Work through this problem (2-3 hours):

Algorithms to know:

1. Token Bucket , Steady rate with bursts

   • Bucket holds tokens, requests consume tokens
   • Tokens regenerate at fixed rate
   • Good for API rate limiting

2. Sliding Window , Accurate but memory-intensive

   • Track each request timestamp
   • Count requests in rolling window
   • Good for strict rate enforcement

3. Fixed Window Counter , Simple but has edge cases

   • Count requests per time window
   • Resets at window boundary
   • Can allow 2x burst at window edge

Distributed rate limiting:

• Centralized (Redis) vs. local (in-memory) vs. hybrid
• Handling race conditions with Lua scripts or Redis INCR
• Synchronization across multiple servers

Action item: Implement token bucket in pseudocode. Understand it deeply enough to write it.

---

Day 7: Review and Rest

Morning (2 hours): Review your notes from the week. Can you explain each system without looking?

Afternoon: Rest. Your brain consolidates learning during downtime.

Evening (optional): Watch one system design YouTube video to hear how others explain these problems.

---

Week 2: Practice and Performance

Day 8: Design YouTube/Netflix , Media at Scale

This problem tests your understanding of video processing and CDN architecture.

Work through this problem (3-4 hours):

Upload pipeline:

Upload → Chunking → Transcoding → Storage → CDN Distribution

Key components:

• Transcoding: Convert to multiple resolutions (1080p, 720p, 480p) and codecs
• Adaptive bitrate streaming: Client switches quality based on bandwidth
• CDN architecture: Edge servers cache popular content near users
• Storage tiers: Hot (SSD), warm (HDD), cold (S3 Glacier) for different access patterns

Numbers to know:

• YouTube: 500 hours of video uploaded per minute
• Netflix: 15% of global internet bandwidth
• Video transcoding: 1 hour video → 12+ output files

Practice question: "How would you handle a video that goes viral and gets 10M views in an hour?"

---

Day 9: Design Uber , Location-Based Systems

Uber introduces geospatial indexing and real-time matching.

Work through this problem (3-4 hours):

Core challenges:

• Storing and querying driver locations efficiently
• Matching riders to nearby drivers
• Real-time location updates (every 3-4 seconds per driver)
• ETA calculation with traffic data

Geospatial indexing options:

1. Geohash , String-based, easy to range query
2. QuadTree , Adaptive density, good for uneven distribution
3. S2 Geometry , Google's approach, spherical geometry

System components:

• Location service (writes driver locations)
• Matching service (finds optimal driver-rider pairs)
• Trip service (manages active rides)
• Pricing service (surge pricing calculation)

Practice question: "How do you handle the case where there are 10,000 drivers in Manhattan but only 10 in rural Montana?"

---

Day 10: Mock Interview #1

Time to simulate real interview conditions.

Setup:

• Set a 45-minute timer
• Pick a problem you haven't practiced: "Design Dropbox" or "Design Typeahead"
• Talk out loud as if explaining to an interviewer
• Record yourself (audio is fine)

Structure your 45 minutes:

• 5 min: Requirements clarification
• 10 min: High-level design
• 20 min: Deep dive on 2-3 components
• 10 min: Scaling, trade-offs, future improvements

After the mock:

• Listen to your recording
• Did you ramble? Were you clear?
• Did you explain trade-offs or just state decisions?
• Where did you get stuck?

---

Day 11: Design a Distributed Cache

This problem goes deep on consistency and distributed systems.

Work through this problem (3-4 hours):

Key decisions:

1. Data distribution: Consistent hashing with virtual nodes
2. Replication: How many replicas? Sync vs. async?
3. Consistency: Strong (all replicas agree) vs. eventual
4. Eviction: LRU, LFU, or TTL-based

Handling failures:

• Node failure: Replicas take over, re-balance data
• Network partition: What happens? (CAP theorem applies)
• Hot keys: Replicate more, or use local caching

Cache patterns:

• Cache-aside (application manages cache)
• Read-through/write-through (cache manages persistence)
• Write-behind (async writes to database)

Practice question: "How do you prevent thundering herd when a popular cache key expires?"

---

Day 12: Mock Interview #2

Pick a harder problem this time:

Options:

• "Design Google Docs" (real-time collaboration)
• "Design a Notification System" (multi-channel delivery)
• "Design an E-commerce Platform" (inventory and transactions)

Focus on:

• Speaking more fluidly
• Drawing clearer diagrams
• Explaining trade-offs proactively ("I chose X over Y because...")
• Asking clarifying questions before diving in

---

Day 13: Weak Spot Day

Identify your gaps and fill them.

Review your mock interview recordings. Where did you struggle?

Common weak spots and fixes:

Capacity numbers to memorize:

• QPS: 1M daily users ≈ 12 QPS (assuming even distribution)
• Storage: 1M users × 1KB = 1GB
• Network: 1 Gbps = ~100MB/s = ~100K requests/sec at 1KB each

---

Day 14: Final Prep

Morning (1 hour): Light review of your notes. Don't cram.

Afternoon: Rest and do something relaxing.

Evening: Prepare logistics:

• Test your video/audio if remote
• Have paper and pen ready for diagramming
• Get a good night's sleep

Mental preparation:

• Remember: interviewers want you to succeed
• It's a conversation, not an interrogation
• If you get stuck, say "Let me think about this..." (silence is okay)
• Ask for hints if needed, it's better than floundering

---

Quick Reference: Interview Day Checklist

First 5 Minutes , Requirements

• Clarify scale (users, QPS, data size)
• Clarify features (what's in scope, what's out)
• Clarify constraints (latency, availability, consistency)
• State your assumptions explicitly

Next 10 Minutes , High-Level Design

• Draw major components (boxes and arrows)
• Show the request flow (how does data move?)
• Identify data stores and their purpose
• Check in: "Does this high-level design make sense before I go deeper?"

Next 20 Minutes , Deep Dive

• Pick 2-3 components to explore
• Discuss data models and schemas
• Explain algorithms and data structures
• Address scaling challenges

Final 10 Minutes , Trade-offs and Wrap-up

• Discuss alternative approaches you considered
• Identify potential bottlenecks
• Suggest future improvements
• Ask if they want you to go deeper anywhere

---

What If I Have Less Than 2 Weeks?

1 Week Plan

Focus on Days 1-2 (fundamentals), Days 3-4 (URL Shortener + Twitter), and Day 10 (mock interview). Skip the advanced problems.

3 Days Plan

Day 1: Fundamentals (caching, databases, load balancers) Day 2: One complete problem (URL Shortener) + practice explaining Day 3: Mock interview + review

1 Day Plan

Focus on the framework: requirements → high-level design → deep dive → trade-offs. Practice talking through ONE problem end-to-end multiple times.

---

The Mindset That Gets Offers

Technical preparation matters, but mindset matters too.

What separates passes from fails:

1. Curiosity over defensiveness , When the interviewer pushes back, don't defend. Ask "What are you seeing?" and learn.

2. Structure over chaos , Always know where you are: requirements, design, or deep-dive. Announce transitions.

3. Depth over breadth , It's better to go deep on fewer components than shallow on everything.

4. Conversation over monologue , Check in with the interviewer. Ask if they want you to go deeper or move on.

5. Honesty over bluffing , If you don't know something, say "I'm not sure, but here's how I'd approach figuring it out..."

---

You've Got This

Two weeks ago, you might have panicked at "Design Instagram." Now you have a framework, vocabulary, and practice under your belt.

System design interviews are learnable. The engineers who pass aren't necessarily smarter, they're better prepared.

You've done the work. Trust the preparation.

Good luck. You've got this.

---

What's Next?

If you want to go deeper on any topic covered in this guide:

• Design a URL Shortener , Complete walkthrough with code examples
• System Design Interview Framework , The RESHADED method explained
• Top 25 System Design Questions , Full question bank with patterns