💰

Money Moves

Use AI to uncover financial tricks most people never find — hidden card perks, fee waivers, and legal loopholes explained in plain language.

Explore Money Moves →
⚡ Staff Engineer Level

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.

5
Companies covered
2
Design rounds at L6+
L6/L7
Staff & Principal level

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

Designs a single service correctly
Names trade-offs without justifying them
Stays in the “design” lane — no ops, cost, or evolution
Responds to constraints given by interviewer
Handles one failure mode at a time
Optimises for the happy path

Staff (L6) answer

Designs a platform that hosts many services
Explains why the trade-off was right for this team, this quarter
Addresses operations, cost, and 2-year evolution
Scopes the problem and identifies what matters most
Discusses cascading failures and recovery strategies
Identifies the hardest problem and goes deep on it

Staff-level system design framework — 45 min structure

1

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.

2

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.

3

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.

4

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.

5

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.

6

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

2 design rounds L6 = Staff Failing either = no hire

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

1
Design Google Docs — real-time collaborative editing with offline support and merge conflict resolution
Hard

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?

CRDTs / OT WebSockets Offline sync Conflict resolution Eventual consistency
2
Design YouTube’s video ingestion, processing, and delivery pipeline at global scale
Hard

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.

Distributed transcoding CDN strategy Adaptive bitrate Object storage Viral traffic spikes
3
Design a distributed rate limiter that works across thousands of microservices with sub-millisecond latency
Hard

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.

Token bucket Sliding window Redis cluster Clock skew Distributed coordination
4
Design Google Search’s web crawler and indexing pipeline for 10 billion pages
Hard

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.

Distributed crawling URL frontier Near-duplicate detection Inverted index Incremental updates

💡 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.

Meta — E6 System Design

Staff Software Engineer · 2 mandatory design rounds · Product Architecture + System Design tracks

2 design rounds E6 = Staff AI-assisted interviews (2025)

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

1
Design Facebook’s News Feed — ranking, personalisation, and real-time updates at 3 billion users
Hard

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).

Fan-out on write/read ML ranking serving Celebrity problem Real-time updates Cache invalidation
2
Design WhatsApp — end-to-end encrypted messaging at 2 billion users with offline delivery guarantees
Hard

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?

E2E encryption Message queuing Delivery receipts Offline storage WebSocket management
3
Design Instagram’s photo/video storage and delivery infrastructure
Medium-Hard

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.

Object storage Content deduplication CDN strategy Storage tiering Transcoding pipeline

💡 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.

Amazon — L6/L7 System Design

Principal SWE (L7) · “The Loop” on-site · Leadership Principles woven into every round

1–2 design rounds L6/L7 = Staff/Principal LP required in every answer

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

1
Design Amazon’s payments infrastructure to support expansion into a new market
Hard

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.

Idempotency Distributed transactions Fraud detection Regulatory compliance Multi-currency
2
Design a distributed job scheduler with exactly-once execution guarantees
Hard

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?

Exactly-once execution Distributed locks Fault tolerance Job prioritisation Dead letter handling
3
Design Amazon’s recommendation engine — from model training to real-time serving to A/B testing
Hard

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?

Feature store Model serving A/B testing infrastructure Real-time features Feedback loops

📋 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.

Apple — ICT5/ICT6 System Design

Staff Engineer equivalent · Privacy-first design · Hardware-software integration emphasis

1–2 design rounds ICT5/6 = Staff Privacy is non-negotiable

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

1
Design iCloud sync — seamless file synchronisation across all Apple devices with privacy guarantees
Hard

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.

E2E encryption Vector clocks Conflict resolution Delta sync On-device processing
2
Design Siri’s on-device NLP pipeline with a privacy-preserving cloud fallback
Hard

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).

On-device ML Model quantisation Differential privacy Private Cloud Compute TEE/Secure enclave
3
Design Apple Pay — secure contactless payments with privacy preservation
Medium-Hard

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.

Tokenisation Secure Element NFC protocol Biometric auth Zero knowledge

💡 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.

Microsoft — L65/L67 System Design

Principal Engineer · Azure-first thinking · AI/Copilot integration a growing focus

1–2 design rounds L65/67 = Staff/Principal Growth mindset culture

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

1
Design Microsoft Teams — real-time messaging, video calls, and presence at enterprise scale
Hard

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).

Presence system WebRTC/WebSocket Message archival Enterprise compliance Multi-tenant isolation
2
Design GitHub Copilot’s backend — code completion inference at developer latency requirements
Hard

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.

LLM inference Speculative decoding KV cache Model routing Code privacy
3
Design Azure’s multi-tenant SaaS platform — isolation, resource limits, and fair scheduling
Medium-Hard

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.

Tenant isolation Noisy neighbour Resource quotas Burst capacity Metering/billing

💡 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.