Meta System Design Interview: What the Bar Actually Tests at Each Level
- The Meta system design interview appears in the phone screen and onsite, with a second design round added at E6.
- E4 focuses on breadth: coherent component decomposition, clean data flow, and reasoning through the happy path.
- E5 requires quantitative depth: size infrastructure with rough math, identify real bottlenecks, and explain cache eviction and failure modes.
- E6 adds low-level internals: design Redis or Kafka from scratch, and show architectural scope that spans multiple teams.
- The fan-out problem (pure push vs. pull vs. hybrid per-account) appears in roughly a third of Meta design rounds and is the highest-ROI topic to master first.
- Technical communication is the most-missed dimension: disorganized delivery consistently scores lower than clear reasoning with less depth.
- Meta follows up on every technology you name; dropping Kafka or Cassandra without explaining failure modes drops your score.
Meta's system design round has three jobs. It's a gate. It's a leveling tool. And it's a trap for anyone who walks in thinking it's just "draw some boxes and talk about trade-offs."
All three jobs. Forty-five minutes. One interviewer who is actively writing things down about you.
A strong performance can push you from E4 to E5. A weak one can sink an otherwise solid loop. At E6, you might face two design rounds, not one. This guide covers where the round appears, how the bar shifts from E4 to E6, what questions come up, how you're scored, and what prep actually moves the needle.
Where System Design Lives in the Meta Loop
The pipeline runs: online assessment (CodeSignal) → recruiter screen → phone screen → onsite → team match → offer. System design appears twice.
The phone screen design round is a gate. Fail it and you don't reach the onsite. Pass it and you'll get at least one more design round there, sometimes two if you're targeting E6.
| Round | Format | Duration |
|---|---|---|
| Phone screen: system design | CoderPad, open-ended prompt | 45 min |
| Onsite: system design | CoderPad or virtual whiteboard | 45 min |
| Onsite: second system design (E6+) | CoderPad or virtual whiteboard | 45 min |
The onsite also includes two coding rounds (Meta started piloting an AI-assisted format in late 2025), one behavioral round, and sometimes a domain-specific round for specialized roles.
The 45-Minute Structure (You're Driving)
Every design round at Meta follows the same shape. You get an open-ended prompt. You drive.
- 0 to 5 min: clarify requirements. Functional scope, non-functional constraints, scale, consistency expectations.
- 5 to 15 min: high-level architecture. Draw the main components and explain how data flows between them.
- 15 to 35 min: deep dive. The interviewer steers you toward what they want to stress-test: storage schema, fan-out mechanics, failure handling, caching strategy.
- 35 to 45 min: trade-offs and follow-ups. Why this approach over alternatives. What breaks first under load.
You are expected to drive all of this. Meta interviewers don't lecture. They probe. Wait to be guided and you'll run out of time before showing the depth needed to level well.
"You drive" is not polite framing. At Meta, silence reads as uncertainty. The interviewer is not waiting off-screen to swoop in and rescue you with a hint. They are writing down "long pauses, needed prompting to move forward."
How the Bar Shifts: E4 vs E5 vs E6
| Level | Design rounds | Expected depth | Common question type |
|---|---|---|---|
| E4 (SWE) | 1 | High-level, clean architecture, basic trade-offs | Product-scale (Design Instagram) |
| E5 (Senior) | 1 | Bottleneck identification, fault tolerance, data modeling | Product-scale with quantitative reasoning |
| E6 (Staff) | 2 | Low-level internals, cross-system architecture, multi-team scope | Low-level (Design Redis, Design Kafka) |
For E4, breadth matters most. Can you decompose a system into components, draw a coherent diagram, and explain the happy path? Nobody expects you to derive the optimal fan-out threshold for a billion-user newsfeed from scratch. The bar is: do you think in systems, not just in functions?
For E5, depth is required. Quantify your scale estimates. Reason about consistency versus availability trade-offs. Explain how your storage layer handles hot keys and identify what breaks first. "Use a cache" without discussing eviction policy, invalidation strategy, and failure behavior is an E4 answer in an E5 round. Interviewers won't pause the clock to tell you this.
For E6, the question type changes. Low-level internals become common: design the data structure behind a key-value store, design a write-ahead log, design a message broker from scratch. You're also expected to show architectural scope that spans teams, not just services. Down-leveling from E6 to E5 is common when candidates show product design depth but can't go deep on distributed systems primitives.
"Design Kafka" is a real question. Meta is not being ironic.
What Meta Actually Asks
Meta's design questions map to products the company actually builds. Real constraints at real scale.
| Question | Key challenge |
|---|---|
| Design the Facebook News Feed | Fan-out-on-write vs. pull, ranking service, celebrity accounts |
| Design Facebook Messenger | WebSocket management, message ordering, read receipts at scale |
| Design Instagram | Media storage and CDN, feed generation, Stories TTL |
| Design Search Autocomplete | Trie or inverted index, prefix compression, personalization |
| Design a Web Crawler | Politeness policies, dedup, distributed scheduling |
| Design a Notification System | Push vs. pull, multi-channel delivery, deduplication |
| Design a Rate Limiter | Token bucket vs. sliding window, Redis Lua atomicity |
| Design Redis (E6) | In-memory data structures, persistence (RDB/AOF), replication |
| Design Kafka (E6) | Log segments, consumer groups, offset management, partitioning |
The newsfeed question comes up most often, including in phone screens. Every interesting distributed systems problem lives inside it: fan-out, caching, ranking, real-time delivery, and storage at scale. Design a newsfeed well and you can reason about most of the other problems on that list.
The Four Things You're Actually Scored On
Meta system design interviews evaluate four dimensions. Every interviewer has a scorecard that maps to these.
Problem navigation. Did you ask the right clarifying questions? Did you set scope before drawing boxes? Candidates who jump straight to architecture before understanding access patterns or consistency requirements lose points here even if their final design is correct. "Let me start with requirements" is not just ritual. It's a scored signal.
Solution design. Is your architecture coherent? Do the components fit together logically? Can you explain data flow end to end without contradicting yourself?
Technical excellence. This is where scale lives. Does your design hold up at a billion users? Did you identify the actual bottlenecks (usually writes at the storage layer, fan-out in the delivery layer) rather than generic ones? Can you size your infrastructure with rough math?
Technical communication. The most underrated dimension. The single biggest predictor of failure in Meta system design isn't missing knowledge. It's disorganized delivery. Candidates who know the right concepts but present them in a scattered, non-linear way routinely score lower than candidates with less depth who communicate clearly. Think out loud. Say "the trade-off here is X because Y" explicitly. Don't make the interviewer assemble your reasoning from a pile of correct but disconnected observations.
For how interviewers translate this into written feedback, see System Design Interview: What to Expect, How It's Scored, and How to Stand Out.
The Fan-Out Problem (Why It Keeps Coming Up)
If you understand fan-out well, you can answer a third of Meta's design questions. Understand fan-out well.
The setup: a user with 10 million followers posts something. Your feed service needs to deliver that post to their followers. Two approaches:
Fan-out on write (push model): pre-compute and write the post to every follower's feed cache when it's created. Reads are O(1). Writes are O(followers). For a celebrity with 10 million followers, one post creates 10 million write operations. That's a lot of database pressure so one person can share a photo of their lunch.
Fan-out on read (pull model): when a user loads their feed, query each followee's recent posts and merge. Writes are cheap. Reads are expensive. At Facebook's scale, feed loading becomes slow for users following many accounts.
The hybrid: Meta pre-computes feeds for most users and stores them in Redis. Accounts above a follower threshold (often around 10,000) use fan-out-on-read. The feed service knows which tier a given followee falls into and applies the right strategy per account in the merge step.
Understanding this, and explaining why neither pure approach works at Meta's scale, is what earns depth credit. See Twitter News Feed System Design: Fan-Out, Celebrities, and the Hybrid Fix for the same pattern at Twitter/X.
Mistakes That Drop Your Score
Jumping to components before clarifying scope. Starting with "so we'll have a load balancer, then application servers, then a database" before asking about scale or consistency requirements signals you're reciting a template, not reasoning about the problem. Everyone can tell. The interviewer went to a top engineering school too.
Using buzzwords without depth. Naming Kafka, Cassandra, and Redis in the first five minutes is fine if you can explain why you chose each and what their failure modes look like. Meta interviewers follow up on every technology you name. Mention Cassandra and you should be ready to explain what W=QUORUM means under partition.
Going deep before going broad. Some candidates spend 20 minutes on one component before they've shown the rest of the system. End-to-end architecture comes first. The interviewer doesn't know yet whether your deep dive is insight or avoidance.
Ignoring non-functional requirements. Latency targets, consistency guarantees, availability SLAs, durability requirements. If you don't surface them early, your design choices look arbitrary. They're not arbitrary. They're just unexplained, which reads the same way.
Staying vague on data modeling. Know how you'd represent a graph edge in a social network, why you'd choose Cassandra over MySQL for a time-series workload, and how you'd handle schema evolution. Meta interviewers dig into schema decisions. "I'd figure out the schema later" is not an answer at any level.
For messaging-specific pitfalls, see Design a Chat App Like WhatsApp: The System Design Walkthrough.
How to Prepare
E4 (four to six weeks): Work through five to eight design problems end to end. Practice saying your design out loud, not just drawing it. Focus on news feed, URL shortener, notification system, search autocomplete. Learn the fan-out problem. Build intuition for SQL versus NoSQL trade-offs.
E5 (six to eight weeks): Add quantitative estimation. Size every design with rough math: QPS, storage per day, bandwidth. Understand consistent hashing, CAP theorem, and the key trade-offs in distributed databases. SpaceComplexity runs voice-based mock interviews that simulate talking through a design under real pressure, which is exactly the skill that separates E4 answers from E5 answers. You can't develop it by reading.
E6 (eight to twelve weeks): Add low-level questions to your rotation. Design Redis. Design a message queue from scratch. Read the original BigTable and Dynamo papers. The interviewer at E6 expects opinions about internals, not just component selection. "I'd use write-ahead logging for durability" lands differently than "I'd use write-ahead logging because it batches writes to an append-only log, keeps the in-memory state authoritative, and lets us replay on crash without a full checkpoint."
The gap between those two answers is the gap between E5 and E6.