46. The Interview Framework (RESHADED)

System design interviews aren't about getting the "right" answer; they're about demonstrating structured thinking under uncertainty. The interviewer is hiring for whether you can lead a design discussion in a real meeting.

46.1 The 45-minute structure

Time budget for a typical FAANG interview:

Phase	Time	What
1. Clarify requirements	5 min	functional + non-functional
2. Capacity estimation	5 min	QPS, storage, bandwidth
3. High-level design	5 min	boxes & arrows
4. API & data model	5 min	interfaces, schemas
5. Deep dive	15 min	2-3 hard problems
6. Bottlenecks & scale	10 min	what breaks at 10×, 100×

The clock is unforgiving. Practice keeps you on pace.

46.2 RESHADED (HelloInterview's framework)

A mnemonic for the interview structure:

• Requirements
• Estimation
• Storage
• High-level design
• API design
• Data schema
• Evolution / scale
• Deep dive

Adapt to your interviewer's pace and signals. Some want estimates first; some want a sketch. Read the room.

46.3 Phase 1: Requirements (5 min)

Functional

• "Walk me through what users do."
• 3-5 core features. Don't try to design every Twitter feature; pick the read & write paths.
• Confirm scope: "out of scope is direct messages and ads, right?"

Non-functional

• Scale: users, QPS read/write, geographic distribution.
• Latency targets: P50, P99 for key operations.
• Consistency requirements: strict (banking) vs eventual (likes).
• Availability target.
• Read:write ratio.

Edge cases & constraints

• Mobile / web / API?
• Data retention?
• Security/PII?
• Compliance?

Get specific numbers. Vague handwaves about "lots of users" won't drive design. If interviewer hedges, propose: "let's say 100M MAU."

46.4 Phase 2: Estimation (5 min)

(See chapter 2.) Quick math:

• DAU from MAU.
• QPS from DAU × actions/day ÷ 86,400.
• Peak QPS (3-5× average).
• Storage / day, / year.
• Bandwidth in / out.
• Memory for cache.
• Number of servers (rough).

Round aggressively. Use 100K not 86,400. State assumptions out loud.

If you skip this, design choices later sound arbitrary. Numbers anchor the conversation.

46.5 Phase 3: High-level design (5 min)

Sketch on the whiteboard / virtual canvas:

[Client] → [Load balancer] → [API gateway / app servers]
                                  │
                          ┌───────┼─────────┐
                       [DB]   [Cache]   [Async queue]
                          │
                  [Other services]

Walk through the request path:

• "User loads timeline → request hits LB → routed to timeline svc → checks cache → falls back to DB → returns."

Key components named with reasoning ("Postgres because relational + ACID; Redis for low-latency cache").

Don't go deep yet. Don't draw 30 boxes. Stay at the level the interviewer can see the system.

46.6 Phase 4: API & Data Model (5 min)

API

For each main flow, sketch the endpoint:

POST /tweets
GET /home_timeline?cursor=...
GET /users/{id}/timeline
POST /follows

REST vs gRPC discussion if relevant.

Pagination: cursor-based by default. Mention idempotency where applicable.

Data model

Tables (or document/wide-column shapes):

tweets (id, author_id, text, media_url, created_at)
follows (follower_id, followee_id, created_at)
timeline_cache: ZSET per user

For each:

• Sharding key
• Indexes
• Estimated size

46.7 Phase 5: Deep dive (15 min)

Pick 2-3 of:

• Caching strategy
• Replication / consistency
• Sharding
• Async pipeline / fan-out
• Hot key handling
• Search index
• Real-time push (WebSocket fan-out)

The interviewer often nudges: "let's talk about scale of timelines" or "how do you handle a celebrity?"

Show trade-offs. "Push fan-out has cheap reads but expensive writes for celebrities; pull is opposite; hybrid is the standard answer."

For each chosen topic:

1. The problem.
2. The naive solution.
3. Why it doesn't scale / what breaks.
4. The improved solution.
5. Trade-offs.

This pattern shows judgment.

46.8 Phase 6: Bottlenecks & scale (10 min)

"What breaks at 10× load? At 100×?"

Walk through:

• DB writes saturate → shard or write to a queue.
• Read load on cache → multi-tier (L1 in process + L2 distributed).
• Hot keys → replicate, local cache, dedicated capacity.
• Geographic latency → multi-region, CDN, edge.

Cover failure modes:

• Cache cluster down → fallback path exists?
• DB primary down → failover plan?
• Cross-region partition → CP or AP behavior?

46.9 Communication patterns

State your assumptions

Out loud, all the time. Wrong assumption is fine; silent assumption is wasted effort.

Drive the discussion

Don't wait for prompts. "Next, I want to talk about timeline caching."

Time-box yourself

"I'll spend 5 min on requirements; let me know if you'd rather I focus elsewhere."

Ask for confirmation

"Does push fan-out with celebrity pull sound reasonable? Should I dive in or is there another area you'd like me to cover?"

Number-driven decisions

Don't say "we should cache." Say "with 500K reads/sec and 99% cache hit ratio, we offload to ~5K DB reads/sec, which Postgres handles."

Acknowledge what you don't know

"I'm not sure about the exact threshold for CDN cost-effectiveness; in this scope I'd assume CDN is right at >100GB/day egress."

46.10 Common red flags (avoid these)

• Jumping to a solution before requirements. "I'd use Cassandra" with no question asked = bad.
• No numbers. "Lots of QPS" doesn't drive design.
• Cargo-culting tools. "We'd use Kafka and Cassandra and ES and..." without justification.
• Hand-waving over hard problems. "Then the data is consistent" needs explanation.
• Ignoring failure modes. Real systems break.
• One-way conversation. Not engaging interviewer's hints.
• Going down rabbit holes. Spending 20 min on schema while ignoring scaling.
• Forgetting to discuss trade-offs. Every choice has alternatives.

46.11 Common patterns of strong candidates

• Structured. Phases visible.
• Numbers-driven.
• Trade-off-aware. "X pros, Y cons; in this context I'd pick X."
• Engages the interviewer. Asks if going right direction.
• Acknowledges complexity without getting paralyzed.
• Mentions concrete tools but doesn't fetishize them.
• Anticipates follow-ups. "We'd need a fan-out service; let me come back to that."

46.12 Behavioral signals

The interviewer is also assessing:

• Pragmatism: do you over-engineer?
• Communication: can you collaborate?
• Curiosity: do you ask interesting questions?
• Judgment under uncertainty: do you commit to a direction with stated trade-offs?

46.13 What to do when stuck

• "Let me think about that for a moment."
• Reason out loud: "If we had X, we could do Y; but we don't, so let's consider..."
• Ask: "Is there a constraint I'm missing?"
• Move on if a hard sub-problem isn't critical to the overall design; flag and return.

Don't fake it. Interviewers see through.

46.14 Mock practice

Ten mocks > 100 hours of reading.

• Pramp (free): peer-to-peer.
• interviewing.io: paid, ex-FAANG interviewers ($150-200/mock).
• HelloInterview: video walkthroughs and mock service.
• Solo whiteboard: time yourself; record; re-watch.
• Friend / colleague: any interviewer with real systems experience helps.

Aim for: at least 8-10 full mocks before a real interview.

46.15 Per-company flavor

• Google: emphasis on scale, fundamentals, distributed systems, papers (Spanner, Bigtable, GFS). Coding interviews often interleave.
• Meta: pragmatic system design; production-realistic; less academic.
• Amazon: leadership principles infused; "tell me about a system you built." Design + behavioral hybrid.
• Microsoft: similar to Google; Azure-aware sometimes.
• Stripe / DoorDash / Uber: domain-relevant designs (payments, marketplaces).

Adjust depth and emphasis accordingly.

46.16 The day-of mindset

• Eat, sleep, hydrate.
• Have water at the desk.
• Have paper, pen, dual monitor / decent setup.
• Read the question twice before designing.
• Repeat the question back: "So you want me to design a system that does X for N users..."
• Ask clarifying questions for the first 3-5 minutes; don't sprint to design.
• Manage clock visibly: "We have 45 min; I'll spend 5 on each phase."

46.17 After the interview

• Self-debrief: what went well? What didn't?
• Track patterns across interviews.
• Adjust prep accordingly.

Key takeaways

• Use a framework (RESHADED or the 6-step). Phases visible to interviewer.
• Numbers drive design. Estimate early; refer back.
• Show trade-offs explicitly; never present an architecture as "the answer."
• Communicate continuously; no silent thinking.
• Mock practice is the single highest-leverage prep activity.