Google System Design Interview: What to Expect at L5, L6, and L7

Google's system design interview is legendary for its difficulty. The bar is high, the questions are open-ended, and the interviewers are world-class engineers who've built systems serving billions of users.

But here's what most guides won't tell you: Google's system design interview isn't about getting the "right" answer. It's about demonstrating how you think.

I've talked to dozens of engineers who've passed Google's system design loop, analyzed their experiences, and identified the patterns that separate offers from rejections. This guide shares everything: the real questions asked, how you're evaluated at each level, and the specific mistakes that tank otherwise strong candidates.

---

How Google's Interview Process Works

Before we dive into system design specifically, let's understand the full picture.

The Interview Loop

Phone Screen (1 round)
        │
        ▼ (if pass)
On-site (4-5 rounds)
  ├── Coding (2 rounds)
  ├── System Design (1-2 rounds)
  └── Googleyness & Leadership (1 round)
        │
        ▼
Hiring Committee Review
        │
        ▼
Team Matching
        │
        ▼
Offer

Key insight: You need to pass each interview independently. One strong system design interview can't compensate for weak coding rounds. But one weak system design interview can sink an otherwise strong candidate.

System Design Round Count by Level

---

What Google Actually Evaluates

Google has a structured rubric for system design. Understanding it changes how you prepare.

The Four Dimensions

1. Problem Exploration (20%)

Can you scope and clarify before jumping to solutions?

2. System Architecture (30%)

Can you design a coherent system?

3. Technical Depth (30%)

Can you go deep on critical components?

4. Communication (20%)

Can you explain complex ideas clearly?

---

Level-Specific Expectations

The same question asked at L5 vs. L7 has very different expectations.

L5 (Senior Software Engineer)

What they expect:

• Design a complete system with reasonable architecture
• Go deep on 2-3 components when asked
• Identify obvious scaling challenges
• Make sensible technology choices with justification

What you don't need:

• Novel solutions to unsolved problems
• Designing for Google-scale edge cases
• Deep expertise in every component

Sample passing performance:

"For the database, I'd use PostgreSQL with read replicas. We need ACID guarantees for user data, and at our scale of 10M users, a properly indexed PostgreSQL with replication handles the load. If we hit scaling issues, we can shard by user_id later, but I'd avoid premature optimization."

L6 (Staff Software Engineer)

What they expect:

• Everything at L5, plus:
• Consider organizational impact of technical decisions
• Design for extensibility and long-term maintenance
• Identify risks and mitigation strategies
• Drive the interview more proactively

What separates L6 from L5:

• L5: "Here's how to build it"
• L6: "Here's how to build it, here's how it evolves over time, and here's how we organize teams around it"

Sample passing performance:

"This system has three natural service boundaries: ingestion, processing, and serving. I'd recommend separate teams own each, with well-defined APIs between them. The ingestion team can move fast without breaking processing, and we can scale teams independently as the system grows."

L7 (Senior Staff Software Engineer)

What they expect:

• Everything at L6, plus:
• Handle extreme ambiguity (problem might not be well-defined)
• Design systems that don't exist yet at Google
• Consider multi-year technical strategy
• Think about cross-team and cross-org impact

What separates L7 from L6:

• L6: "Here's the system design"
• L7: "Here's why we should build this system instead of these alternatives, here's the 3-year roadmap, and here's how it affects adjacent systems"

---

Real Google System Design Questions

These are actual questions asked in recent Google interviews, organized by theme.

Infrastructure & Platform

"Design Google Cloud Storage (GCS)"

Focus areas:

• Object storage at massive scale
• Consistency models (strong vs. eventual)
• Multi-region replication
• Durability guarantees (11 9s)
• Cost tiers (Standard, Nearline, Coldline, Archive)

Key discussions:

• How do you achieve 99.999999999% durability?
• How do you handle a data center going offline?
• How do you optimize for different access patterns?

"Design a distributed cron system"

Focus areas:

• Exactly-once execution guarantee
• Handling machine failures mid-job
• Time zones and DST edge cases
• Job dependencies and DAGs

Key discussions:

• What happens if the scheduler machine dies?
• How do you handle jobs that run longer than their interval?
• How do you scale to millions of scheduled jobs?

"Design a feature flag system"

Focus areas:

• Low-latency flag evaluation
• Gradual rollout (1%, 10%, 50%, 100%)
• User targeting and segmentation
• Flag lifecycle management

Key discussions:

• How do you ensure consistency across servers?
• How do you handle flag evaluation for logged-out users?
• How do you prevent flag debt from accumulating?

Data & Analytics

"Design Google Analytics"

Focus areas:

• Event ingestion at massive scale (billions/day)
• Real-time vs. batch processing
• Custom dimensions and metrics
• Query patterns for dashboards

Key discussions:

• How do you handle late-arriving data?
• How do you store data for fast aggregation queries?
• How do you ensure sampling is statistically valid?

"Design a system to detect trending topics"

Focus areas:

• Stream processing architecture
• Anomaly detection (what counts as "trending"?)
• Time windowing (trending now vs. today)
• Filtering spam/manipulation

Key discussions:

• How do you distinguish organic trends from coordinated campaigns?
• How do you handle different time zones?
• What's the latency from event to trending detection?

User-Facing Products

"Design Google Maps"

Focus areas:

• Map tile serving at global scale
• Routing algorithm (Dijkstra's, A*, Contraction Hierarchies)
• Real-time traffic integration
• Offline mode support

Key discussions:

• How do you update map data without regenerating all tiles?
• How do you handle routing through areas with no data?
• How do you incorporate live traffic into routes?

"Design YouTube"

Focus areas:

• Video upload and transcoding pipeline
• Content delivery network architecture
• Recommendation engine
• Live streaming support

Key discussions:

• How do you handle a video going viral (1M views in an hour)?
• How do you balance recommendation relevance vs. diversity?
• How do you detect and remove policy-violating content quickly?

"Design Google Search autocomplete"

Focus areas:

• Trie data structure (or alternatives)
• Personalization vs. global suggestions
• Handling multilingual queries
• Sub-100ms latency requirement

Key discussions:

• How do you rank suggestions (frequency? recency? personalization?)
• How do you filter inappropriate suggestions?
• How do you handle never-before-seen queries?

Google-Specific Questions

"Design a system to serve Google Doodles"

Focus areas:

• Global content delivery
• Time zone-aware serving
• Interactive doodle support
• A/B testing different doodles

Why this question:

• Tests CDN and caching knowledge
• Simple enough to go deep
• Google-specific, shows genuine interest

"Design Gmail's spam filter"

Focus areas:

• ML model serving at scale
• Feature extraction from emails
• Feedback loops (user marks as spam/not spam)
• Adversarial robustness

Key discussions:

• How do you retrain models without disrupting production?
• How do you handle new spam patterns?
• How do you balance false positives vs. false negatives?

---

The 45-Minute Framework

Here's how to structure your Google system design interview:

Minutes 0-5: Problem Exploration

Do:

• Clarify the scope ("Are we designing all of YouTube or just video upload?")
• Establish scale ("How many users? How many requests per second?")
• Identify key metrics ("Are we optimizing for latency, throughput, or cost?")
• Prioritize features ("What's the MVP vs. nice-to-have?")

Say:

"Before I dive in, I'd like to clarify a few things. First, what scale are we targeting, is this for thousands of users or billions? And what's the primary metric we're optimizing for, latency, availability, or cost?"

Minutes 5-15: High-Level Design

Do:

• Draw the major components
• Show the request flow (how does a user request travel through the system?)
• Identify data stores and their purpose
• Define APIs between components

Say:

"Let me sketch out the high-level architecture. We'll have three main components: [X, Y, Z]. Here's how a typical request flows through the system..."

Minutes 15-35: Deep Dive

Do:

• Pick 2-3 components to explore in depth
• Discuss data models and schemas
• Explain algorithms and trade-offs
• Address failure scenarios

Say:

"I'd like to go deeper on the [X] component since it's the most critical for our latency requirements. Let me walk through the data model first..."

Important: Let the interviewer guide some of this. If they want you to go deeper on caching, pivot to caching. If they want to talk about consistency, go there.

Minutes 35-45: Scaling & Trade-offs

Do:

• Identify bottlenecks as scale increases
• Discuss what you'd change for 10x scale
• Acknowledge alternatives you considered
• Mention monitoring and operational concerns

Say:

"At our current scale, this design works well. If we need to 10x, the main bottleneck would be [X]. I'd address that by [Y]. An alternative approach would be [Z], but I chose this because..."

---

Common Mistakes That Tank Google Interviews

Mistake 1: Not Clarifying Requirements

What happens:

Interviewer: "Design a notification system" Candidate: "OK, we'll use Firebase Cloud Messaging and..."

Why it fails: You might spend 30 minutes designing the wrong thing. Maybe they wanted email notifications, not push. Maybe they wanted a B2B system, not consumer.

Fix: Spend 3-5 minutes asking questions. What channels? What scale? What latency requirements? What's the trigger for notifications?

Mistake 2: Going Wide Instead of Deep

What happens:

Candidate mentions databases, caching, load balancers, message queues, CDNs, monitoring, logging, CI/CD, Kubernetes, service mesh...

Why it fails: Breadth without depth shows you've read blog posts but can't actually build systems. Google wants to see you can go deep.

Fix: Pick 2-3 components and explain them thoroughly. Show you understand the implementation details, not just the buzzwords.

Mistake 3: Not Explaining Trade-offs

What happens:

Candidate: "For the database, I'll use Cassandra." Interviewer: "Why Cassandra?" Candidate: "It's good for scale."

Why it fails: "It's good for scale" isn't a trade-off analysis. What did you give up by choosing Cassandra? What would you have gained with PostgreSQL?

Fix: Always frame decisions as trade-offs. "I chose Cassandra over PostgreSQL because we need high write throughput and can tolerate eventual consistency. If we needed strong consistency for financial transactions, I'd choose differently."

Mistake 4: Ignoring Failure Scenarios

What happens:

Candidate designs the happy path perfectly but doesn't discuss what happens when things fail.

Why it fails: At Google scale, failures are constant. Every machine will fail. Every network will partition. Designing only for success shows inexperience.

Fix: Proactively discuss: "What happens if this service goes down? How do we handle data center failures? What's the blast radius of a bad deploy?"

Mistake 5: Not Engaging with the Interviewer

What happens:

Candidate gives a 20-minute monologue without checking in or responding to interviewer cues.

Why it fails: System design interviews are collaborative. The interviewer has areas they want to explore. Ignoring them means missing chances to shine.

Fix: Check in every 5-7 minutes. "Does this make sense so far? Should I go deeper here or move on?" Watch for nonverbal cues, if they look confused or disengaged, pause and ask.

---

Google-Specific Tips

1. Know Google's Technology Stack

You don't need to use Google's internal tools, but showing awareness helps:

Example: "For the message queue, I'd use Kafka, or if this were internal at Google, something like Pub/Sub. The key requirement is durable, ordered message delivery..."

2. Think About Google Scale

Google numbers are different from typical companies:

• YouTube: 500 hours of video uploaded per minute
• Gmail: 1.8 billion users
• Search: 8.5 billion searches per day
• Maps: 1 billion monthly users

When designing, think about what breaks at these scales. Your "simple" design that works for 1 million users might completely fail at 1 billion.

3. Reference Google's Published Systems

Google has published papers on many of their systems. Referencing them shows you've done your homework:

• Bigtable , Wide-column store
• Spanner , Globally distributed SQL
• MapReduce , Batch processing paradigm
• GFS , Distributed file system
• Borg , Container orchestration
• Chubby , Distributed lock service

Example: "For distributed consensus, I'd use something like Chubby or ZooKeeper. Google's Chubby paper describes how they handle leader election with Paxos..."

4. Show Intellectual Curiosity

Google values engineers who are genuinely curious about hard problems. This comes through in how you discuss trade-offs:

Good: "I'm not sure if eventual consistency is acceptable here. It depends on whether users ever see their own writes immediately, that's something I'd want to validate with user research."

Less good: "We'll use eventual consistency because it's faster."

---

Preparation Timeline

If You Have 4 Weeks

Week 1: Fundamentals

• Databases (SQL vs. NoSQL, sharding, replication)
• Caching (strategies, invalidation)
• Message queues (Kafka, SQS, Pub/Sub)
• Load balancing and scaling

Week 2: Core Questions

• Design URL shortener
• Design Twitter
• Design WhatsApp
• Design rate limiter

Week 3: Google-Specific

• Design Google Drive
• Design YouTube
• Design Google Maps
• Read Google's published papers (Bigtable, Spanner, MapReduce)

Week 4: Mock Interviews

• 3-4 mock interviews with peers or platforms
• Focus on communication, not just technical correctness
• Practice the 45-minute framework

If You Have 2 Weeks

Week 1: Fundamentals + Core Questions

• Days 1-2: Database, caching, messaging fundamentals
• Days 3-4: URL shortener, Twitter deep dives
• Days 5-7: WhatsApp, YouTube overviews

Week 2: Practice

• Days 1-2: Google-specific questions
• Days 3-4: Mock interviews
• Days 5-7: Review and rest

If You Have 1 Week

• Days 1-2: Core concepts (caching, databases, scaling)
• Days 3-4: Two deep-dive problems (URL shortener, Twitter)
• Days 5-6: Two mock interviews
• Day 7: Rest and light review

---

Interview Day Checklist

Before the Interview

• Test your video/audio (if remote)
• Have paper and pen ready for diagramming
• Review your notes on key systems
• Get a good night's sleep
• Eat well, stay hydrated

During the Interview

• Take a breath before starting
• Clarify requirements (3-5 minutes)
• State assumptions explicitly
• Draw diagrams as you explain
• Check in with the interviewer regularly
• Discuss trade-offs proactively
• If stuck, verbalize your thinking
• Ask for hints if needed, it's better than floundering

After the Interview

• Write down the question (helps for future prep)
• Note what went well and what didn't
• Don't obsess, you can't change it now

---

Final Thoughts

Google's system design interview is challenging, but it's not mysterious. They're looking for:

1. Problem solvers who clarify before coding
2. System thinkers who see the big picture
3. Technical depth in core areas
4. Clear communicators who can explain complex ideas

The engineers who pass aren't necessarily smarter or more experienced. They're better prepared, they know what's expected, they've practiced under realistic conditions, and they've learned to think out loud.

You can do this. Prepare systematically, practice with feedback, and trust the process.

Good luck.

---