What is a system design interview?
A system design interview asks you to design a system under stated constraints and explain your choices. You usually clarify the problem, sketch an architecture, explore important details, and discuss alternatives as the interviewer adds questions.
Formats differ. For example, Atlassian's engineering interview handbook describes a 60-minute design discussion that explores practical decisions and adapts follow-up difficulty. Confirm your own round's length, scope, and permitted drawing tool with the recruiter.
If the round focuses on classes, interfaces, or object modeling, it may be low-level design. The rehearsal below focuses on high-level architecture and distributed systems.
Set up a mock that exposes your gaps
Use a blank whiteboard, a timer, and a partner or AI interviewer that can question your design. If you practice alone, record your explanation and use the follow-ups below after drawing your first version. Keep solved examples closed until the review.
Pick one problem from the system design practice question bank. Choose a problem you cannot reproduce from memory.
Ask your interviewer to answer clarification questions without teaching you a solution. A useful mock gives you room to choose a direction and enough resistance to reveal a weak decision.
Minutes 0–5: agree on the problem
Establish the main user action, essential features, expected load, and correctness requirements. Name one or two things you are leaving out.
Consider this fictional prompt: design a service that notifies customers when an online order changes status.
A useful opening might be:
"I'll start with order updates by email. Do we also need SMS or push notifications? Can delivery lag by a minute, or do some updates need to arrive immediately? I'll assume the order service owns the status, and this service handles notification delivery. Is that the boundary you want?"
This opening separates the source of truth from delivery and identifies a requirement that could change the architecture. It does not introduce a queue before establishing why one is needed.
Minutes 5–10: estimate what affects the design
State your assumptions and do enough arithmetic to find the likely pressure point.
For a fictional workload of two million notification events per day, average arrival rate is approximately 23 events per second. A peak at 20 times that average is roughly 460 events per second. These are practice assumptions, not production benchmarks.
Ask whether one event creates one message or fans out to several recipients and channels. Ask about the delivery provider's limits. An average event rate alone cannot tell you the worker capacity or end-to-end delivery time you need.
Keep estimates tied to a decision. If a number changes nothing about storage, capacity, or failure handling, it probably does not deserve another minute.
Minutes 10–20: draw one complete path
Start with the path from an order-status change to a delivered notification. Label who owns each piece of state and what each arrow carries.
Explain where you accept work, where you persist it, where you call the provider, and how you record the outcome. If notification requests must survive a crash, identify the durability boundary rather than assuming an arrow means reliable delivery.
Walk through one event using the diagram. A listener should be able to follow it without supplying missing components for you.
Minutes 20–35: defend two important decisions
Choose details that could make the design fail. For the notification example, useful questions include:
- What happens when the delivery provider is unavailable?
- How do you handle a timeout when you do not know whether the provider sent the message?
- Can status updates arrive out of order?
- How do you keep a promotional-message backlog from delaying an urgent order update?
Work through one failure at a time. Change the diagram when your explanation requires new behavior.
Use the worked trade-off guide to practice explaining a choice, its cost, and the condition that would make you revisit it.
Minutes 35–40: respond to a changed constraint
Ask your interviewer to change one assumption: traffic increases, a provider fails, or a new channel has a stricter delivery deadline.
First name what breaks. Then change the relevant part of the system and explain the consequence. Adding replicas everywhere without identifying the bottleneck makes your reasoning difficult to assess.
If you cannot resolve the entire problem, state the remaining risk and the next investigation. That gives the interviewer something concrete to question.
Minutes 40–45: summarize the design
Recap the requirements you covered, the central decisions, the largest unresolved risk, and the first signal you would monitor.
Try this structure:
"This design handles these two user actions. We chose this approach because of this constraint. The main cost is this failure or operational burden. Before expanding it, I would validate this assumption and watch this metric."
Use your own decisions to fill it in. A fluent summary cannot repair an architecture you have not explained.
Review evidence across five dimensions
Use these anchors to review your recording or transcript. They are editorial practice anchors, not predictions of a hiring outcome.
Requirements and scoping. Weak: you start drawing before agreeing on the task. Credible: you establish user actions and constraints. Strong: you identify which uncertain requirement could change the design and resolve it explicitly.
High-level design. Weak: boxes appear without a complete request path. Credible: a listener can trace a request and find the stored state. Strong: you also explain ownership and the important failure boundaries.
Technical depth. Weak: you name a technology without explaining its behavior. Credible: you explain one critical mechanism. Strong: you walk through a failure, recovery, and the remaining limitation.
Trade-off reasoning. Weak: every choice is "for scalability." Credible: you compare alternatives against a constraint. Strong: you name the cost and a measurable reason to revisit the choice.
Communication. Weak: the diagram and explanation diverge. Credible: you keep them aligned. Strong: you incorporate follow-ups, make assumptions explicit, and preserve time for unresolved risks.
Choose one gap and rehearse that section again. Completing another problem is less useful if you repeat the same unexplained decision.
Practice with Revarta
Revarta's system design practice combines a timed voice interview with a whiteboard. You draw and explain the architecture, respond to follow-ups, and review feedback across requirements, high-level design, technical depth, trade-offs, and communication. Target levels include mid, senior, and staff.
Explore system design practice on a desktop or tablet. Sign in or create an account to access the practice library; access depends on your plan or available mock credits. If you are preparing for the rest of the loop, see the software engineer interview guide.
Frequently asked questions
Can I practice system design interviews alone?
Yes. Record a timed explanation while drawing, then challenge the design with failure and scale questions. A partner or AI interviewer can add follow-ups you did not anticipate. Either way, review specific decisions and retry the weakest section.
Should I memorize system design answers?
Learn reusable mechanisms and when they apply. Memorizing an entire diagram can hide gaps until the interviewer changes a requirement. Practice explaining why your chosen components satisfy the current constraints.
How long should a system design mock take?
Match the scheduled interview when you know its length. This guide uses 45 minutes as a rehearsal format; actual rounds vary. Shorter drills are useful for a specific weakness, such as clarifying requirements or defending a storage choice.
Is an AI mock interview enough to prove I am ready?
An AI mock can expose unclear reasoning and give you repeated practice. Its feedback is an additional signal, not an employer's decision. Review whether the criticism matches your diagram and explanation, and use human feedback when available.
Sources and editorial scope
Employer-format example: Atlassian engineering interview handbook, checked November 10, 2026. The rehearsal schedule, notification example, and review anchors are original Revarta editorial material. The fictional workload is not a customer result.
