Chapter 9: INTERVIEW STRATEGY - System Design Course: Complete Interview Preparation | PlayBook Library

SLIDE 57: Interview Timing Breakdown

Step 9: How to Present This in a 45-Minute Interview

Time Allocation Strategy:

Section	Time	What to Cover	What to Skip
Requirements	5-7 min	Functional, non-functional, scale, out of scope	Detailed justifications
Capacity Estimation	5-6 min	Storage, bandwidth, QPS (rough calculations)	Precise math
High-Level Architecture	8-10 min	Draw diagram, explain components, data flow	Implementation details
Deep-Dive 1	8-10 min	(Interviewer chooses: DB, Feed, or Media)	Other deep-dives
Deep-Dive 2	5-7 min	(Second topic if time permits)	-
Trade-Offs	3-5 min	Key decisions, alternatives considered	Extensive comparison
Scaling	3-5 min	How to scale each tier	Detailed config
Q&A / Buffer	5 min	Clarifications, follow-ups	-

Total: 42-50 minutes

SLIDE 57B: Interview Pacing - Requirements

Pacing Guide:

Minutes 0-7: Requirements

CODE

What to say:
"Let me start by clarifying requirements. For Instagram, I'll focus on core functionality:
photo uploads, following users, viewing a personalized feed, and social interactions like likes and comments.

Functional requirements:
[List 5-7 core features]

Non-functional requirements:
[Scale: 500M DAU, Performance: <500ms, Availability: 99.99%]

Out of scope for today:
[Stories, DMs, video encoding]

Does this align with what you're looking for?"

Wait for interviewer confirmation before proceeding.

SLIDE 57C: Interview Pacing - Capacity Estimation

Minutes 8-13: Capacity Estimation

CODE

What to say:
"Let me estimate capacity to inform architecture decisions.

[Write on whiteboard while talking:]
DAU: 500M
Views per user: 20 posts/day
Read QPS: 10B views / 86,400 sec ≈ 100K QPS

Posts per user: 0.2/day
Write QPS: 100M / 86,400 ≈ 1K QPS

Storage: 100M × 2MB × 365 = 73 PB/year

Key insight: Read-heavy (100:1), massive storage needs."

Don't spend more than 5 minutes on this - round numbers aggressively.

SLIDE 57D: Interview Pacing - High-Level Architecture

Minutes 14-25: High-Level Architecture

CODE

What to do:
1. Draw architecture diagram (microservices)
2. Walk through upload flow (2 min)
3. Walk through feed load flow (3 min)
4. Explain why microservices (1 min)
5. Point out CDN, caching, object storage (1 min)

What to say:
"Here's the high-level architecture. [Draw boxes]
We have microservices for User, Post, Feed, and Media management.
Object storage for media files, CDN for delivery.
Let me walk through two data flows..."

[Explain upload and feed load]

"The key decisions here are: microservices for independent scaling,
CDN for 231 GB/sec egress, and separation of media from metadata."

SLIDE 57E: Interview Pacing - Deep-Dive

Minutes 26-38: Deep-Dive (Interviewer-Driven)

CODE

Interviewer will ask:
"Tell me more about [database design / feed generation / media storage]"

Be ready to deep-dive on ANY component:
- Database: Show schema, sharding strategy, indexes
- Feed: Fan-out strategies, ranking algorithm, caching
- Media: S3, CDN, async processing, thumbnails

Spend 8-10 minutes on deep-dive.
Show actual schemas, algorithms, not hand-waving.

SLIDE 57F: Interview Pacing - Wrap-Up

Minutes 39-45: Trade-Offs and Wrap-Up

CODE

What to say:
"Let me discuss key trade-offs:

1. Consistency vs Availability: Chose eventual consistency for feeds,
   strong consistency for likes/follows.

2. SQL vs NoSQL: Chose SQL because data is relational, need for joins and transactions.

3. Fan-out strategy: Hybrid approach - write for normal users, read for celebrities.

These decisions optimize for Instagram's specific characteristics:
read-heavy, social graph, need for transactions.

Alternative approaches I considered:
[Briefly mention NoSQL, GraphQL, serverless - why not chosen]

Is there anything you'd like me to explore deeper?"

SLIDE 57G: Interview Tips - Do’s

Critical Interview Tips:

Do:

Think out loud (interviewer wants to hear your reasoning)
Ask clarifying questions before diving in
Draw diagrams (architecture, data flow, database schema)
Justify decisions (“I chose X because Y”)
Mention trade-offs (“This gives us A but costs us B”)
Adapt based on interviewer feedback

SLIDE 57H: Interview Tips - Don’ts

Don’t:

Jump to solution without requirements
Spend 20 minutes on capacity estimation (5-6 min max)
Design every single feature (focus on core)
Ignore time (check clock at 15, 25, 35 min marks)
Be defensive (if interviewer challenges, listen and adapt)
Memorize solutions (interviewers detect canned answers)

SLIDE 58: What Interviewers Look For - Scoring

Evaluation Criteria: How You’re Assessed

Scoring Rubric (Typical):

Criterion	Weight	What They’re Evaluating
Problem Understanding	20%	Did you ask good questions? Clarify requirements? Identify constraints?
System Design	40%	Is architecture sound? Does it scale? Are components well-separated?
Communication	20%	Can you explain clearly? Listen to feedback? Think out loud?
Trade-Off Analysis	20%	Do you understand no perfect solution? Justify choices? See alternatives?

SLIDE 58B: What Interviewers Look For - Strong Performance (Part 1)

What “Strong” Looks Like:

Problem Understanding (Strong):

CODE

Candidate asks:
- "Should we support Stories and Reels, or focus on main feed?"
- "What's more important: consistency or availability?"
- "Are we designing for Instagram's current scale or MVP?"
- "Can feed have slight staleness, or must be real-time?"

Then summarizes:
"So we're designing core feed functionality for 500M DAU, prioritizing
availability over consistency, with <500ms latency target. Correct?"

SLIDE 58C: What Interviewers Look For - Strong Performance (Part 2)

System Design (Strong):

CODE

Candidate:
- Draws clear architecture diagram with components
- Explains data flow for key operations (upload, feed)
- Shows actual database schema (not just "a database")
- Discusses sharding with specific strategy (user_id % 1000)
- Mentions caching at multiple layers with TTLs
- Points out bottlenecks and how to address them

SLIDE 58D: What Interviewers Look For - Strong Performance (Part 3)

Communication (Strong):

CODE

Candidate:
- Thinks out loud: "I'm considering two approaches: fan-out on write vs read..."
- Asks for feedback: "Does this approach make sense, or would you like me to explore alternatives?"
- Listens to hints: Interviewer says "What about celebrities with millions of followers?"
  Candidate: "Good point! Let me adjust the fan-out strategy..."
- Uses whiteboard effectively (diagrams, schemas, flows)

SLIDE 58E: What Interviewers Look For - Strong Performance (Part 4)

Trade-Off Analysis (Strong):

CODE

Candidate:
- "I'm choosing SQL over NoSQL because the data is relational and we need
  transactions for likes/follows. The trade-off is that horizontal scaling
  is harder - we'll need sharding. NoSQL would scale more easily but we'd
  lose joins and transactions which are critical here."

- "For feed generation, I'm using a hybrid approach: fan-out on write for
  normal users (fast reads) and fan-out on read for celebrities (avoid
  expensive writes). This adds complexity but handles both use cases well."

SLIDE 58F: What Interviewers Look For - Red Flags

Red Flags (What Gets You Rejected):

Red Flag	Example	Why It’s Bad
No Questions	Immediately starts designing without clarifying	Shows lack of real-world experience
Hand-Waving	“We’ll just cache it” (no details on what, where, TTL)	No depth, theoretical knowledge only
Ignoring Scale	Suggests single server or doesn’t mention sharding	Doesn’t understand distributed systems
No Trade-Offs	Claims solution is perfect with no downsides	Unrealistic, lacks nuance
Can’t Adapt	Interviewer hints at issue, candidate ignores	Poor listening, inflexible thinking
Over-Engineering	Suggests blockchain, quantum computing for simple problem	Buzzword-driven, not practical

SLIDE 58G: What Interviewers Look For - Green Flags

Green Flags (What Gets You Hired):

Green Flag	Example	Why It’s Good
Structured Approach	Requirements → Estimation → Design → Deep-Dive	Shows organization, methodical thinking
Production Mindset	Mentions monitoring, failure scenarios, costs	Real-world experience
Justifies Decisions	Every choice has “because…”	Critical thinking
Depth When Needed	Shows actual SQL schema, not just “database”	Technical competence
Breadth Awareness	Mentions alternatives considered	Well-rounded knowledge
Collaborative	Engages interviewer, asks for input	Good team player

SLIDE 59: Common Interview Mistakes (Part 1)

Interview Mistakes: Learn from Others’ Failures

Mistake 1: Solving a Different Problem

What It Looks Like:

CODE

Interviewer: "Design Instagram's core feed functionality"
Candidate: Proceeds to design Stories, Reels, DMs, e-commerce, ads...

Problem: Out of scope, wasting time

Correct Approach:

Confirm scope explicitly
Focus on core problem
Mention other features as “out of scope”

SLIDE 59B: Common Interview Mistakes (Part 2)

Mistake 2: Premature Optimization

What It Looks Like:

CODE

Candidate: "We'll use machine learning for feed ranking with deep neural networks
trained on user behavior data using distributed TensorFlow on Kubernetes..."

For an MVP with 1K users: Massive over-engineering

Correct Approach:

Start simple: “Initially, chronological feed. Later, add ranking by engagement.”
Mention ML as future enhancement
Scale complexity with user growth

SLIDE 59C: Common Interview Mistakes (Part 3)

Mistake 3: Hand-Waving Complexity

What It Looks Like:

CODE

Interviewer: "How do you generate the feed?"
Candidate: "We'll cache it in Redis"

Missing:
- WHAT is cached (post IDs, full objects?)
- HOW is cache populated (fan-out on write/read?)
- WHEN is cache invalidated (TTL?)
- WHERE is cache stored (cluster config?)

Correct Approach:

Specific details: “We cache post IDs in Redis sorted set, 5-min TTL,
populated via fan-out on write for normal users.”

SLIDE 59D: Common Interview Mistakes (Part 4)

Mistake 4: Ignoring Numbers

What It Looks Like:

CODE

Interviewer: "Can a single database handle this?"
Candidate: "Yes, databases can handle a lot of data"

Vague, no calculation

Correct Approach:

CODE

"Let me check: 100M posts/day × 1KB/post = 100 GB/day metadata.
Plus 2B users × 2KB/user = 4 TB users.
Over years: 10-50 TB total metadata.

Single PostgreSQL instance practical limit: ~10 TB.
So yes, initially. But we'll need sharding for growth to 50 TB."

Shows you can reason about scale

SLIDE 59E: Common Interview Mistakes (Part 5)

Mistake 5: Not Adapting to Hints

What It Looks Like:

CODE

Interviewer: "What if a user has 10 million followers?"
Candidate: [Ignores hint] "So the feed generation works by..."

Interviewer is trying to guide you to discuss celebrity problem!

Correct Approach:

CODE

Candidate: "Good point! With 10M followers, fan-out on write would be
expensive - 10M cache writes per post. Let me revise the approach
to use fan-out on read for users above a follower threshold..."

Shows you listen and adapt

SLIDE 59F: Common Interview Mistakes (Part 6)

Mistake 6: Architecture Astronaut (Buzzword Overload)

What It Looks Like:

CODE

Candidate: "We'll use blockchain for immutable post storage, implement
event sourcing with CQRS, deploy on serverless Kubernetes with service
mesh, and apply quantum algorithms for feed ranking..."

Using buzzwords without understanding

Correct Approach:

Use proven patterns: microservices, caching, sharding
Mention advanced topics only if relevant and you understand them
Justify why blockchain/ML/etc. is needed (usually it isn’t)

SLIDE 59G: Common Interview Mistakes (Part 7)

Mistake 7: No Error Handling / Monitoring

What It Looks Like:

CODE

Candidate designs perfect system, never mentions:
- What happens when database fails
- How to detect issues
- Logging and monitoring

Unrealistic - systems fail in production

Correct Approach:

Mention failure scenarios: “If primary DB fails, auto-failover to replica”
Monitoring: “Track latency, error rates, alert on anomalies”
Shows production mindset

SLIDE 59H: Common Interview Mistakes (Part 8)

Mistake 8: Poor Time Management

What It Looks Like:

CODE

30 minutes in, still discussing requirements
10 minutes left, rushing through architecture
No time for deep-dive or trade-offs

Interview ends before you showed technical depth

Correct Approach:

Check time at 15, 25, 35-minute marks
Requirements: 5-7 min MAX
Leave 10-15 minutes for deep-dive
If interviewer asks deep question at minute 40, that’s OK (they’re interested!)