The short answer: a system design interview gives you a broad problem, such as “design a messaging backend,” and about 45 minutes to design a system for it while talking it through with the interviewer. There’s no single right answer. Interviewers judge how you clarify requirements, structure the design, go deep on the hard parts, and reason about trade-offs. Prepare by learning the core building blocks (databases, caches, queues, load balancers), practicing a repeatable framework out loud on common problems, and reviewing systems you’ve built. Below is what companies say they look for, a six-step framework with a worked example, the concepts to know, common questions, and how to use AI to practice.
What interviewers look for
Meta’s guide for software engineering candidates describes the design interview as 45 minutes that “almost never involve coding.” Instead, “you’ll spend the interview talking and drawing on the whiteboard.” Its purpose is to assess “the candidate’s ability to solve a non-trivial engineering design problem.” Meta’s tips:
- Start with requirements. Ask about scale, latency and what operations the system must support.
- Identify your focus. “There’s not enough time to discuss every detail of the design, find the interesting and hard problems to focus the discussion on.”
- Explore the inherent trade-offs and make reasoned decisions about them.
- Drive the discussion. Ask clarifying questions, “but make sure you drive towards a good solution.”
Amazon’s prep page for SDE II roles includes system design too: “Your interviewer will ask questions related to your design, and you should ask questions to complete and validate your design.”
A six-step framework
- Clarify requirements (5 minutes). Functional: what must it do? Non-functional: how many users, how much data, what latency, what availability?
- Estimate scale (2–3 minutes). Requests per second, storage per year, read-to-write ratio. Rough numbers are fine; they drive your choices.
- Define the API and data model (5 minutes). The main endpoints and the core entities.
- Sketch the high-level design (10 minutes). Clients, load balancer, services, databases, caches, queues. Keep it simple first.
- Deep dive (15 minutes). Pick the hardest parts: scaling the database, handling hot spots, consistency, failure handling.
- Wrap up (3–5 minutes). Bottlenecks, what you’d monitor, what you’d do with more time.
Worked example: a messaging backend
This is the example Meta uses in its guide. A condensed walk-through:
- Requirements: one-to-one and group messages, delivery in under a second, message history, online status. Ask how many users and messages per day.
- Scale: if there are 100 million daily users sending 20 messages each, that’s about 2 billion messages a day, roughly 23,000 per second on average and more at peaks.
- API: send message, fetch conversation history, and a connection for receiving messages in real time.
- Data model: users, conversations, messages (partitioned by conversation so a conversation’s history is read from one place).
- High-level design: clients keep a persistent connection (for example WebSockets) to a gateway; a message service writes to a durable store and a queue; delivery workers push messages to recipients who are online and store them for those who aren’t.
- Deep dives: push vs pull delivery, ordering within a conversation, what happens when a gateway server fails, large group chats, and storage growth.
- Trade-offs: strong ordering per conversation costs throughput; storing everything forever costs money, so consider tiered storage.
Core concepts to know
| Concept | What to be able to explain |
|---|---|
| Load balancing | Spreading requests across servers; health checks |
| Caching | What to cache, where (client, CDN, application), and invalidation |
| Databases | SQL vs NoSQL, indexes, replication, partitioning (sharding) |
| Consistency | Strong vs eventual consistency, and when each is acceptable |
| Queues and streams | Decoupling services, absorbing spikes, retries |
| Rate limiting | Protecting services from overload and abuse |
| Availability | Redundancy, failover, avoiding single points of failure |
| Observability | Metrics, logs and traces to know when something breaks |
Common system design questions
- Design a URL shortener.
- Design a news feed.
- Design a chat or messaging system.
- Design a rate limiter.
- Design a file storage and sharing service.
- Design a ride-sharing dispatch system.
- Design a notification system.
- Design a web crawler.
Mistakes to avoid
- Jumping into components before clarifying requirements.
- Designing for massive scale when the problem doesn’t need it, or ignoring scale when it does.
- Naming technologies without reasons. “A queue here because the email service is slow and we don’t want to block the user” is better than “use Kafka.”
- Going wide but never deep. Pick one or two hard parts and go into detail.
- Silence. Think out loud; the interviewer is evaluating your reasoning.
How to practice, including with AI
- Review systems you’ve built. Meta suggests asking: “What would you change about your approach if you did it all over again?”
- Design systems you use every day from scratch: a feed, a messaging app, a map.
- Practice out loud on a timer, drawing as you talk.
- Use AI as an interviewer, not an answer key. Ask a chat assistant to play the interviewer, give you a vague prompt, and push back on your choices with follow-up questions. Then compare your design with its critique. Don’t memorize AI-generated designs; interviewers ask follow-ups that expose memorized answers.
- Check whether AI is allowed in your actual interview. Rules vary by company; see our guide to AI coding interviews.
- Do a mock interview with an engineer if you can. See how to run a mock interview.
Related: data engineer interview questions (pipeline design), .NET Core interview questions and take-home assignments.
Frequently asked questions
What is a system design interview?
An interview, usually about 45 minutes, where you design a system for a broad problem, such as a messaging backend or URL shortener, while talking it through with the interviewer. It tests how you clarify requirements, structure a design and reason about trade-offs, not whether you reach one correct answer.
How do I prepare for a system design interview?
Learn the core building blocks (load balancers, caches, databases, replication and partitioning, queues), practice a repeatable framework out loud on common problems, review systems you've built and what you'd change, and do timed mock interviews.
What framework should I use in a system design interview?
Clarify requirements, estimate scale, define the API and data model, sketch a simple high-level design, deep dive into the hardest parts, and wrap up with bottlenecks and trade-offs.
Do system design interviews involve coding?
Usually not. Meta's guide says its design interviews almost never involve coding; you talk and draw on a whiteboard or a shared diagram tool.
Can I use AI to practice system design?
Yes, as a practice interviewer that gives you prompts and challenges your choices. Don't memorize AI-generated designs, and check whether AI is allowed in your actual interview.
Sources
- Meta Careers, Preparing for your software engineering interview at Meta, updated 2022. Read on 30 September 2026.
- Amazon, SDE II Interview Prep. Read on 30 September 2026.
