System Design Interview: Format, a 7‑Step Framework and How to Practice with a Mock

What is a system design interview?

A system design interview tests whether you can design a real-world software system made of many parts, and explain your reasoning as you go. There is no single right answer; the interviewer is judging how you scope an ambiguous problem, choose components and weigh the trade-offs between them.

The Tech Interview Handbook describes the aim as evaluating "a candidate's skill at designing real-world software systems involving multiple components", and lists four common formats: back end or distributed system design (the most common), API design, object-oriented design and front end system design (Tech Interview Handbook: system design). The System Design Primer adds that the interview is an open-ended conversation that you are expected to lead (System Design Primer).

Format and timing by level

Most system design rounds are a single interview of about 45 to 60 minutes, usually held on a whiteboard or a shared online drawing tool, and the depth expected rises with seniority. Interns and new graduates rarely get one, while senior and staff candidates often face one or more.

Amazon's published preparation guide for SDE II candidates is a useful concrete example: the online assessment includes 20 minutes of systems design scenarios, and the interview loop is four 55-minute interviews in which candidates should "expect at least one question on software systems design" (Amazon Jobs: SDE II interview prep). Other companies differ, so check what your recruiter tells you.

The Tech Interview Handbook notes that system design questions are "typically given to more senior candidates" and that interns are not usually asked them. This table is a general guide drawn from that pattern, not any one company's policy.

A 7‑step framework for any system design question

A repeatable framework keeps a 45-minute design discussion on track: requirements, estimates, API, data model, high-level design, deep dives and trade-offs. The timings below assume a 45-minute round; adjust them to fit yours, and say out loud which step you are on so the interviewer can follow.

1. Clarify requirements (about 5 minutes)

Start by agreeing what the system must do and how well it must do it, because designing the wrong system is the most expensive mistake you can make in the round. Split requirements into functional ones (what users can do) and non-functional ones (scale, latency, availability, consistency). The System Design Primer's first step asks questions such as who will use it, how many users there are, how many requests per second to expect and what the read-to-write ratio is.

2. Estimate scale (about 5 minutes)

Rough back-of-the-envelope numbers tell you whether one database is enough or whether you need sharding, caching or a queue. Round aggressively and state your assumptions. For a URL shortener, with made-up but plausible assumptions:

• Assume 100 million new short links a month. A month is about 2.6 million seconds, so that is roughly 40 writes per second.
• Assume 10 reads for every write: roughly 400 redirects per second on average, with peaks several times higher.
• Assume 500 bytes per record, kept for 5 years: 100 million × 12 × 5 = 6 billion records, or about 3 TB.

The conclusion matters more than the arithmetic: this is a read-heavy system where a cache in front of the database will carry most of the traffic.

3. Define the API (about 3 minutes)

A short API definition pins down exactly what the system does and gives you names to use for the rest of the interview. Keep it to the two or three calls that matter:

POST /urls          body: { "long_url": "...", "custom_alias": optional }
                    returns: { "short_code": "aZ3kP9q" }
GET  /{short_code}  returns: 301 redirect to long_url, or 404

4. Sketch the data model (about 3 minutes)

The data model shows which entities you store, how they are keyed and which access patterns you must serve quickly. For the URL shortener, one table keyed by short_code with long_url, created_at and owner_id covers the core. Say why you would pick a relational or a key-value store: here every read is a single lookup by key, which suits a key-value store well.

5. Draw the high-level design (about 10 minutes)

The high-level design is the end-to-end path of a request through the main components, drawn simply enough that the interviewer can see it working. A typical first version: clients, a load balancer, stateless application servers, a cache, the database and a service that generates unique short codes. Walk one write and one read through it before adding anything else.

6. Deep dive into one or two components (about 15 minutes)

The deep dive is where most of the signal comes from, so pick the components with the hardest problems, or the ones the interviewer steers you towards. For the URL shortener, that might be how to generate short codes without collisions (a counter with base-62 encoding versus hashing), how to shard 3 TB across machines, and what happens when the cache fails.

7. Discuss trade-offs and wrap up (about 4 minutes)

Finish by naming the main trade-offs you made, the bottlenecks that remain and what you would change at ten times the scale. Showing that you know what each choice gave up shows the interviewer you understand the design rather than reciting it.

Every real design trades something away. Amazon's Dynamo paper, for example, describes a store that chose availability over strong consistency for some services, accepting that replicas may briefly disagree (Amazon's Dynamo).

Common system design interview questions

The same dozen or so prompts appear again and again in system design interviews, because each one forces a different core trade-off. Practice a few that cover different building blocks rather than many that test the same thing.

Several of these appear in the Tech Interview Handbook's list of common back end questions. For a much larger set grouped by topic, see the system design interview question bank.

ML and GenAI system design interviews

An ML system design interview asks you to design a product that depends on a model, such as a recommendation feed, rather than plain back-end infrastructure. A GenAI system design interview does the same for products built on large language models. The structure is similar, but the discussion shifts from servers and databases to data, models and evaluation.

What changes in an ML system design interview

• Frame the problem: turn the product goal into an ML task, and agree how success is measured, both offline and in the product.
• Data: where labels come from, how fresh they need to be, and how you avoid leakage and bias.
• Features and model: start with a simple baseline, then justify anything more complex.
• Serving: batch or real time, latency budgets, and how candidates are retrieved and then ranked.
• Monitoring: data drift, retraining, and how you test a new model safely.

What changes in a GenAI system design interview

• Retrieval: how documents are chunked, embedded and searched before the model sees them.
• Evaluation: how you measure answer quality when there is no single right output.
• Safety: made-up answers, prompt injection, and what the system does when it isn't sure.
• Cost and latency: token budgets, caching, streaming and when a smaller model is enough.

How is a system design interview scored?

A system design interview is scored on how you reason, not on whether you reach one particular architecture. Interviewers typically look at how well you scoped the problem, whether the design works and scales, how you handled trade-offs, the depth of your deep dive, and how clearly you communicated throughout.

Amazon lists the objectives for its systems design questions as practicality, accuracy, efficiency, reliability, optimization and scalability, and tells candidates that they "should ask questions to complete and validate your design" (Amazon Jobs: SDE II interview prep). A practical way to self-score a practice answer:

• Requirements: did you agree functional and non-functional requirements before drawing?
• Estimates: did your numbers change any decision, or were they decoration?
• Soundness: does every request in your diagram have a working path, including failures?
• Depth: could you go two levels down on at least one component?
• Trade-offs: did you say what each choice costs, for example consistency against availability?
• Communication: could the interviewer follow you without asking where you were?

For availability targets, it helps to speak the language of service level objectives; the Google SRE book's chapter on service level objectives is a clear primer.

How to practice with a system design mock interview

A system design mock interview is a timed practice round where someone else plays the interviewer, gives you a prompt and pushes back on your choices. It is the closest you can get to the real thing, because the hardest part of the round is reasoning out loud while being questioned, not knowing the components.

1. Learn the building blocks first. Load balancers, caches, databases and replication, sharding, queues and consistency models. The System Design Primer covers these for free, including back-of-the-envelope numbers and the CAP theorem.
2. Practice solo with a timer. Pick a prompt, set 45 minutes, and talk through all seven steps out loud while sketching on paper.
3. Do mocks with a person. A peer or a more senior engineer can play interviewer, interrupt with "what if this server dies?", and tell you where they lost the thread. Peer interview practice explains how to set this up.
4. Review afterwards. Use the self-scoring list above, note the step that went worst, and start your next mock with that step.
5. Mix in the rest of the loop. System design is usually one round among coding and behavioral rounds; see technical mock interviews for the full picture.

Can you practice system design with MockIF?

Yes, as a spoken discussion rather than a whiteboard round. MockIF does not have a dedicated system design interview type or a drawing canvas; instead, in a full interview for a senior role, its AI interviewer asks about system design, architecture trade-offs and scaling decisions, and follows up on your answers.

Because the interview is built from your resume and the job description, the design questions lean towards the systems and skills that role needs. Keep paper beside you to sketch while you talk, and use the seven steps above to structure your answer. MockIF is free to start with 5 credits, then you can choose a monthly or 3-monthly plan, or buy a one-off credit pack; see pricing. If you want a live human to watch you draw, a peer or coach mock is the better fit.

Frequently Asked Questions