Interview Copilot

System design interview for beginners: what to say, in order

By Interview Copilot · Written for first-time and junior candidates · Updated

Short answer. In a system design interview, the interviewer is mostly listening to how you reason, not checking for one correct design. Work in a fixed order: clarify requirements, estimate the size, sketch the main components, walk one request through them, go deeper on one part, then name the trade-offs and what would break first. For a junior role, a simple design you can explain and defend is worth more than a complex one you can't.

What beginners ask

These come up again and again:

  • "How to prep for junior system design interview?" from someone who is "a complete beginner with no prior experience and prepping for an entry-level SWE role" (r/leetcode).
  • "Best resources for System Design interview prep? (Beginner → Advanced)" (r/leetcode).
  • An engineer with an infrastructure background, asking: "Curious if there is any shortcuts other than repetition." (r/devops).

The honest answer to the last one: the shortcut is a fixed order of steps, so your repetitions are spent on the thinking rather than on remembering what comes next.

What a junior system design round is checking

For junior and mid-level candidates, the round is usually less about distributed-systems depth and more about whether you:

  • ask questions before designing;
  • can break a problem into a few clear parts;
  • know what common building blocks do (load balancer, cache, database, queue) and when you'd add one;
  • notice trade-offs and say them out loud;
  • respond well when the interviewer changes a requirement.

Expectations vary by company and level, so ask your recruiter what the round covers. Some companies don't run system design for entry-level roles at all.

The order: six steps, and what to say at each

1. Clarify requirements (about 5 minutes). Ask what the system must do and what matters most. Say: "Before I design, can I check the main use cases?" Then ask about users, reads vs writes, and whether speed, consistency or cost matters most. Write the answers down where the interviewer can see them.

2. Estimate the size (2–3 minutes). Rough numbers only: requests per second, data per day. Say them as estimates: "Let's assume about 1 million new links a day; that's roughly a dozen writes a second on average." The point is to decide whether one database is enough, not to be precise.

3. Sketch the main components (5–10 minutes). Client → API → service → database, plus anything the requirements force on you. Say why each box is there. If you can't say why, leave it out.

4. Walk one request through (3–5 minutes). "A user submits a long URL. The API validates it, the service generates a short code, stores the pair, and returns the short link." Then the read path. This is where gaps show up, and it's better that you find them than the interviewer.

5. Go deeper on one part (10 minutes). Pick the hardest part, or ask the interviewer which part they want: "Would you like me to go deeper on code generation or on the read path?" Explain your choice and one alternative.

6. Trade-offs and what breaks first (5 minutes). Name one or two trade-offs you made and what would fail first at 10× the traffic. "The single database is the first bottleneck; I'd add a cache for reads, because reads far outnumber writes here."

Worked example: a URL shortener, spoken

Here is how the first two minutes might sound. This is an illustration written for this article, not a transcript.

"Can I check scope first? Users paste a long URL and get a short one, and anyone with the short link is redirected. Do we need custom aliases, expiry, or click analytics? … Okay, no aliases, and analytics later. I'd expect far more redirects than new links, so reads dominate. Let's assume a million new links a day and 100 redirects per link over its life; I'll treat that as read-heavy and design the read path to be fast."

What makes it work: questions first, an explicit assumption, and a conclusion drawn from the numbers ("read-heavy, so make reads fast"). The rest of the design follows from that sentence.

Where to learn the building blocks

Reddit threads on system design prep commonly point to the free System Design Primer on GitHub and to books and courses on system design interviews. Whichever you use, learn what each building block is for (what problem a cache, a queue or a replica solves) before memorising full designs.

Practise it out loud

Most people prepare by reading designs. The round is spoken. The parts that go wrong are the order, the long silences while you draw, and forgetting to say why. Practise by talking:

  1. Pick a common problem: a URL shortener, a rate limiter, a webhook delivery service.
  2. Set a 35-minute timer and talk through the six steps out loud, as if someone were listening.
  3. Afterwards, pick one thing to fix: usually skipping requirements, or never naming a trade-off.
  4. Do the same problem again the next day, then a new one.

A friend who knows the material is the best listener. Without one, Interview Copilot's AI interview practice (Coach) has a system design mock interview that you narrate out loud: it asks the question, follows up when an answer needs more depth, and gives feedback at the end. It is spoken only, with no code editor, and its questions are common problem types rather than your own systems. The free plan includes 20 practice minutes a month.

For the behavioural half of the same loop, see how to prepare stories for an Amazon behavioral interview and our guide to behavioral interview questions.

FAQ

How should a beginner start a system design interview?

Ask clarifying questions about the main use cases, the users and whether reads or writes dominate, and write the answers down before drawing anything.

Do junior engineers get system design interviews?

Some companies include a lighter system design round for junior roles; others don't run one at all. Ask your recruiter what the round covers.

What should I study first?

What each common building block is for: load balancers, caches, databases and replicas, queues. Then practise applying them to simple problems such as a URL shortener or a rate limiter.

How do I practise system design alone?

Talk through a problem out loud with a timer, in a fixed order, then fix one thing and repeat. Recording yourself helps you hear long silences and missing reasons.

Sources