System design interview for 3 to 5 years of experience

For system design interview preparation at 3 to 5 years of experience, spend week one learning core building blocks such as load balancers, caches, databases, queues and sharding, and week two practising full designs out loud with a fixed framework: requirements, estimates, API, data model, high-level design, deep dive and trade-offs.

At three to five years of experience, system design rounds stop being optional. Many companies, especially product companies and startups, now include at least one design round for mid-level backend and full-stack roles. And unlike coding rounds, there is no single correct answer to memorise, which makes many engineers put off preparing until the interview is a week away.

Two focused weeks are enough to go from nervous to structured. This plan assumes you work full time and can give about 90 minutes on weekdays and three hours on weekend days. If you need a refresher on the vocabulary first, start with our system design interview basics, then come back here for the plan.

What do interviewers expect at 3 to 5 years?

Interviewers do not expect a mid-level engineer to design a global system with the depth of a principal architect. They are checking whether you can take a vague problem, make sensible decisions, and explain the trade-offs behind them. Here is what usually separates a pass from a fail at this level.

• You clarify requirements before drawing anything, and you separate functional from non-functional needs.

• You make rough capacity estimates and use them to justify choices, not just recite numbers.

• You draw a clean high-level design with the main components and how data flows between them.

• You go deep on one or two parts, such as the database schema, caching strategy or queue design.

• You name trade-offs honestly, for example consistency versus availability, and say why you chose one.

• You drive the conversation, but you listen and adapt when the interviewer pushes in a direction.

What framework should you use in every round?

A fixed framework keeps you calm and stops you from jumping straight to boxes and arrows. Use the same seven steps for every practice problem so they become automatic. In a 45-minute round, the rough timings below work well.

1. Requirements (5 minutes): ask what the system must do, who uses it, and what matters most, such as latency, scale or reliability.

2. Estimates (3 to 5 minutes): rough users, requests per second, storage per year. Keep the maths simple and round numbers.

3. API (3 to 5 minutes): list the key endpoints or events with their inputs and outputs.

4. Data model (5 minutes): the main entities, their fields, and whether a relational or NoSQL store fits better.

5. High-level design (10 minutes): clients, load balancer, services, databases, caches, queues, and how a request flows.

6. Deep dive (10 minutes): pick the hardest part, or the part the interviewer cares about, and go into detail.

7. Trade-offs and wrap-up (5 minutes): bottlenecks, failure handling, what you would improve with more time.

What is the 2-week plan, day by day?

Week one builds your toolkit. Week two is all practice. Resist the urge to only read: by day eight you should be designing out loud every day.

Day 12 is often the most valuable. Interviewers frequently ask about systems you have built. Being able to redesign your own project, and say what you would change, shows real experience.

Worked example: how would you design a notification service?

Here is a condensed version of how Karthik, a backend engineer with four years of experience, walked through this problem in a practice session. Use it as a model for your own day 9.

Requirements and estimates

Before I design anything, let me confirm scope. We need to send notifications by push, email and SMS, triggered by other services, such as an order shipped event. Users can set preferences per channel. Delivery should be reliable, but a few seconds of delay is fine. For estimates, I will assume around 10 million users and 50 million notifications a day, which is roughly 600 per second on average, with peaks perhaps five times higher during sales.

API and data model

Karthik proposed a single internal endpoint, send notification, taking a user ID, a template ID, channel hints and a payload. For data, he kept user preferences and templates in a relational database, because they are small and change rarely, and stored a notification log in a NoSQL store keyed by user ID and time, because it is write-heavy and queried by user.

High-level design

Producer services call the notification API, which validates the request, checks user preferences, renders the template and publishes one message per channel to a queue. Separate worker pools consume each channel queue and call the external providers for push, email and SMS. A cache in front of the preferences database keeps lookups fast at peak.

Deep dive: reliability

The tricky part is reliability with external providers. If the SMS provider times out, the worker retries with exponential backoff, and after a few failures the message moves to a dead letter queue for inspection. To avoid sending the same notification twice on retry, each message carries an idempotency key, and the worker checks the log before sending. If one provider is down for long, we can route to a backup provider for that channel.

He closed by naming bottlenecks: the template rendering step at peak and per-provider rate limits. He suggested scaling rendering horizontally and adding a per-provider rate limiter in front of the workers. That wrap-up is what interviewers remember.

Which trade-offs should you be ready to discuss?

Mid-level candidates often know the components but struggle to explain choices. Prepare a one-line reason for each side of these common trade-offs.

What mistakes cost mid-level candidates the round?

• Drawing boxes in the first minute without asking a single requirement question.

• Spending fifteen minutes on estimates and running out of time for the design.

• Naming technologies without reasons, such as 'I will use Kafka' with no explanation of why a queue is needed.

• Ignoring failure: no mention of retries, timeouts, replicas or what happens when a service is down.

• Going silent while thinking. Narrate your reasoning, even when you are unsure.

• Refusing to change direction when the interviewer hints that a part needs rethinking.

How do you practise system design out loud?

Reading about systems builds knowledge, but speaking builds fluency. Practise each design with a timer, a whiteboard or a simple drawing tool, and explain every step as if someone is listening. Record yourself once and watch it back. You will spot long silences and skipped steps immediately.

Pair up with a colleague and take turns as interviewer, or run a timed mock interview on day 13 to get structured feedback. If your role is Java-heavy, also revise the backend questions in our Java developer interview questions, since design rounds often lead into follow-ups about your stack.

On the day itself, some candidates use Interview Copilot for technical interviews to see a live, speaker-labelled transcript and recall their own project details under pressure. Follow each employer's interview rules, and treat any tool as support for expressing your own real experience.

Ready to begin your two weeks? Start free with InterviewPlan AI and get 5 live Copilot minutes and 100 AI credits, no card needed.

Frequently asked questions

Is two weeks enough for system design interview preparation?

For engineers with three to five years of experience, two focused weeks is usually enough to become structured and confident. Spend the first week on building blocks like caching, databases, queues and sharding, and the second week designing full systems out loud. If you are starting from scratch, add an extra week of reading first.

What system design questions are common for mid-level engineers?

Common mid-level questions include designing a URL shortener, a notification service, a rate limiter, a news feed, a chat application, a file storage service or a parking lot system for low-level design. Interviewers also often ask you to explain and improve a system you have built in your current or previous role.

Do I need to know specific tools like Kafka or Redis?

You should know what categories of tools do, such as message queues, caches and distributed databases, and when to use them. Naming a specific tool is fine if you can explain why it fits. Interviewers care more about your reasoning and trade-offs than about which brand of technology you choose.

How long should capacity estimates take in an interview?

Keep estimates to about three to five minutes in a 45-minute round. Use round numbers, state your assumptions clearly, and calculate only what affects your design, such as requests per second and storage per year. The goal is to justify decisions, not to produce precise maths.

How is low-level design different from system design?

Low-level design focuses on classes, interfaces and object-oriented structure for a smaller problem, like a parking lot or library system. System design focuses on how services, databases, caches and queues work together at scale. Mid-level candidates may face either or both, so prepare at least two low-level problems as well.