1. Introduction

Google’s L5 (Senior Software Engineer) loop typically consists of:

  • 2 coding rounds (algorithms/data structures)

  • 1 system design round (45 min)

  • 1 "Googleyness & Leadership" behavioral round (45 min)

  • Sometimes an additional coding round or a domain round depending on team

The coding is where people pass the bar. The behavioral and system design are where people fail it — not because the technical content is harder, but because the evaluation criteria are fuzzier and most candidates under-prepare. This guide focuses on those two.

At L5, the hiring bar shifts from "can you solve it" to "can you drive it." The interviewer is looking for signals that you can operate autonomously on ambiguous problems, make judgment calls under uncertainty, and influence people around you. Every answer you give should — implicitly or explicitly — demonstrate one of those three things.

2. Part 1: Behavioral Interview

2.1. What Google actually evaluates

The behavioral round is officially called Googleyness & Leadership (GLE). Despite the soft name, it’s a structured interview with specific signals. Interviewers fill in a rubric across roughly these dimensions:

  • Navigating ambiguity — can you make progress without full information?

  • Drive and ownership — do you push things across the finish line, including things that aren’t strictly your job?

  • Collaboration and influence — can you align peers and stakeholders who don’t report to you?

  • Dealing with conflict — do you handle disagreement productively?

  • Learning and growth — do you seek feedback, change your mind, and upskill?

  • Impact — what did your work actually change for users, the team, or the business?

At L5 specifically, the scope that demonstrates each of these needs to be team-level or larger. Not a single feature you shipped. Not a bug you fixed well. The examples must show you operating across boundaries — multiple engineers, multiple teams, multiple quarters of timeline, or problems without a clear owner.

2.2. The STAR framework (and where most people fail it)

Every behavioral answer should follow STAR:

*S*ituation

Context: the team, the project, the stakes. ~20 seconds.

*T*ask

What specifically you were responsible for. Not the team — you. ~15 seconds.

*A*ction

What you did. Specific, sequential, in first person. ~60-90 seconds. This is the bulk.

*R*esult

The outcome, with numbers where possible, and what you learned. ~20 seconds.
The most common failure mode is inverting this: candidates spend 3 minutes on Situation, then rush through Action. Interviewers care about your decisions and behaviors, which live in Action.

2.2.1. The "I" vs "we" discipline

In every Action, use "I" when describing what you personally did. Use "we" only for team context. This is not pedantic — it’s how the interviewer distinguishes your contribution from your team’s. "We migrated the database" tells them nothing about you. "I proposed the migration plan, got buy-in from the platform team, and personally wrote the backfill script" tells them a lot.

Many senior engineers feel awkward doing this because it sounds self-promotional. It isn’t — the interviewer can’t read minds, and if you don’t claim your contributions, they’ll assume you didn’t have any.

2.2.2. Specificity over generality

Weak: "I often mentor junior engineers and help them grow."

Strong: "In Q3 last year, a junior engineer on my team was struggling with code review feedback. I set up weekly 1:1s, walked through one of his PRs line by line with him, and paired on the next one. Three months later his review cycles dropped from 8 iterations to 2, and he led the next feature himself."

The weak version describes a pattern. The strong version is an event. Interviewers score events, not patterns.

2.3. The Googleyness dimensions, explained

Understanding the rubric helps you map your stories to what interviewers are scoring.

2.3.1. Navigating ambiguity

What it looks like: You were given a vague problem ("improve onboarding" / "figure out why latency is bad" / "help this team that’s stuck") and you made it concrete without someone telling you how.

Signal they want:

  • You broke the problem down.

  • You made assumptions explicit and checked them.

  • You picked a direction and moved, then corrected course.

  • You knew when to escalate vs. when to decide.

Weak story: "My manager told me to do X and I did X." Strong story: "The goal was 'reduce support tickets.' Nobody told me how. I pulled the last 6 months of tickets, clustered them, found 60% were the same auth issue, proposed a fix, got two engineers to help, shipped it, saw a 40% drop."

2.3.2. Drive and ownership

What it looks like: You saw something broken or missing that wasn’t your assigned work, and you did it anyway — or you pushed a project through obstacles others would have given up on.

Signal they want:

  • You don’t wait to be told.

  • You finish things, including the unglamorous last-10%.

  • You absorb ambiguity so others don’t have to.

Key phrase to use: "It wasn’t officially my problem, but…​" or "Nobody was going to do it, so I…​"

2.3.3. Collaboration and influence

What it looks like: You aligned people you had no authority over — other teams, senior engineers, PMs, partner orgs — on a direction.

Signal they want:

  • You listen before pushing.

  • You frame your proposal in terms of their goals, not yours.

  • You build consensus when possible and make a call when consensus isn’t coming.

Weak story: "I convinced them by writing a very clear doc." Strong story: "Team A wanted approach X, team B wanted approach Y. I set up a 45-min meeting, had each side state their top constraint, found that X’s main objection was about latency and Y’s main objection was about cost. I proposed a hybrid that used Y’s storage layer and X’s caching. Both teams signed off in the meeting."

2.3.4. Dealing with conflict

What it looks like: You disagreed with a peer, a manager, or a stakeholder — and you resolved it professionally, including cases where you were the one who turned out to be wrong.

Signal they want:

  • You engage with disagreement head-on; you don’t avoid or stew.

  • You separate people from positions.

  • You are willing to change your mind when the data points that way.

  • You disagree-and-commit when the decision goes against you.

Interviewers are specifically watching for candidates who never lose an argument in their stories. That’s a red flag. Have at least one story where you were wrong, admitted it, and adjusted.

2.3.5. Learning and growth

What it looks like: You sought feedback, changed your behavior based on it, and leveled up a skill deliberately.

Signal they want:

  • You’re self-aware about weaknesses.

  • You actively seek criticism rather than waiting for it.

  • You can point to a specific thing you got better at and how.

2.3.6. Impact

What it looks like: Your work mattered to users, revenue, team velocity, or engineering quality — with numbers attached where possible.

Signal they want:

  • You can quantify outcomes (latency X → Y, cost $A → $B, tickets down Z%).

  • You tie your work to broader org goals, not just technical metrics.

  • At L5, at least one story should have cross-team or cross-quarter impact.

If your past work has impact numbers and you don’t know them off the top of your head — go look them up before the interview. "I think it improved things" is a losing answer when the candidate next to you says "latency dropped from 340ms p99 to 95ms p99, which reduced cart abandonment by 11%."

2.4. The story bank: what to prepare

You need roughly 8–12 stories prepared in advance. Each story can answer multiple question types, so you don’t need one per question.

Prepare stories in at least these categories:

  1. A project you drove end-to-end — design, execution, launch, impact.

  2. A time you disagreed with someone senior — how you handled it.

  3. A time you were wrong — how you realized, what you did.

  4. A time you dealt with a difficult peer — not a villain story, a growth story.

  5. A time you had to say no — to scope, to a stakeholder, to your manager.

  6. A time you influenced without authority — cross-team alignment.

  7. A time you mentored someone — with specific before/after.

  8. A time you dealt with a serious production issue — calm under pressure, postmortem ownership.

  9. A time you made a hard tradeoff — picking between two legitimate options.

  10. A failure — a project that didn’t work, what you learned, what you’d do differently.

  11. A time you made an unpopular decision that turned out right.

  12. A time you had to learn something new fast.

For each story, write down:

  • The 30-second pitch (elevator version)

  • The 2-minute version (STAR fully developed)

  • The metrics/outcomes (specific numbers)

  • Three follow-up questions you might get ("what would you do differently?", "how did X feel about it?", "what was the hardest part?") and your answers

2.5. Common questions and how to approach them

2.5.1. "Tell me about yourself"

Not actually a softball. This is where the interviewer decides which direction to probe.

Structure (90 seconds max):

  1. One sentence: current role and scope.

  2. 2-3 sentences: career arc — what you’ve built, technical themes.

  3. 2-3 sentences: what you’re working on now and why it matters.

  4. One sentence: why you’re here / why this team.

Do not recite your resume. The interviewer has it. Pick the 3-4 threads you want them to pull on, and leave hooks — mentioning a project in passing so they ask about it.

2.5.2. "Tell me about a time you had conflict with a coworker"

Trap: Making the other person sound unreasonable. Goal: Show that you engage with conflict directly, assume good intent, and separate the disagreement from the relationship.

Template:

  1. What the disagreement was about (technical, not personal).

  2. Why you initially thought you were right.

  3. What you did to understand their position (1:1, reading their doc, asking questions).

  4. How you either (a) changed your mind, (b) found a synthesis, or (c) escalated to a decision-maker when alignment wasn’t possible.

  5. What the working relationship looked like after.

2.5.3. "Tell me about a time you failed"

Trap: Giving a fake failure ("I work too hard"). Goal: Show genuine self-awareness and that failure produces learning you act on.

Pick a real failure where:

  • You had meaningful ownership of the outcome.

  • The failure was bounded (not career-ending, not someone else’s fault).

  • You learned something specific that shows up in how you work now.

End with: "What I took from this was X. You can see that in how I approach Y now." Concrete behavior change is the signal.

2.5.4. "Why Google? / Why this team?"

Do the research. Read the team’s public work, papers if any, recent product launches. Say something that couldn’t apply to any other company.

Weak: "Google has a great engineering culture and I want to work on hard problems." Strong: "I’ve been following the team’s work on X since the paper/launch. What interests me specifically is Y, because in my current role I’ve been dealing with Z, and I’d want to work on it at Google’s scale."

2.5.5. "What’s a weakness?"

Trap: Humblebrag ("I’m too detail-oriented"). Goal: Genuine self-aware weakness + specific concrete actions you’re taking.

Pick a real weakness that:

  • Is not a core job requirement (don’t say "I’m bad at coding" for a SWE role).

  • You’ve been actively working on.

  • You can demonstrate recent, specific progress.

Example: "Historically I’ve jumped to solutions too fast — I’d see a problem and start coding before fully understanding the constraints. I’ve been working on this deliberately for the last year by forcing myself to write a one-pager before any project with more than 2 weeks of work. On the last three projects, it caught requirements I’d have missed."

2.5.6. "Describe a project you’re most proud of"

Your anchor story. Pick the one that:

  • Shows the most L5-appropriate scope.

  • Has clear, quantified impact.

  • Has obvious opportunities for follow-up questions you’re prepared for.

  • You can tell in 3-4 minutes with enthusiasm.

This is the story you’ve rehearsed most.

2.5.7. "How do you handle disagreement with your manager?"

Signal they want: You push back when you disagree, but you respect decision authority.

Show:

  1. You raise the disagreement directly, in private, with data.

  2. You genuinely consider their perspective — managers often have context you don’t.

  3. If you still disagree after the discussion, you can either ask to escalate with them, or disagree-and-commit and execute fully.

  4. You do not passive-aggressively undermine the decision.

2.6. L5 signal calibration

The difference between an L4 and L5 behavioral answer is usually scope and autonomy. Interviewers are mentally asking:

  • Did this person decide something, or were they told?

  • Was the scope their feature, or the team’s system?

  • Did the impact end at shipping, or did it include adoption, followup, and iteration?

If your stories mostly describe being assigned work, executing it well, and handing it off — that’s L4. Push your examples toward stories where you:

  • Identified the problem yourself

  • Scoped it

  • Got resources (people, time, approval)

  • Drove execution, possibly through others

  • Measured impact post-launch

  • Iterated based on results

Even if one of your actual stories covers only part of that arc, you can emphasize the parts where you did own it.

2.7. Anti-patterns to avoid

  1. The hero narrative. Stories where you’re the only competent person. Interviewers don’t believe them and also don’t like them.

  2. Vague outcomes. "It was a big success" — compared to what? How do you know?

  3. No "I". Stories told entirely in "we" make you invisible.

  4. No conflict or failure anywhere. A candidate with no failures has either been in easy roles or isn’t being honest.

  5. Blaming others. Even if the other party was genuinely bad, describing them as such makes you look bad. Describe behaviors, not characters.

  6. Generic leadership buzzwords. "I’m a servant leader who empowers through psychological safety." What did you do last Tuesday?

  7. Running out of examples. If you only have 3 stories and the interviewer asks 5 questions, you’ll repeat. Have 10+.

2.8. Questions to ask the interviewer

You’ll get 5-10 minutes at the end. This is evaluated. Asking nothing, or asking only logistics ("when will I hear back"), is a negative signal.

Good questions show you’ve thought about the role:

  • "What’s the hardest technical problem the team is working on right now?"

  • "How does the team decide what to work on? Is it top-down, bottom-up, or mixed?"

  • "What does a successful engineer on this team look like 18 months in?"

  • "What’s something you wish you’d known before joining the team?"

  • "Where does the team struggle — what’s not working well right now?" (bold but well-received if asked respectfully)

  • "How is technical disagreement resolved on the team?"

Don’t ask things easily Googleable (benefits, team size from the careers page, what the product does).

3. Part 2: System Design

3.1. What L5 system design actually tests

A 45-minute system design interview at L5 is evaluating five things:

  1. Can you handle ambiguity? — the problem will be vague on purpose.

  2. Do you know the building blocks? — load balancers, caches, databases, queues, etc.

  3. Can you reason about tradeoffs? — every choice has alternatives; can you compare them?

  4. Can you go deep? — after the high-level design, the interviewer will zoom into one component. Can you discuss it at the level of a specialist?

  5. Can you communicate? — structured thinking, clear diagrams, explicit assumptions.

L5 is not expected to invent new distributed algorithms. You’re expected to know the common ones, apply them correctly, and justify your choices. L6 starts expecting novel design under genuinely new constraints.

The interviewer is not looking for "the right answer" — they’re looking for a defensible answer with explicit reasoning. Two candidates can pick opposite architectures and both pass, if both justified their choice against the requirements.

3.2. The 45-minute framework

Here’s how to spend the time:

Minutes Phase What you’re doing

0-5

Requirements

Clarify functional and non-functional requirements. Define scope.

5-10

Capacity estimation

Back-of-envelope numbers: QPS, storage, bandwidth.

10-15

API and data model

Define the interface and the core data structures.

15-25

High-level architecture

Draw the box-and-arrow diagram. Justify each component.

25-40

Deep dive

The interviewer picks (or you propose) 1-2 areas to go deep. Bottlenecks, scaling, failure modes.

40-45

Wrap-up

Summarize, identify what you’d improve with more time, open questions.
Interviewers will interrupt. That’s fine and expected. Don’t get thrown off — absorb the question, answer it, and return to your structure.

3.3. Phase 1: Requirements (do not skip)

Most candidates lose points in the first 5 minutes by rushing this. Never start drawing boxes before you’ve nailed down requirements.

3.3.1. Functional requirements

What must the system do? List the core features. Explicitly deprioritize out-of-scope things.

Example for "Design Twitter":

  • Users can post tweets (text, max 280 chars)

  • Users can follow/unfollow other users

  • Users can view a timeline of tweets from people they follow

  • Users can like tweets

  • Out of scope for this discussion: DMs, search, trending, ads, media uploads

Saying "out of scope" is valuable — it shows you recognize the full problem but are bounding what you’ll design.

3.3.2. Non-functional requirements

How well must it do it? These drive most of your architecture choices.

  • Scale: how many users, DAU, MAU? What’s the read/write ratio?

  • Latency: what’s the p50, p99 target for reads and writes?

  • Availability: 99.9%? 99.99%? (Each nine is an order of magnitude more effort.)

  • Consistency: strong, eventual, read-your-writes, causal?

  • Durability: can we afford to lose data? How much?

You won’t get precise answers — estimate them yourself and state them as assumptions. "Let’s assume 200M DAU, read-heavy, 100:1 read/write ratio, p99 timeline load under 300ms, eventual consistency is acceptable for the timeline."

3.4. Phase 2: Capacity estimation

Keep the math simple and legible. Round aggressively.

3.4.1. The numbers every engineer should memorize

Operation Rough latency

L1 cache

0.5 ns

L2 cache

7 ns

Main memory

100 ns

SSD random read

100 μs (= 100,000 ns)

Network round trip within datacenter

500 μs

Disk seek (spinning)

10 ms

Network round trip across continents

150 ms
Quantity Rough size

Seconds in a day

~86,400 (round to 100,000)

Seconds in a month

~2.5M

Requests/sec at 1M DAU

~12 RPS (if one request per day per user — obviously higher in practice)

3.4.2. Estimation template

  1. Users: DAU = X. Assume each makes Y actions per day.

  2. QPS: (X × Y) / 86,400 ≈ Z reqs/sec. Peak is ~2-3× average.

  3. Storage per object: estimate bytes per record.

  4. Total storage/year: QPS_writes × bytes × seconds_in_year.

  5. Bandwidth: QPS × avg_payload_size.

  6. Memory for cache: target hit rate × hot working set.

Example, rough Twitter:

  • 200M DAU, avg 50 tweet-reads per day → 10B reads/day → ~120K reads/sec, peak ~300K reads/sec.

  • 1 tweet write per user per 2 days avg → 100M writes/day → ~1.2K writes/sec peak ~3K.

  • Tweet: ~300 bytes. 100M/day × 300B = 30 GB/day = ~11 TB/year just for tweet bodies.

Don’t pretend these are precise. State assumptions, do the arithmetic aloud, round.

3.5. Phase 3: API and data model

3.5.1. API

Define 4-6 endpoints in a stable format. REST-ish is fine unless you have a reason to pick gRPC or GraphQL.

POST /tweets
  body: { user_id, text }
  returns: { tweet_id, timestamp }

GET /users/:user_id/timeline
  params: { limit, cursor }
  returns: { tweets[], next_cursor }

POST /follow
  body: { follower_id, followee_id }

Explicit pagination (cursors, not offsets — offsets don’t scale) is a senior-level detail worth naming.

3.5.2. Data model

Sketch the core tables or documents. Show keys and indexes.

Users:        user_id (PK), username, created_at, ...
Tweets:       tweet_id (PK), author_id (indexed), text, created_at
Follows:      follower_id, followee_id  (compound PK)
                — index on followee_id for reverse lookups

Call out which fields are indexed and why. At L5, absence of index discussion is a miss.

3.6. Phase 4: High-level architecture

Draw boxes for the major components. A typical web-scale architecture has some subset of:

  • Client (web, mobile)

  • DNS / CDN

  • Load balancer (L4 or L7, active-passive or active-active)

  • API gateway / reverse proxy

  • Application servers (stateless, horizontally scaled)

  • Cache layer (Redis/Memcached)

  • Database(s) (primary store, plus specialized stores)

  • Message queue (Kafka, SQS, RabbitMQ) for async work

  • Background workers

  • Object storage (S3, GCS) for blobs

  • Search index (Elasticsearch) if needed

  • Monitoring/logging (briefly mention)

For each box, say why it’s there. "Load balancer so we can horizontally scale the app tier and handle host failures." "Cache because the read-heavy workload means DB reads are the bottleneck and the working set fits in memory."

3.7. Phase 5: Deep dive — where L5 is won or lost

The interviewer will pick an area ("let’s talk about how the timeline is generated" / "how do we shard the tweets table" / "what happens when the cache goes down"). Be ready to go 10+ minutes on any of:

  • Data partitioning / sharding strategy

  • Caching strategy and invalidation

  • Consistency model and replication

  • Failure modes — what dies, what happens, how we recover

  • Hot spot mitigation

  • Rate limiting / backpressure

The signal here is depth. One specific mechanism discussed thoroughly beats three mentioned superficially.

3.8. Core building blocks: reference

3.8.1. Load balancers

  • L4 (transport layer): routes on IP/port. Fast, but no application awareness. Example: AWS NLB.

  • L7 (application layer): routes on HTTP headers/path. Can do SSL termination, sticky sessions, header-based routing. Example: AWS ALB, Envoy, NGINX.

  • Algorithms: round-robin, least-connections, consistent hashing, weighted.

  • HA: active-passive with VIP failover, or active-active with anycast/DNS.

3.8.2. Caching

Key decisions:

  • Where: client-side, CDN, reverse proxy, application-local (in-process), distributed (Redis/Memcached), database buffer pool.

  • What: full objects, query results, computed aggregates, sessions.

  • Write policies:

    • Write-through: write to cache and DB simultaneously. Consistent but slow writes.

    • Write-back (write-behind): write to cache, async to DB. Fast but durability risk.

    • Write-around: write to DB only, cache on read. Good for write-heavy with low re-read.

  • Read policies:

    • Cache-aside (lazy loading): app checks cache first, falls back to DB, populates cache. Most common.

    • Read-through: cache itself fetches from DB on miss.

  • Eviction: LRU (most common), LFU, FIFO, TTL-based.

  • Invalidation: TTL expiry, explicit purge, versioned keys, write-through updates.

The "two hard things in computer science" quote is actually about cache invalidation and naming. Invalidation is the harder half. When you pick a caching strategy, explicitly address: how is stale data prevented, how long can it be stale, and what happens when a write needs to invalidate entries across cache nodes.

3.8.3. Databases

SQL (Postgres, MySQL, Spanner)

  • Strong consistency, ACID transactions, rich querying.

  • Vertical scaling primary; horizontal via read replicas or sharding.

  • Use when: relational data, complex queries, strong consistency needed, transactions matter.

  • Modern: Spanner, CockroachDB, Vitess — distributed SQL with horizontal scaling.

NoSQL — key-value (Redis, DynamoDB, Bigtable)

  • Simple model: get/put by key. Horizontal scaling by design.

  • Use when: massive scale, simple access patterns, low latency.

NoSQL — document (MongoDB, Firestore)

  • JSON-like documents, flexible schema.

  • Use when: schema evolves, nested structures, per-document queries.

NoSQL — wide-column (Cassandra, HBase, Bigtable)

  • Row has many columns, optimized for time-series and write-heavy workloads.

  • Use when: high write throughput, time-series, partition by row key.

Graph (Neo4j, Neptune)

  • Relationships are first-class.

  • Use when: queries traverse many hops (social graph, fraud rings, recommendations).

Search (Elasticsearch, OpenSearch)

  • Inverted index for full-text search, aggregations.

  • Not a primary store — keep source of truth elsewhere and sync.

3.8.4. Message queues & streaming

  • Queue (SQS, RabbitMQ): FIFO-ish, message consumed once. Good for task distribution.

  • Log/stream (Kafka, Kinesis, Pulsar): messages persisted, multiple consumers can replay. Good for event sourcing, audit, fan-out.

  • Pub/sub (Google Pub/Sub, Redis Pub/Sub): broadcast to subscribers.

Use cases for any queue: decouple producers from consumers, buffer traffic spikes, retry async work, process in parallel.

3.8.5. CDN

Serves static assets and increasingly dynamic content from edge locations near users. Cuts latency dramatically for geographically distributed users. Every serious web-facing system has one.

3.9. Distributed systems fundamentals

3.9.1. CAP theorem

In a network partition, you choose between consistency and availability. You cannot have both. Partition tolerance isn’t optional in a distributed system, so the real choice is CP or AP.

  • CP: refuse requests when consistency can’t be guaranteed. E.g., single-leader databases during partition.

  • AP: accept requests, reconcile later. E.g., Dynamo-style, multi-leader setups.

3.9.2. PACELC (the one people forget)

CAP only talks about the partition case. PACELC extends it: If Partition, then Availability or Consistency; Else, Latency or Consistency.

Even with no partition, you trade latency for consistency. Writing synchronously to 3 replicas is more consistent and slower. Async replication is faster and allows stale reads. Most real systems tune this tradeoff per-request.

3.9.3. Consistency models (from strongest to weakest)

  • Linearizability (strong): every operation appears atomic and in real-time order. Expensive.

  • Sequential consistency: operations appear in some total order consistent with each client’s order.

  • Causal consistency: causally related operations are ordered; concurrent ones aren’t.

  • Read-your-writes: you always see your own writes; others may lag.

  • Eventual consistency: given no new writes, all replicas converge.

At L5, know which model you need for which feature. "The like counter can be eventually consistent — nobody cares if it’s off by 5 for 2 seconds. But the account balance in a transfer needs linearizability."

3.9.4. Replication

  • Single-leader (primary-replica): writes go to leader, replicate to followers. Common (Postgres, MySQL).

    • Sync replication: durable but slow.

    • Async: fast but can lose writes on leader failure.

    • Semi-sync: at least one follower must ack.

  • Multi-leader: multiple accept writes, replicate to each other. Complex conflict resolution. Used across datacenters.

  • Leaderless (Dynamo-style): clients write to N, wait for W acks; read from N, wait for R responses. If W+R > N, guaranteed to read latest. Tunable.

3.9.5. Partitioning / sharding

Strategies:

  • Range partitioning: shard by key range. Good for range scans, bad for hot keys (e.g., timestamps — latest range is a hot spot).

  • Hash partitioning: shard by hash(key). Even distribution, poor for range queries.

  • Consistent hashing: hash both keys and nodes onto a ring; each key goes to the next node clockwise. Adding/removing a node only moves ~1/N of keys. Used in Dynamo, Cassandra, memcached clusters.

  • Directory-based: lookup service tracks where each key lives. Flexible, adds a layer.

Common pitfall: hot shards. If your partition key is non-uniform (user_id where 1% of users generate 90% of traffic), some shards burn while others idle. Fixes: secondary sharding, adding randomness to the key, isolating hot keys to their own shards.

3.9.6. Consensus

When a distributed system needs to agree on something (leader election, committed log entries), it uses a consensus algorithm:

  • Paxos: original, famously hard to implement.

  • Raft: designed to be understandable. Used in etcd, Consul, CockroachDB.

  • Zab: ZooKeeper’s protocol.

You don’t need to implement one — but you should know where consensus is used: leader election, distributed locks, configuration stores, committing writes across replicas.

3.9.7. Idempotency

Any operation that might be retried (and in distributed systems, everything might be retried) should be idempotent. Include a client-provided request ID and dedupe server-side. This is senior-level plumbing that interviewers love to hear discussed.

3.10. Canonical problems to know cold

You should be able to sketch a reasonable design for each of these in 30 minutes:

  1. URL shortener (TinyURL/bit.ly) — ID generation, redirection, analytics.

  2. Rate limiter — token bucket, sliding window, distributed rate limiting.

  3. News feed (Twitter, Instagram) — fanout-on-write vs fanout-on-read, hybrid.

  4. Chat/messaging (WhatsApp, Slack) — long polling / websockets, message ordering, delivery guarantees, presence.

  5. Typeahead/autocomplete — trie, caching, personalization.

  6. Web crawler — frontier, dedup, politeness, DNS caching.

  7. Distributed cache (Memcached/Redis cluster) — consistent hashing, eviction, replication.

  8. Distributed file/object storage (Google Drive, Dropbox) — chunking, dedup, sync, conflict resolution.

  9. Video streaming (YouTube, Netflix) — CDN, chunked encoding, adaptive bitrate, metadata vs media split.

  10. Ride-sharing (Uber) — geo-indexing, matching, real-time location.

  11. Notification system — fanout, throttling, priority queues, retries, dedup.

  12. Ad click aggregation / metrics pipeline — stream processing, windowing, at-least-once vs exactly-once.

  13. Payment/order system — sagas, idempotency, two-phase vs compensating transactions.

  14. Search engine (basic) — indexing pipeline, inverted index, ranking.

For each, know:

  • The core data model.

  • The main read and write paths.

  • The primary scaling bottleneck.

  • The "L5 insight" — the one non-obvious design choice.

Example — News feed: the L5 insight is that fanout-on-write (precompute each user’s timeline on post) and fanout-on-read (build on demand) each have a failure mode, so production systems (like Twitter) use hybrid: fanout-on-write for normal users, fanout-on-read for celebrities with millions of followers.

Example — Rate limiter: the L5 insight is distributed coordination. A single-node token bucket is easy; a cluster-wide rate limit requires either a centralized store (Redis with Lua script for atomic check-and-decrement) or approximate algorithms (each node gets a slice of the budget).

3.11. Common pitfalls

  1. Jumping to architecture without requirements. You’ll design the wrong system.

  2. Over-complicating. L5 isn’t measured by how many boxes you draw. A simple, well-justified design beats a Rube Goldberg machine.

  3. Name-dropping without understanding. "I’d use Kafka" — why? What’s it solving? If you can’t answer, don’t say it.

  4. Ignoring failure modes. For every component: what happens when it dies? At L5, failure thinking is expected.

  5. Not stating tradeoffs. Every choice has an alternative. Name it and say why you picked yours.

  6. Refusing to commit. "It depends" is fine once. Twice is pattern. Pick a direction.

  7. No capacity math. "It’ll scale" without numbers isn’t design, it’s hope.

  8. Missing the async path. Many designs need a queue + worker for anything expensive or unreliable; candidates who put it all synchronous in the request path miss a basic senior signal.

  9. Getting defensive when challenged. The interviewer will poke holes. Treat it as collaborative. "Good point — how about if we did X instead?" beats "No, my design handles that because…​"

3.12. Example walkthrough: "Design a URL shortener"

Compressed to show the shape:

Requirements (2 min):

  • Functional: shorten long URL to short code, redirect short → long, custom aliases optional, analytics optional.

  • Non-functional: 100M new URLs/month, 10B redirects/month, p99 redirect < 100ms, redirects are the dominant traffic.

  • Read:write ratio ≈ 100:1. Read-heavy.

Estimation (2 min):

  • Writes: 100M / 2.5M ≈ 40/sec, peak 100/sec.

  • Reads: 10B / 2.5M ≈ 4K/sec, peak 10K/sec.

  • Storage: 100M/month × 500 bytes/record × 12 × 5 years ≈ 3 TB.

API (1 min):

POST /shorten { url, custom_alias? } -> { short_code }
GET /:short_code -> 302 redirect

Data model:

URLs: short_code (PK), long_url, created_at, user_id, expires_at

High-level (5 min):

  1. Client → load balancer → app servers.

  2. App servers write new mappings to DB, read through a cache.

  3. Redirect path: hit cache, fall back to DB.

  4. Analytics writes go async through a queue to a separate pipeline.

Short code generation (the key design choice):

Three options:

  1. Hash of URL + collision handling: deterministic, but collisions require retry; different user submits same URL → same code.

  2. Random generation + check: check DB for collision, retry. Simple, but extra DB roundtrip.

  3. Counter-based, base-62 encoded: monotonic counter encoded to short string. No collisions. Needs distributed counter (ZooKeeper, or range-leasing: each app server gets a block of 10K IDs, uses them locally).

Pick option 3 with range-leasing. Justify: no collision logic, scales horizontally (each server has its own range), and the counter service only gets hit every 10K inserts.

Deep-dive topics ready:

  • Cache sizing: 20% of short codes get 80% of hits (power law). Cache the top ~20% in Redis with LRU.

  • DB choice: key-value is a great fit; could use DynamoDB or Cassandra. If analytics join needed, keep SQL with sharding by short_code hash.

  • Failure modes: counter service down → app servers have 10K-lease buffer, ride through. Cache down → DB gets hit directly, degraded latency but functional.

  • Abuse prevention: rate-limit creation per IP/account; scan for known-malicious URLs.

That’s a 45-minute interview compressed to a page. Spend real time on each of those phases.

4. Part 3: Three-day prep schedule

Given the timeline:

4.1. Day 1: Behavioral

  • Morning: write out 10-12 stories in STAR format. Target 1-2 pages each in notes.

  • Afternoon: practice telling them out loud, timed. Record yourself if possible.

  • Evening: Map each story to 3+ potential questions. Identify gaps — if you have no story for "a time you disagreed and were wrong," construct one from a real event.

4.2. Day 2: System design

  • Morning: pick 3 canonical problems from the list. Sketch each end-to-end on paper in 45 min.

  • Afternoon: pick 1 of them and do a deep dive on the hardest component.

  • Evening: review the building blocks section above. For anything you can’t explain in 2 minutes, re-read and try again.

4.3. Day 3: Integration and rest

  • Morning: one timed mock of each (behavioral 45 min, system design 45 min). Have someone else ask you questions if possible, or record yourself.

  • Afternoon: light review of your story bank and building-block cheat-sheet. Don’t learn anything new.

  • Evening: stop studying by 8 PM. Sleep matters more than the last 4 hours of prep.

5. Final checklist

Behavioral readiness:

  • 10+ stories prepared, each with specific metrics

  • At least one failure story, genuinely owned

  • At least one disagreement story where you changed your mind

  • 90-second "tell me about yourself" polished

  • 5+ thoughtful questions to ask the interviewer

  • Practiced "I" vs "we" discipline out loud

System design readiness:

  • Can do back-of-envelope math without a calculator

  • Know at least 6 canonical problems cold

  • Can explain: CAP, consistency models, sharding strategies, consensus, idempotency

  • Can compare SQL vs NoSQL for a given workload with specific reasoning

  • Can describe 2+ caching strategies and their invalidation tradeoffs

  • Have a personal time-budget for the 45 minutes and practiced sticking to it

  • Can draw a clean box-and-arrow diagram on a whiteboard or shared doc

Interview-day logistics:

  • Working camera, mic, reliable internet (for remote)

  • Scratch paper, pen, water

  • Google Doc or shared whiteboard link bookmarked

  • Resume in the same tab, in case you need to reference dates/numbers

  • Silent environment, phone off