How a system design interview works

A system design interview is a 45-to-60-minute conversation in which you turn a deliberately vague prompt, such as “design a food-delivery app”, into a working architecture, out loud, with an interviewer who knows more about the problem than they have told you. It tests judgement, not recall: what you ask, what you choose, what each choice costs, and whether a colleague could follow your reasoning. This page covers the format, what gets scored, how the bar moves with level, and how to prepare.

Picture it first: briefing an architect

A family in Pune asks an architect to “design us a house”. One architect comes back the next morning with a glossy floor plan. Another sits down and asks: how many people will live here? Will your parents move in? What’s the budget and the plot size? Does the street flood in the monsoon? Might you add a floor in ten years?

The second architect then sketches something rough and talks through it: “I’ve put the staircase on the outer wall so you can add a floor later without breaking the kitchen. It costs you a bit of the living room today.” Halfway through, the family mentions that the grandmother can’t climb stairs. The architect moves a bedroom to the ground floor without fuss.

The family will hire the second architect, and not because the drawing is prettier. They have watched how that person thinks, and they trust them with the money.

Map it back:

• The family is your interviewer, holding requirements they will only reveal if you ask or if your design runs into them.
• The questions are your requirements phase; the rough sketch is your high-level design.
• The staircase is a trade-off stated with its cost; the extra floor is scale and evolution.
• The grandmother is the curveball: a new constraint dropped in mid-design to see how you adapt.
• The decision to hire rests on the conversation, not on the final drawing.

Why companies run this round

Beyond the first couple of years, most engineering work starts without a spec. Someone describes a goal, and you decide what to build, which parts to reuse, what can fail and what it will cost. Coding rounds can’t show that: their problems are well defined and have answers. The design round samples the other half of the job.

The companies’ own prep material says this plainly. Meta’s full-loop guide says the design question “will be something very high-level and it will be up to you to drive the conversation”, and that there’s no “right answer” for a design problem. Atlassian’s engineering page says it wants to see “what questions you would ask, how you’d talk through constraints like reliability and cost, who you might partner with for help, and which technologies you’d use”, and adds: “There’s no one right answer!”

Google’s re:Work guide to structured interviewing explains why an open problem works as a test. Interviewers “may not be looking to assess a correct answer, but instead want to judge the analytical thought process used to explore, define, and offer a solution to the problem.” A system design prompt is that idea at full size: one sentence of prompt and 40 minutes of thinking out loud.

So the round measures three things at once: judgement under ambiguity, breadth (do you know the building blocks and when each fits), and communication (could a team build what you describe, and could you change course when they push back).

The format

Length and place in the loop

Public prep pages agree on the shape, if not the exact minutes:

• Meta: the full loop is four to six 45-minute interviews covering coding, design and behaviour, each leaving a few minutes for your questions. The design interview is one of them.
• Amazon (SDE II): four 55-minute interviews with “at least one question on software systems design”. Interviewers typically also ask two or three behavioural questions based on the Leadership Principles, so part of each slot goes to behaviour. The online assessment before the loop includes 20 minutes of system design scenarios.
• Atlassian: a 60-minute systems design session.
• Microsoft: technical interviews are described as a “short 45-minute interview round”.

Take a 45-minute slot, subtract about 5 minutes of introductions and 5 minutes for your questions, and about 35 minutes are left for design. That matches an Amazon senior engineer’s description of the high-level design round, in which “in just 30 to 40 minutes you have to explain a complete complex system”. Some loops include more than one design round; ask your recruiter which ones you’ll get and how long each is.

Two kinds of prompt

Prompts come in two broad flavours, and each starts in a different place.

Meta’s guide lists both kinds as examples: “Design a URL shortener”, “Build a Facebook chat” and “Architect a worldwide video distribution system”.

Variants of the round

“System design” covers several related interviews. Check which one you have, because they reward different preparation:

• High-level design (HLD). The default and the subject of this handbook: services, data stores, caches, queues, scale and failure. Meta calls it Systems Design, “more focused on distributed systems, scalability, performance and efficiency”.
• Product architecture or API design. Meta’s second variant is “more focused on API design, usability and utility”, with examples such as “Design a chat service or a feed API”. Endpoints, data models, pagination and client behaviour carry more weight; see API design for system design interviews.
• Low-level or object-oriented design (LLD/OOD). Classes, interfaces and extensibility for a bounded problem such as a parking lot or a cache library, sometimes with code. Atlassian’s coding stage, for example, has a “Code Design” part alongside data structures.
• Domain variants. ML engineers commonly get an ML system design round (data, features, training, serving, evaluation); frontend engineers may get client-side architecture, as in Meta’s sample question “How would you architect the front-end for a messaging system?”; SRE loops lean towards capacity and failure.

The whiteboard is usually virtual

Most rounds now happen on video with a shared canvas. Meta’s guide tells candidates to familiarise themselves with Excalidraw, and Amazon’s prep page points to Bluescape; others use a shared document or the interviewer’s tool of choice. Drawing with a mouse is slower than with a marker, so practise on the real tool before the day.

The interviewer is a collaborator with hidden requirements

The interviewer has a version of the problem in mind: the scale, the part they want to dig into, and often a curveball. Amazon’s prep page says “you should ask questions to complete and validate your design”. In Amazon’s system design prep video, a manager adds that an interruption “doesn’t necessarily mean that they’re not happy”; usually they want more data or detail. Atlassian says its questions “ladder”: follow-ups get harder or easier depending on how you’re doing, and may add a new trade-off to test how you adjust.

Treat them as a senior colleague in a design review: share your plan, check assumptions, and use their hints.

How it differs from other rounds

Two differences matter most. A coding round has a finish line; a design round has a horizon, and the interviewer keeps moving it. And in coding the artefact speaks for itself, while in design almost all the evidence is what you say.

What interviewers score

Every company words its rubric differently, but the public guides converge on five signals.

Microsoft’s technical-interview page lists the vocabulary it expects: distributed systems, SOA, n-tier architecture, “resiliency, high availability, auto-scaling, replication, CAP theory, partitioning”. Knowing the terms is the entry ticket; the signals above are about using them.

Google’s SRE workbook adds a useful lens. Its non-abstract large system design (NALSD) method takes a whiteboard sketch and asks, in turn, whether it is possible, whether you can do better, whether it is feasible within budget and hardware, and whether it is resilient, until the design turns into concrete machine counts. The chapter stresses that “sound reasoning and assumption making are more important than any final values”. Interviewers commonly reward the same habit: numbers that drive decisions, with the assumptions said out loud.

The signals are not collected evenly. Each part of the round produces evidence for some of them.

From notes to a decision

Your interviewer doesn’t remember the session; they remember their notes. Google’s re:Work guide describes Google’s structured approach: the same vetted questions for every candidate, predetermined follow-ups, detailed notes, and rubrics that describe what a poor, borderline, solid and outstanding answer looks like for each attribute. Atlassian likewise says its design interviewers choose “from a set of structured questions”.

Atlassian describes the next step: interviewers “consolidate feedback and debrief”, and a hiring committee, which “works independently from our interviewers”, makes the final call with access only to things like interview feedback and your CV.

Three practical consequences follow.

1. Say the reasoning, not just the answer. Meta’s guide puts it bluntly: “Interviewers can only assess your skills and abilities based on what you show them during your interview.” A trade-off you weighed silently earns nothing.
2. Leave evidence for every signal. A brilliant cache deep dive won’t rescue a round in which you never reached a working end-to-end design, because one signal has nothing written under it.
3. The same notes are read against your level. A design rated solid for a mid-level role can be borderline for senior, because the anchors differ. That’s why the next section matters.

How expectations change by level

The prompt is often the same at every level. What changes is how much of the conversation comes from you, how deep you go without being asked, and how wide your view is.

Published career ladders show the same progression. The open-source Engineering Ladders framework moves a developer’s System axis from Designs (“medium to large size features”) through Owns (“the production operation and monitoring of the system”) at its first senior level, to Evolves (“the architecture to support future requirements”) and Leads. Dropbox’s career framework moves from decomposing “a simple problem” into multiple components at IC2, through independently solving “ambiguous, open-ended problems” at IC3 and “coherent designs with multiple components interacting across API or system boundaries” at IC4, to staff engineers “designing systems with significant ambiguity and/or lots of systems that depend on it” and making build-versus-buy choices. The interview is a 45-minute sample of those behaviours.

Strong and weak sessions, minute by minute

The step-by-step method has its own page: the delivery framework. In short, you pin down functional and non-functional requirements (with numbers) and what’s out of scope, name the core entities, sketch the API, estimate only where a number will change a decision, draw a simple high-level design that satisfies every requirement, and spend the remaining time on deep dives into the hardest parts. The time budget and a worked example live there.

Here is how the same prompt, “design a food-delivery app”, can play out.

The weak session isn’t short of knowledge: Kafka, Redis and Cassandra may all belong in the final design. It fails on order and evidence. An Amazon manager describes the most common version in the company’s prep video: “a lot of times we end up getting requirements but not using them in the design.” The full catalogue of failure patterns, with what to do instead, is in common mistakes that sink design rounds.

Preparing: what to study, in what order

Meta’s guide offers a sensible core: review systems you have built and what you would change, design from scratch systems you use every day, read engineering blogs (“Read about the false-starts too!”), and practise answering questions “in roughly 30 minutes per question”. Here is one way to turn that into a plan, assuming about an hour on weekdays and a longer session at weekends.

1. Fundamentals (weeks 1–2)

Learn the vocabulary every design leans on: scalability, latency, throughput and bandwidth, availability and the nines, CAP and PACELC, consistent hashing and API design. Start the daily estimation habit with back-of-envelope estimation and numbers to know.

2. Building blocks (weeks 2–4)

For each component, know what it is good at, what it costs and how it fails: databases for system design interviews, caching, message queues, Redis, Kafka and blob storage. An Amazon senior engineer warns that if you claim a database feature is required, “I usually ask them to design that part in detail”, so learn the internals of anything you plan to name.

3. Patterns (weeks 4–5)

Patterns are the reusable answers to the hard parts: scaling reads, scaling writes, real-time updates, contention and double booking, long-running jobs, plus the trade-offs behind them.

4. A mental library of about 20 designs (weeks 4–8)

You will rarely get a prompt you’ve seen, but most prompts are recombinations of a few dozen. Build a library of about 20, 20 designs ÷ 5 weeks = 4 a week, chosen to cover different hard parts:

For each design, remember three things rather than the whole diagram: the two or three hard parts, the one number that drives the architecture, and the main trade-off with its cost. That fits on an index card and recombines well.

5. Practice under interview conditions (weeks 5–8)

A useful loop per problem: a timed 35-minute attempt on the tool you’ll use, then 30 minutes comparing against the write-up, then five lines on what you missed. From week 5, add 1–2 mock interviews a week, 4–8 in total, with a peer or a colleague who has interviewed. Record yourself once; most people discover long silences and unexplained arrows. Ask your mock interviewer to hide a requirement and spring it on you halfway through.

Remote interview logistics

Most design rounds now happen over video, which changes a few things.

• Test the setup the day before. Meta asks candidates to enable Zoom screen sharing in advance because setup can take a few minutes, and to use a laptop with webcam, speaker and microphone; a headset is recommended.
• Learn the canvas. Open the tool (Excalidraw, Bluescape or whatever the recruiter names) and draw a five-box design against a timer. Know how to make boxes, arrows and text, and how to zoom out.
• No filters, no outside help. Meta asks candidates to disable video filters, including blurred and virtual backgrounds, and not to use outside assistance, which explicitly includes AI tools like ChatGPT. Don’t paste a pre-drawn diagram unless the interviewer invites it.
• Narrate as you draw. The interviewer can’t watch your face and the canvas at once. Say what each box is as you place it, and keep requirements and numbers in a corner of the canvas where both of you can see them.
• Lay out for the screen. Draw left to right (client, edge, services, data), leave space between boxes for later additions, and zoom out before the deep dives so the whole design is visible.
• Plan for a dropped call. Keep a phone nearby and the recruiter’s contact details to hand. And if the audio is unclear, Meta’s guide notes that it’s fine to ask the interviewer to speak more slowly.

Cheat sheet

How to say it in the interview

Here is how you might open a round in the first 60 seconds:

“Thanks. Before I draw anything, I’d like about five minutes on scope: a few questions about users and the core flows, then I’ll write down the functional requirements, two or three numbers, and what I’m leaving out. After that I’ll sketch a simple design that works end to end, and spend most of our time on the parts that are hardest here. For food delivery, my guess is live order tracking and assigning riders during the dinner peak. Please stop me if you’d rather I go deeper somewhere else. First question: are we designing the customer app, the restaurant side, the rider side, or all three?”

Should I estimate traffic first? Only the numbers that change a decision, such as one database versus shards or a cache versus none, and only once you know what you’re building. State the assumptions so the interviewer can correct them. Google’s SRE workbook puts the priority clearly: reasoning and assumptions matter more than the final values. The method is in back-of-envelope estimation.

What if I don’t know a technology the interviewer mentions? Say so, then reason from first principles: “I haven’t used it; if it’s a log-structured store with partitions, I’d expect ordering per partition and need to choose a key.” Meta’s guide says “it’s ok if you don’t know”, and Atlassian’s says “If you don’t know what to do, say so!” An Amazon senior engineer advises using generic terms rather than product names anyway, because naming a feature invites a request to design it.

How much should I talk versus draw? Talk nearly all the time, and draw to anchor what you say. A box that appears without a sentence leaves nothing for the notes; a long explanation with no diagram is hard to follow. If you need to think, say so: “Give me 20 seconds to compare two options.”

What if the interviewer keeps interrupting? Treat each interruption as information. They want more detail, or they’re steering you towards a hidden requirement or the deep dive they care about. Answer it, then signpost: “I’ll note that and come back to it after the write path.” Atlassian’s laddered follow-ups and Amazon’s advice both describe interruptions as normal, not as a bad sign.

Is there one right answer? No; Meta and Atlassian both say so. But there are wrong answers: designs that miss a stated requirement, ignore the numbers you agreed, or can’t survive a single failure. Two candidates can pass with different architectures, as long as each choice is justified and its cost is named.

Where to go next

• The delivery framework: the step-by-step method and time budget for the round itself.
• Back-of-envelope estimation: turning stated assumptions into the numbers that pick a design.
• Numbers to know: latencies, throughputs and sizes to plug in.
• Common mistakes that sink design rounds: the failure patterns, and a self-review checklist.
• Ten principles senior engineers design by: the habits behind the senior and staff columns.
• API design for system design interviews: the API step and the product-architecture variant.
• Databases for system design interviews: the storage choices nearly every prompt needs.
• Design a rate limiter: a full worked infrastructure problem to practise against.

References and further reading

1. Preparing for your Full Loop Interview at Meta (Software Engineer Full Loop Interview Guide, PDF)metacareers.comFour to six 45-minute interviews; the 45-minute design interview, its systems and product-architecture variants, four focus areas, Excalidraw, and video-interview rules.
2. SDE II Interview Prep (Amazon Jobs)amazon.jobsFour 55-minute interviews, at least one system design question, the listed design objectives, Leadership Principles in every interview, and the Bluescape whiteboard.
3. System Design Interview Prep, video transcript (Amazon Jobs)static.jobs.production.amazon-jobs.brightspot.cloudAn Amazon manager on asking about scale first, writing requirements down and using them, validating assumptions, and why an interruption usually means “more detail, please”.
4. Prep Series, Senior Software Development Engineer, video transcript (Amazon Jobs)static.jobs.production.amazon-jobs.brightspot.cloudThe senior high-level design round: 30–40 minutes of real design, architecture plus sequence diagrams, generic terms over product names, and being asked to design any feature you claim.
5. Engineering interview process (Atlassian Careers)atlassian.comThe 60-minute systems design session, structured questions that “ladder”, no single right answer, a Code Design coding stage, debriefs and an independent hiring committee.
6. Technical interviews (Microsoft Careers)careers.microsoft.comThe 45-minute round, designing new systems from scratch, and the distributed-systems topics to review.
7. A guide to structured interviewing for better hiring practices (Google re:Work)rework.withgoogle.comSame questions and rubrics for every candidate, predetermined follow-ups, poor/borderline/solid/outstanding anchors, and judging the thought process rather than a correct answer.
8. Introducing Non-Abstract Large System Design (Google SRE Workbook, chapter 12)sre.googleIterating a whiteboard design through “possible, better, feasible, resilient” into concrete resources, and reasoning over final values.
9. Dropbox Engineering Career Frameworkdropbox.github.ioPublished software-engineer expectations from IC2 to IC5 Staff, used to ground how design scope and ambiguity grow with level.
10. Engineering Ladders (Jorge Fioranelli, open source)github.comThe developer ladder’s System axis (designs, owns, evolves, leads) and Influence axis (team to company).