System Design
Interview Guide
A deep guide for Staff SWE (L6/L7) candidates at Google, Meta, Amazon, Apple, and Microsoft. What they actually test, how to think at staff level, and the questions most likely to appear in your loop.
The mindset shift
L5 designs a service.
L6 designs a platform.
At Staff level, the question isn’t “can you build this?” — it’s “can you make decisions that shape what an entire team builds for the next 18 months?” The design space changes fundamentally. Interviewers want to see architectural judgment, not just technical knowledge.
What separates L5 from L6 answers on the same question
Senior (L5) answer
Staff (L6) answer
Staff-level system design framework — 45 min structure
Clarify & scope (5 min)
Don’t rush to design. Ask about scale, consistency requirements, latency SLAs, and business constraints. At L6, YOU decide what to scope in and out — don’t wait to be told. State your assumptions explicitly.
Identify the hardest problem (3 min)
State out loud which dimension of this problem is hardest — consistency, scale, latency, or reliability. This is what separates L6. Don’t try to cover everything — go deep on what matters.
High-level design (10 min)
Draw the core components. API layer, services, storage, async processing. Keep it simple. Interviewers want to see your mental model, not a perfect diagram. Narrate your thinking as you draw.
Deep dive on the hardest part (15 min)
Go deep on the dimension you identified in step 2. Use numbers. “At 1M QPS, a single Postgres instance won’t work — here’s why and here’s how I’d shard.” Interviewers will follow your lead here.
Failure modes & operations (7 min)
What breaks first? How does the system degrade gracefully? What are your SLOs and how do you monitor them? At L6, this section is required — skipping it is an automatic downlevel signal.
Evolution & trade-offs (5 min)
How does this design change in 2 years? What would you do differently with 10x the scale? What did you deliberately not build and why? This shows staff-level thinking about platforms, not just systems.
Topics every Staff candidate must know cold
Distributed storage
Consistent hashing, sharding strategies, replication lag, read replicas, CQRS, event sourcing, LSM trees vs B-trees.
Consistency models
CAP theorem in practice, eventual vs strong consistency, linearizability, CRDTs for conflict resolution, Raft/Paxos basics.
Async & messaging
Kafka partitioning, consumer groups, exactly-once delivery, backpressure, dead letter queues, saga pattern for distributed transactions.
Back-of-envelope math
QPS calculations, storage estimates, bandwidth requirements, cache hit rates. Be fluent — do it in your head, narrate out loud.
Multi-region & geo
Active-active vs active-passive, data residency requirements, cross-region replication lag, global load balancing, CDN strategies.
Observability
SLOs vs SLAs vs SLIs, error budgets, distributed tracing, structured logging, anomaly detection, on-call runbooks. Required at L6.
Cost & efficiency
Storage tiering, compute cost trade-offs, egress costs, spot vs on-demand, right-sizing. Staff engineers are expected to own cost.
Security & auth
AuthN vs AuthZ, OAuth 2.0 / OIDC, zero-trust architecture, secret management, encryption at rest vs in transit, rate limiting.
✦ Practice with Claude
Run a mock system design interview
Click any prompt to open Claude with a staff-level mock interview ready to go.
Google — L6 System Design
Staff Software Engineer · 2 mandatory design rounds · Most technically rigorous of FAANG
Format
5–6 round loop: Google Hiring Assessment (GHA) → 2 coding → 2 system design → Googliness/behavioral. Some loops include Role-Related Knowledge (RRK).
Design round duration
60 minutes each. Expect the interviewer to go very deep very fast on one specific dimension.
What’s different
Google operates at planetary scale. Numbers like billions of users, petabytes of data, and millions of QPS change the design space. Know your distributed systems cold.
2025/2026 change
Google reintroduced in-person rounds at Bay Area, Seattle, NYC, and Bangalore — 2 virtual + 3–4 in-person — to counter AI-assisted cheating.
What Google L6 interviewers evaluate
Architectural judgment
Can you identify the core technical risk in the problem and design around it? Interviewers go deep fast — they want to see your limits.
Quantitative reasoning
Do your numbers make sense? Google expects you to estimate QPS, storage, and bandwidth in your head and use them to justify design decisions.
Handling ambiguity
L6 questions come with conflicting business priorities. You choose which to honour. Don’t wait for the interviewer to narrow the scope.
Platform thinking
Design for extensibility — other teams will build on your system. Show you’re thinking about APIs, SLOs, and long-term maintainability.
Likely questions at L6
The core challenge is operational transformation (OT) or CRDTs for conflict-free merges. At L6, go deep on the sync protocol — how does a client reconnect after being offline for 3 days? How do you handle edits that conflict at the character level?
Go deep on the transcoding pipeline — parallelisation, codec selection, adaptive bitrate streaming (DASH/HLS). At L6, discuss CDN strategy, cache warming for viral videos, and how to handle a video that gets 10M views in the first hour.
The key tension is accuracy vs latency. Centralised counters are accurate but slow. Local counters are fast but allow overage. At L6, discuss the token bucket vs sliding window algorithms, Redis cluster strategies, and how to handle clock skew across datacenters.
Go deep on the politeness protocol — how do you avoid overloading small websites while crawling at massive scale? At L6, discuss the URL frontier prioritisation, duplicate detection via SimHash/MinHash, and the incremental indexing problem for frequently updated pages.
💡 Google-specific tip: Go deep, not broad
Google interviewers are comfortable going very deep very fast on a specific dimension. If you try to cover everything at 30,000 feet, you’ll get probed until you run out of depth. Pick the hardest part of the problem and go deep first — let the interviewer pull you to other areas.
✦ Practice with Claude
Meta — E6 System Design
Staff Software Engineer · 2 mandatory design rounds · Product Architecture + System Design tracks
Format
2 coding rounds + 2 design rounds + 1 behavioral. For E6+, both design rounds are mandatory — failing either blocks the hire.
Two design tracks
Infrastructure engineers get “System Design.” Product engineers get “Product Architecture” — includes UX considerations alongside technical design.
2025 change: AI interviews
Meta now uses AI-assisted coding interviews where you use an integrated AI tool. They evaluate how well you collaborate with AI — prompt effectively and review output critically.
Anti-cheating
Candidates must share their entire screen with background blur disabled. Meta is the strictest about this across FAANG.
What Meta E6 interviewers evaluate
Speed & scale intuition
Meta moves fast. Show you can design systems that ship quickly and scale — not just systems that are theoretically perfect.
Product thinking
Meta expects engineers to think about user impact. Your design decisions should connect to product outcomes, not just technical metrics.
Iteration mindset
Start simple, then evolve. Meta values engineers who can ship v1 quickly and improve iteratively — not overengineered v1s that take 6 months.
AI collaboration (2025)
Demonstrate you can work effectively with AI tools — know when to trust AI output, when to verify it, and when to override it.
Likely questions at E6
At E6, don’t just describe a fan-out architecture. Go deep on the ranking model serving infrastructure — how do you serve personalised ML rankings at 3B users with <100ms p99 latency? Discuss the push vs pull trade-off for different user types (celebrities vs regular users).
Go deep on the message delivery guarantee model — at-most-once vs at-least-once vs exactly-once. At E6, discuss the Signal Protocol for E2E encryption and how key distribution works at scale. How do you handle a user who’s offline for 30 days?
Focus on the Haystack object storage system (Meta’s real solution). At E6, go beyond “use S3” — discuss content-addressable storage, deduplication, CDN strategy for different content types (profile pics vs Reels), and storage cost optimisation through tiering.
💡 Meta-specific tip: Ship fast, then scale
Meta’s culture is “move fast.” In your design, explicitly acknowledge what you’d cut for v1 to ship in 3 months, and what you’d add in v2. This shows E6-level judgment about what actually matters vs what’s nice to have. Overengineering v1 is a red flag at Meta.
✦ Practice with Claude
Amazon — L6/L7 System Design
Principal SWE (L7) · “The Loop” on-site · Leadership Principles woven into every round
Format — “The Loop”
45–60 min rounds: 1–2 system design + coding + behavioral + Bar Raiser. The Bar Raiser is a senior employee from another team who can veto the hire.
Leadership Principles
Amazon’s 16 LPs permeate every interview including system design. Frame design decisions using LP language — “Customer Obsession” for UX, “Operational Excellence” for monitoring.
L7 difference
L7 questions are intentionally broad and under-specified. You’re expected to scope the problem, identify the most important dimensions, and lead the conversation — not respond to it.
Two tracks
Infrastructure engineers get “System Design.” Product engineers get “Product Architecture” that includes UX considerations alongside technical design.
Likely questions at L6/L7
A genuine breadth question touching currency handling, regulatory compliance, fraud detection, latency, and reliability. At L7, identify which of these is the hardest problem and go deep on it — don’t cover all five shallowly. Frame decisions using Leadership Principles: “Customer Obsession” for fraud UX, “Operational Excellence” for payment retries.
Amazon will probe what happens when a job is partially executed and a worker crashes. At L6, go deep on exactly-once semantics — idempotent job design, distributed locks via ZooKeeper/DynamoDB, and the at-least-once vs exactly-once trade-off. How do you handle a job that’s been running for 6 hours when the worker dies?
At L6, think about the full loop: offline training → feature store → real-time serving → A/B testing → feedback loop. The hardest part is the feature store — how do you serve freshly-computed features (last purchase 5 minutes ago) at millisecond latency with 100% freshness?
📋 Amazon Leadership Principles in system design
Explicitly reference LPs when justifying design decisions. “I’m choosing to prioritise consistency over availability here because our customers trust us with their payments — Customer Obsession.” “I’m adding detailed logging and alerting because we need to own our operational metrics — Operational Excellence.” Interviewers are trained to look for this.
✦ Practice with Claude
Apple — ICT5/ICT6 System Design
Staff Engineer equivalent · Privacy-first design · Hardware-software integration emphasis
Format
Team-specific loop of 5–7 rounds across multiple days. Often includes a hiring manager screen + multiple peer interviews + skip-level. Less standardised than other FAANG.
What’s different
Apple is the most team-specific of FAANG. The interview style, questions, and evaluation criteria vary significantly by team (Siri, iCloud, Maps, Payments, etc.).
Privacy-first
Apple’s design philosophy requires on-device processing where possible, differential privacy, and minimal data collection. Your designs must reflect this.
Hardware integration
Apple expects engineers to understand hardware constraints — memory, battery, thermal limits. Designs that ignore device constraints will be downleveled.
Likely questions at ICT5/ICT6
The core challenge is conflict resolution with end-to-end encryption — Apple can’t see your files, so the server can’t resolve conflicts. At ICT6, go deep on vector clocks for conflict detection, and how you do deduplication when you can’t read the content. Also discuss the bandwidth optimisation for mobile clients with limited data plans.
Apple’s on-device ML is a core differentiator. At ICT6, discuss model quantisation for on-device inference, the latency vs accuracy trade-off between on-device and cloud models, and how to use Private Cloud Compute — Apple’s privacy-preserving cloud inference using TEEs (Trusted Execution Environments).
Apple Pay uses device account numbers (DANs) — Apple never sends your actual card number to the merchant. At ICT6, go deep on the tokenisation scheme, the Secure Element on the device, and how the NFC transaction flow works with biometric authentication. Privacy constraint: Apple doesn’t track what you buy.
💡 Apple-specific tip: Privacy is a design constraint, not an afterthought
At Apple, privacy isn’t something you add at the end — it’s a first-class design constraint like latency or scale. For every component you design, ask: “What data does this collect? Can we avoid collecting it? Can we process it on-device instead?” Interviewers will be impressed if you raise privacy concerns before they do.
✦ Practice with Claude
Microsoft — L65/L67 System Design
Principal Engineer · Azure-first thinking · AI/Copilot integration a growing focus
Format
4–5 rounds: system design + coding + behavioral. Less standardised than Google/Meta — varies significantly by team (Azure, Office, Xbox, GitHub, AI).
Azure-first
Microsoft expects Azure-native thinking. Know the Azure service equivalents: Event Hub (Kafka), Cosmos DB (DynamoDB), Service Bus (SQS), ADLS (S3).
Growth mindset
Satya Nadella’s culture shift means interviewers want to see intellectual curiosity and willingness to be wrong. Changing your design mid-interview based on feedback is valued, not penalised.
AI/Copilot focus (2025)
Many teams are building AI-native features. Expect questions about LLM integration, RAG architectures, and how to build reliable AI-assisted systems.
Likely questions at L65/L67
The core challenge is the presence system at scale — knowing if 300M users are online/offline/in-a-meeting in real time. At L65, go deep on the WebSocket connection management, presence heartbeat optimisation, and how you handle enterprise compliance requirements (message archival, eDiscovery, data residency).
This is about LLM inference at scale with very tight latency constraints (<200ms for inline suggestions). At L65, discuss speculative decoding, KV cache sharing across requests, and the routing strategy for different model sizes (small model for fast suggestions vs large model for complex completions). Also discuss the privacy challenge — code is sensitive IP.
Multi-tenancy is the defining challenge in Azure. At L65, go deep on tenant isolation levels (shared infrastructure vs dedicated), noisy neighbour prevention, resource quota enforcement, and how you handle a tenant that suddenly needs 100x their normal resources (burst capacity). Discuss the billing and metering infrastructure too.
💡 Microsoft-specific tip: Think in Azure services
When you say “message queue,” say “Azure Service Bus or Event Hub depending on whether we need ordering.” When you say “object storage,” say “Azure Blob Storage.” This shows you understand Microsoft’s ecosystem and are thinking practically about what your team would actually build on. Interviewers appreciate Azure-native thinking at Principal level.
✦ Practice with Claude