A system design interview is a technical interview in which you design a large-scale software system, such as a URL shortener, chat app or news feed, out loud: clarifying requirements, sketching components and data storage, and explaining trade-offs. Interviewers judge your reasoning, not one correct answer. It is a standard round in many software engineering loops.
The prompt is short and vague on purpose. "Design a URL shortener" leaves you to decide how many users, how fast, how reliable and how expensive, and the way you make those decisions is most of what's being assessed. As of October 2026, Amazon's interview prep page for software development engineers says most of its technical interviews require coding and system design whiteboarding exercises, and it lists distributed-computing topics to know, including service-oriented architecture, MapReduce, distributed caching and load balancing (Amazon's SDE interview topics).
How a system design interview works
Most rounds follow the same arc, whether you draw on a whiteboard or in an online diagram tool. The timings below are one common way to pace a 45-minute round, not a rule.
- Clarify requirements (about 5 minutes). Ask what the system must do (functional requirements) and how well it must do it (non-functional: scale, latency, availability, consistency). Write the answers down.
- Estimate the scale (about 5 minutes). Rough numbers: daily users, requests per second, read-to-write ratio, storage per year. These drive every later choice.
- Define the API and data model (about 5 minutes). A few endpoints and the main tables or records.
- Draw the high-level design (about 10 minutes). Clients, load balancer, services, databases, caches and queues, and how one request flows through them.
- Deep dive (about 15 minutes). The interviewer picks one or two areas, such as how you'd partition the database, keep the cache fresh or handle a hot key.
- Bottlenecks and wrap-up (about 5 minutes). What breaks first at ten times the load, how you'd monitor it, and what you'd change with more time.
What interviewers assess
| Signal | What a strong candidate does |
|---|---|
| Requirements | Asks focused questions before drawing and states assumptions out loud |
| Structure | Gets a complete end-to-end design on the board before polishing any one part |
| Data | Picks storage that fits the access pattern and can explain relational vs non-relational trade-offs |
| Scale and reliability | Uses numbers to find bottlenecks; covers caching, replication, partitioning and failure |
| Trade-offs | Says what each choice costs, not only what it gains |
| Communication | Thinks aloud, checks in with the interviewer and uses hints |
Amazon's guide makes a similar point: interviewers aren't testing whether you memorized every detail, but whether you can apply what you know to solve problems efficiently.
How expectations change with seniority
Companies don't share one rubric, so this varies. Candidate reports describe a common pattern. New-grad loops often have no full system design round, or a smaller object-oriented or API design question instead. Mid-level candidates are expected to drive a working design with some hints. Senior candidates are expected to lead the conversation, spot bottlenecks unprompted, cover operations and failure, and may face more than one design round. Ask your recruiter which rounds your loop includes; Amazon's guide recommends exactly that.
What a system design interview looks like in practice
This is a condensed example we wrote. All numbers are assumptions you'd agree with the interviewer, not real traffic figures.
- Prompt: "Design a URL shortener."
- Clarifying questions: Do links expire? Do we need custom aliases and click counts? Is traffic read-heavy? (Assume yes: 100 reads for every write.)
- Estimate: 10 million new links a day is roughly 116 writes per second, so about 11,600 reads per second at 100 to 1.
- High-level design: A write service creates a short code and stores code-to-URL in a key-value store. A read service looks up the code, with a cache in front because reads dominate, and returns a redirect.
- Deep dive: Hashing the long URL risks collisions; a counter encoded in base 62 avoids them but needs coordination across servers. A 7-character base-62 code allows about 3.5 trillion combinations.
- Trade-off: A 302 redirect sends every click through your servers, so you can count it. A 301 can be cached by browsers, which cuts load but hides repeat clicks from your analytics.
The full walkthrough is in our guide to designing a URL shortener.
System design vs coding and object-oriented design interviews
System design is one kind of technical interview. It's easy to confuse with two neighbors.
| System design (high-level) | Object-oriented (low-level) design | Coding interview | |
|---|---|---|---|
| Typical prompt | "Design a news feed" | "Design the classes for a parking lot" | "Find the longest substring without repeating characters" |
| What you produce | Components, data flow and estimates | Classes, interfaces and relationships | Working code |
| Main skill tested | Architecture and trade-offs at scale | Clean, extensible code structure | Algorithms and data structures |
| One right answer? | No | No, but some designs are clearly cleaner | Usually there is a correct, efficient solution |
Amazon's prep page covers both kinds of design: it expects a working knowledge of object-oriented design and says you should be ready to defend your design choices. Our parking lot design guide is a typical object-oriented prompt.
How to prepare for a system design interview
- Learn the building blocks. Load balancers, caches, SQL vs NoSQL, replication, sharding, queues, CDNs and consistency models. The free system design cheat sheet and our 14 core concepts guide cover them.
- Use one framework every time. Requirements, estimates, API, high-level design, deep dive, wrap-up. A fixed order frees your attention for the problem itself.
- Work through classic problems. Start with a URL shortener, then a rate limiter, a chat app and a news feed. Our rate limiter walkthrough is a good second problem.
- Practice talking while you design. Going quiet while you draw hides the reasoning you're being scored on. CoPilot Interview's Mock Interview lets you add system design to the question mix, reads each question aloud, scores your spoken answer out of 10 with what to fix and a model answer, and ends with a report card. Our system design mock interview script shows how to run a full session, and the system design interview page covers the topics the app handles.
Common mistakes
- Drawing before asking. A design for the wrong requirements wastes the round.
- Naming tools without reasons. "Use a queue" earns little; "use a queue so writes survive a traffic spike, at the cost of some delay" earns more.
- Skipping the numbers. Without estimates you can't justify a cache, sharding or a particular database.
- Over-engineering. Ten microservices for a system with a thousand users is a warning sign, not a strength.
- Ignoring hints. When the interviewer asks "what happens if this server fails?", that's where they want you to go next.
- Never mentioning failure. Replication, retries, timeouts and monitoring belong in every design.
For more interview terms, see our interview glossary and the definition of a behavioral interview, another round you may meet in the same loop.
Rehearse a system design round out loud
Add system design to CoPilot Interview's Mock Interview mix and get each spoken answer scored out of 10 with what to fix and a model answer. The free plan includes 15 minutes every day and all four modes, with no credit card.
Try a free AI mock interviewFAQ
How long is a system design interview?
It varies by company. Amazon, for example, says you will spend around 45 minutes to an hour with each interviewer in its loop, as of October 2026. Ask your recruiter for the length of your round and pace your design to fit it.
Do new grads get system design interviews?
Sometimes. It depends on the company and level. Many candidate reports describe new-grad loops with no full system design round, or a smaller object-oriented or API design question instead. Your recruiter can tell you which rounds you will have.
Is there a right answer in a system design interview?
No single right answer. Several designs can work. Interviewers score how you gather requirements, use numbers, reason about trade-offs and adapt when they add a new constraint.
What topics should I know for a system design interview?
Amazon's prep page lists service-oriented architecture, MapReduce, distributed caching and load balancing, plus database trade-offs, operating system basics and how the internet works, from DNS to TCP/IP. Those are a solid baseline for any company.
Can I practice a system design interview with AI?
Yes. CoPilot Interview's Mock Interview can include system design questions, reads them aloud and scores each spoken answer out of 10 with what to fix and a model answer. The browser version needs no install and has a system design track. The free plan includes 15 minutes every day.