SLIDE 60: Practice Recommendations (Part 1)
How to Prepare for System Design Interviews
Study Plan (6-8 Weeks):
Week 1-2: Fundamentals
What to Study:
- Horizontal vs vertical scaling
- Load balancing (L4 vs L7)
- Caching strategies (write-through, write-back, cache-aside)
- Database sharding and replication
- CAP theorem (consistency, availability, partition tolerance)
- SQL vs NoSQL trade-offs
- Message queues and async processing
Resources:
- “Designing Data-Intensive Applications” by Martin Kleppmann (Chapters 1-5)
- System Design Primer (GitHub repo)
- YouTube: “Gaurav Sen” system design videos
Practice:
- No mock interviews yet
- Focus on understanding concepts deeply
- Take notes on trade-offs for each pattern
SLIDE 60B: Practice Recommendations (Part 2)
Week 3-4: Practice Problems
Problems to Practice:
How to Practice:
- Set 45-minute timer
- Work through problem on whiteboard/paper
- Record yourself (review later)
- Compare your solution to online solutions
- Note what you missed
Practice Alone First:
- Weeks 3-4: Solo practice (10-15 problems)
- Build confidence before mocking with others
SLIDE 60C: Practice Recommendations (Part 3)
Week 5-6: Mock Interviews
Mock Interview Partners:
What to Do:
- Schedule 2-3 mock interviews per week
- Rotate problems (don’t repeat same problem)
- Ask for candid feedback
- Focus on communication and time management
After Each Mock:
- What went well?
- What mistakes did I make?
- What concepts am I weak on?
- Practice those specific areas
SLIDE 60D: Practice Recommendations (Part 4)
Week 7-8: Company-Specific Prep
Research Target Companies:
If interviewing at Meta/Facebook:
- They built Instagram - study their architecture blog posts
- Know: Cassandra (they created it), TAO (graph store), Memcache
- Expect: Graph-heavy problems (friends, feed, groups)
If interviewing at Google:
- Know: BigTable, Spanner, MapReduce
- Expect: Large-scale data processing, search-related problems
If interviewing at Amazon:
- Know: DynamoDB, S3, Aurora
- Expect: E-commerce problems, highly available systems
If interviewing at Microsoft:
- Know: Azure services (Blob, Cosmos DB, Service Bus)
- Expect: Enterprise-scale, reliability-focused designs
How to Prep:
- Read company engineering blogs
- Know their open-source projects
- Tailor solutions to their tech stack
- Mention their technologies when relevant (but don’t force it)
SLIDE 60E: Practice Recommendations (Part 5)
Day Before Interview:
CODE
Do:
- Review key numbers (1M seconds/day, 1B = 10^9)
- Practice drawing architecture diagrams quickly
- Review your past mistakes (notes from mocks)
- Sleep well (8 hours - you need mental clarity)
Don't:
- Cram new concepts (won't retain)
- Practice new problems (might confuse)
- Stay up late (fatigue kills performance)
SLIDE 60F: Practice Recommendations (Part 6)
Interview Day:
CODE
Materials (If In-Person):
- Whiteboard markers (bring your own - theirs might be dry)
- Paper and pen for notes
- Water bottle
Before Interview:
- Arrive 15 minutes early
- Use bathroom (45-min interview, no breaks)
- Deep breaths (calm nerves)
During Interview:
- Ask if you can take 30 seconds to organize thoughts (they'll say yes)
- Think, structure, then speak
- Draw while explaining (engage visual learning)
After Interview:
- Note what questions were asked (for future reference)
- Don't dwell on mistakes (can't change it now)
SLIDE 60G: Practice Recommendations (Part 7)
Key Numbers to Memorize:
CODE
Time:
- 1 day = 86,400 seconds ≈ 100K seconds
- 1 month ≈ 2.5M seconds
Data:
- 1 KB = 1,000 bytes
- 1 MB = 1,000 KB = 1M bytes
- 1 GB = 1,000 MB = 1B bytes
- 1 TB = 1,000 GB
- 1 PB = 1,000 TB
Latency:
- RAM: <1 microsecond
- SSD: <1 millisecond
- Network (same datacenter): 1-5ms
- Network (cross-country): 50-100ms
- Network (cross-ocean): 100-300ms
Throughput:
- Single server: 1-10K QPS
- Database: 10K-100K QPS (with replicas)
- Redis: 100K+ QPS
Availability:
- 99.9% (three nines) = 8.76 hours downtime/year
- 99.99% (four nines) = 52.56 minutes downtime/year
- 99.999% (five nines) = 5.26 minutes downtime/year
SLIDE 61: Final Interview Tips (Part 1)
Final Tips for Success
Communication Best Practices:
Do’s:
SLIDE 61B: Final Interview Tips (Part 2)
Don’ts:
SLIDE 61C: Final Interview Tips (Part 3)
Leveraging Your Background:
Microsoft Experience:
When to Mention:
CODE
Good:
"At Microsoft, we encountered similar challenges with Teams scaling to 300M users.
We used a similar microservices approach..."
Adds credibility, shows real-world experience
When NOT to Mention:
CODE
Bad:
"At Microsoft, we always do it this way, so that's the only correct approach"
Sounds arrogant, inflexible
SLIDE 61D: Final Interview Tips (Part 4)
Oxford Computer Science:
When to Mention:
CODE
Good:
"From distributed systems coursework, I learned about the CAP theorem,
which applies here. We need to choose between consistency and availability..."
Shows academic foundation
When NOT to Mention:
CODE
Bad:
"At Oxford, we studied this extensively, so I know more than most engineers..."
Sounds condescending
SLIDE 61E: Final Interview Tips (Part 5)
Showing Depth vs Breadth:
Strategic Depth:
CODE
Interview flow:
1. Start broad (high-level architecture)
2. Wait for interviewer to ask for depth
3. Go deep on ONE area they choose
4. Show you CAN go deep on others if asked
Example:
Interviewer: "Tell me more about database design"
You: [Show detailed schema, indexes, sharding - the content from this presentation]
Interviewer: "Good. What about feed generation?"
You: [Show fan-out strategies, ranking algorithm]
This demonstrates both breadth (knew all components) and depth (can explain any in detail)
Avoid:
CODE
Going too deep too early:
"Let me explain every database column and every index in detail..."
[Spend 20 minutes on database, no time for other components]
Better:
"Here are the core tables. I can detail any of them if you'd like."
[Let interviewer guide which areas to explore]
SLIDE 61F: Final Interview Tips (Part 6)
Handling Difficult Moments:
Scenario 1: You Don’t Know Something
Wrong Response:
CODE
"I don't know" [silence]
Right Response:
CODE
"I haven't worked with that specific technology, but here's how I'd approach
the problem based on similar systems I have worked with. For production,
I'd research [specific aspect] more deeply and consult with specialists."
Shows: Problem-solving ability, honesty, willingness to learn
SLIDE 61G: Final Interview Tips (Part 7)
Scenario 2: Interviewer Challenges Your Design
Wrong Response:
CODE
"No, my approach is correct because..." [defensive]
Right Response:
CODE
"That's a great point I hadn't considered. If [their concern] is true,
then my approach would have problems. Let me think about an alternative...
What if we [adjusted approach]?"
Shows: Listening, adaptability, collaborative mindset
SLIDE 61H: Final Interview Tips (Part 8)
Scenario 3: You Realize You Made a Mistake
Wrong Response:
CODE
[Try to hide it or double down]
Right Response:
CODE
"Actually, I realize there's an issue with what I just proposed.
[Explain the problem]. Let me revise to handle that case..."
Shows: Self-awareness, honesty, ability to course-correct
SLIDE 61I: Final Interview Tips (Part 9)
Scenario 4: Running Out of Time
Wrong Response:
CODE
[Rush through remaining topics incoherently]
Right Response:
CODE
"I see we have 5 minutes left. I'd like to cover trade-offs and scaling.
Would you prefer I focus on one of those, or briefly touch both?"
Shows: Time awareness, prioritization, giving interviewer control
SLIDE 61J: Final Interview Tips (Part 10)
Body Language and Presence:
Positive Signals:
SLIDE 61K: Final Interview Tips (Part 11)
Negative Signals:
SLIDE 61L: Final Interview Tips (Part 12)
Final Mindset:
Remember:
- Interview is a Conversation, Not an Interrogation
- Interviewer wants you to succeed (hiring is hard)
- They’re evaluating if they’d enjoy working with you
- Be collaborative, not combative
- Perfect Solution Doesn’t Exist
- Every design has trade-offs
- Showing awareness of trade-offs > claiming perfection
- “It depends” is often the right answer (with reasoning)
- You Have Valuable Experience
- 12 years industry experience (Microsoft, Oxford)
- You’ve built real systems
- Reference this naturally, not boastfully
SLIDE 61M: Final Interview Tips (Part 13)
- Communication Equals Technical Skill
- 50% of score is how you communicate
- Clear explanation of good design > unclear explanation of perfect design
- Practice explaining to non-technical friends
- Interviewers Are Human
- They make mistakes too
- Sometimes the problem is ambiguous
- It’s OK to ask for clarification
- Be respectful even if you disagree
SLIDE 62: Complete Solution Summary (Part 1)
Instagram System Design: Complete Recap
Requirements:
- Functional: Upload photos, follow users, view feed, like/comment
- Non-Functional: 500M DAU, <500ms feed load, 99.99% availability, 73 PB/year storage
- Scope: Core feed functionality (Stories, DMs out of scope)
Capacity Estimation:
- Read QPS: 115,000 (peak: 350,000)
- Write QPS: 1,200 (peak: 3,600)
- Storage: 73 PB/year media, 36 TB/year metadata
- Bandwidth: 2.3 GB/sec ingress, 231 GB/sec egress
SLIDE 62B: Complete Solution Summary (Part 2)
Architecture:
- Microservices: User, Post, Feed, Media services
- Load balancer + API Gateway (auth, rate limiting)
- Stateless application servers (horizontal scaling)
Database:
- SQL (PostgreSQL) for relational data
- 5 tables: Users, Posts, Follows, Likes, Comments
- Sharding: 1,000 shards by user_id % 1000
- Replication: 1 primary + 3 read replicas per shard
- Indexes: Composite indexes on common query patterns
SLIDE 62C: Complete Solution Summary (Part 3)
API Design:
- RESTful endpoints (versioned /v1/)
- Cursor-based pagination (not offset)
- JWT authentication
- Rate limiting: Token bucket algorithm
Feed Generation:
- Hybrid fan-out: Write for normal users, read for celebrities
- Ranking: 40% recency, 30% engagement, 20% relationship, 10% content type
- Caching: Redis, 5-min TTL, 80% hit rate
SLIDE 62D: Complete Solution Summary (Part 4)
Media Storage:
- Object storage (S3/Azure Blob) for photos
- CDN for global delivery (80% cache hit rate)
- Async processing: Compression + 3 thumbnail sizes
- Lifecycle policies: Hot → Warm → Cold storage tiers
Scaling:
- Application: 1,000+ stateless servers, auto-scaling
- Database: 4,000 instances (sharding + replication)
- Cache: 400 Redis instances, partitioned
- Queue: Async workers for image processing, notifications
SLIDE 62E: Complete Solution Summary (Part 5)
Trade-Offs:
- Eventual consistency (feeds) vs Strong consistency (likes/follows)
- SQL vs NoSQL (chose SQL for relationships, transactions)
- Fan-out on write vs read (hybrid approach)
- Microservices complexity vs independent scaling
Cost: ~680M/year)
- Optimizations save $40-50M/year