Interviewers do not expect you to have built a large distributed system. Almost nobody applying has. They expect you to reason about one clearly, and that is a separate skill you can learn on purpose.
The candidates who fail without production experience rarely fail because of the missing experience. They fail because the gap shows in four specific ways, and all four are fixable in a few weeks.
This article is about the gap itself. If you want the full study plan, read A Beginner's Guide to System Design Interviews instead. This one covers what interviewers actually notice and how to build experience you can borrow. It also covers what to say when you have never built the thing being discussed.
Do interviewers expect you to have built a distributed system?
No, and the reason is simple. If they required it, they could only hire from a few thousand people worldwide who have operated systems at that scale.
Think about who sits across from you. That interviewer works on one service inside a very large company. They have deep knowledge of their part and normal knowledge of everything else. They are not comparing you against their own system. They are asking whether you can hold a technical conversation about a system neither of you has built.
There is one honest exception. A role that specifically says "distributed storage" or "large-scale infrastructure" in the description will test depth you cannot fake. That is a smaller set of roles than most candidates assume.
What the round tests instead
Three things, and none of them require production experience.
Can you turn a vague question into a specific problem? You are given four words: "design a chat app." A senior engineer asks who uses it, how many, whether messages must arrive in order, and whether history is stored. This is a habit, not a memory.
Do you know the building blocks and what each one costs? About a dozen concepts appear in most interviews. Knowing that a cache makes reads fast is the easy half. Knowing that it creates a stale data problem you must then handle is the half that interviewers actually score.
Can you choose, and say why? Every design has a moment where two options are both reasonable. SQL or NoSQL. Consistency or availability under failure. The score comes from naming both and picking one for a stated reason.
Experience helps with all three. It is not the only way to get them.
The four places the experience gap actually shows
You give no numbers. Candidates without operational background describe systems in adjectives. The system is "fast" and "scalable." Engineers who have run systems speak in quantities: 50,000 writes per second, 200 milliseconds at the 99th percentile, two terabytes per year. You can learn to do this from a book. Estimate traffic and storage out loud in every practice run, using back-of-the-envelope estimation.
You design only for the working case. This is the clearest signal. Someone who has been paged at night designs with failure in mind by habit. They ask what happens when a database replica falls behind, or when a queue consumer stops. Someone who has not been paged draws a system where every part works. Fix this by asking one question after every component you draw: what happens when this one fails?
You name products instead of properties. Saying "I will use Kafka" is weaker than naming what you need. The stronger version is this: "I need a durable log that lets consumers read at their own speed, so Kafka fits." That version survives the follow-up question. The first invites an interviewer to ask what Kafka actually guarantees.
You stop at the first correct answer. Without experience it is tempting to present one design and defend it. Engineers who have maintained systems know the second-order costs, so they volunteer them. Say what your design makes worse, not only what it makes better.
| The signal | What it sounds like | What to say instead |
|---|---|---|
| No numbers | "It needs to be scalable" | "At 10 million daily users that is about 1,000 writes per second" |
| Only the working case | "The service writes to the database" | "If the primary is unavailable, writes queue here and we accept a delay" |
| Products, not properties | "I will use Redis" | "I need a fast in-memory store for session data, so Redis fits" |
| One option, no alternative | "I will shard by user id" | "Sharding by user id keeps a profile on one machine, but hot users become a problem" |
How to build experience you can borrow
You cannot get four years of production experience in six weeks. You can get enough borrowed experience to speak accurately, and there are four sources worth your time.
Public engineering write-ups. Large companies publish how their systems work and, more usefully, how they broke. A public incident write-up gives you the failure vocabulary that production normally teaches. Read one a week and note what surprised you.
Worked case studies. Reading a complete design for a known system teaches the order of decisions, which is the part that is hard to invent. The free lessons on designing Instagram, a web crawler, and Uber each show a full sequence from requirements to bottlenecks.
A small system you build yourself. Scale is not the point. Run two copies of a service behind a load balancer on your own machine. Put a cache in front of a database and then make the cached data wrong on purpose. Two afternoons of this teaches more about replication lag than a week of reading.
Your current work, described accurately. Most engineers underrate what they have already done. Have you handled a slow query, added an index, fixed a race condition, or retried a failed API call? Each one is a real distributed systems problem at a smaller size. These are legitimate examples. Use them.
A structured course does the second source for you and orders it. That is what Grokking the System Design Interview contains. It has 15 complete design problems, and the trade-off at each decision is written out rather than left for you to infer.
What to say when you have not built it
Never claim experience you do not have. Interviewers at this level ask a second question, and the second question is where invented experience fails.
Say this instead, in your own words:
"I have not run this at that scale. Based on how I understand the trade-off, I would start with X, because Y. The part I would want to measure first is Z."
Three things happen when you say that. You stay accurate, which protects you from a follow-up you cannot answer. You still make a decision, which is what is being scored. And you name what you are uncertain about, which experienced engineers do constantly and junior engineers rarely do.
The failure case is different from what candidates fear. Nobody is rejected for saying "I have not operated this." People are rejected for saying "we would just use Cassandra" and then having no answer when asked what Cassandra guarantees.
What you can safely skip
Preparation time is limited, so some things are not worth it without production background.
Skip memorizing internal architectures of specific databases, unless you name one in your design. Skip configuration details and version numbers. Skip building a real distributed system to prove something, because it takes months and the interview does not ask for it.
Spend that time on the building blocks instead: load balancing, sharding, the CAP trade-off, and how trade-offs are judged in interviews.
How long this takes
Six to eight weeks of consistent evening study is a realistic target for a first senior-level design round. Four weeks is possible if you already know databases and caching well.
Spend the first three weeks on vocabulary, the next three on complete case studies, and the last two on practice under a timer. The timer matters. Knowing a design and explaining it in 35 minutes are different skills, and only the second one is tested.
Frequently asked questions
Can I pass a system design interview with no backend experience at all? It is harder, but it happens, especially for mid-level roles. You need the vocabulary and a repeatable method. Front-end and mobile engineers often do well in product-focused design rounds, where the data model and API matter more than storage internals.
Will the interviewer know I have never built one? They will notice if you speak in adjectives instead of numbers, or if you design only for the working case. They will not notice merely because you lack the experience. Fix the four signals above and the gap stops being visible.
Should I admit I have not built the system being discussed? Yes, briefly, and then keep going. Say what you would do and why, and name what you would measure. Do not spend two minutes apologizing, and never invent a project.
Is it worth building a side project to gain experience? A small one, yes. Two services, a load balancer, a cache, and a deliberate failure teach you real behaviour in a weekend. A large project is not a good use of preparation time.
Do CRUD developers get rejected for lack of scale experience? Not for the lack itself. Most engineers work on systems smaller than the ones discussed in interviews. What gets rejected is a design with no failure handling and no stated trade-off.
How many practice problems should I do? Eight to ten complete ones, each attempted on a timer before you read the solution. Attempting first is what makes the review useful.
Related reading
- A Beginner's Guide to System Design Interviews, the full step-by-step study plan
- The Meta System Design Interview, for what one company's round looks like in detail
- Top 30 System Design Interview Questions and Answers
- Grokking System Design Fundamentals vs the Interview Course, for which one to take first
- How Long Does It Take to Finish Grokking the System Design Interview
The gap you are worried about is smaller than it feels, and it is not the gap being tested. Learn the building blocks. Practice reasoning out loud with numbers and failure cases, and be accurate about what you have and have not done. If you want that sequence already built, start with Grokking the System Design Interview.