System Design Interviews: What Mid-Level Engineers Miss

Most engineers walk into a system design round and start drawing boxes. Database box. Service box. Cache box. Their interviewer watches them sketch a recognizable architecture and thinks: "This person learned from YouTube." Not a compliment.

The problem isn't that the boxes are wrong. The problem is that selecting technology before understanding constraints is the single most common way mid-level engineers fail this round.

What Is a System Design Interview, Really?

A system design interview is a structured 45-60 minute conversation where you're asked to design a large-scale software system from scratch — think "design Twitter's feed" or "build a ride-sharing location service." The interview exists to test whether you can reason under ambiguity, not whether you can recall the right buzzwords.

At mid-level (L4-L5 at Google, SDE-II at Amazon, equivalent elsewhere), you're not expected to redesign Kafka from memory. You are expected to know why you'd use a message queue to decouple notification delivery from the API response, and what the tradeoff is between consistency and availability in that choice.

System design interviews differ from coding rounds in one critical way: there's no single correct answer. Interviewers are calibrating how you think, not grading an output. According to a 2023 Levels.fyi survey of 1,200 engineers who failed a final round, 68% identified system design as the stage where they fell short — making it the most frequently cited failure point in the data.

How Do Mid-Level Engineers Typically Fail This Round?

The most common failure isn't insufficient technical knowledge. It's skipping the conversation phase.

Junior engineers ask no questions. They hear "design a URL shortener" and immediately start whiteboarding. Senior engineers understand that the first 5-7 minutes should be pure requirement discovery: Who is this for? What's the scale? Does it need custom aliases? Does the redirect need to be fast or just functional?

Mid-level engineers who pass this round treat requirement-gathering as load-bearing work, not formality.

A Google L5 interviewer described it in a 2024 Blind thread (847 upvotes): engineers who stood out spent twice as long on constraints as on the actual design. The ones who failed jumped to the architecture before asking a single question.

A second failure mode: designing for infinite scale from minute one. You don't need Kafka, a CDN, and three caching layers for a URL shortener handling 1,000 redirects per day. Over-engineering signals that you can't calibrate to requirements — which is exactly what a mid-level engineer should be able to do.

How should mid-level engineers approach a system design interview?

A system design interview tests your reasoning under ambiguity, not your ability to recall distributed systems buzzwords. The approach that works consistently: spend the first 5-7 minutes clarifying requirements, write out the API contract before sketching any database, then build the core flow end-to-end before layering in scale. At mid-level (L4/L5 range), you're expected to know the difference between a read-heavy and write-heavy workload, and to match your design to the actual load profile. Interviewers aren't defaulting to Kafka and microservices — they're listening for defensible choices. A simple PostgreSQL service with Redis in front handles most interview scenarios cleanly. The engineers who pass name the tradeoff out loud: "I'm choosing SQL here because the data is relational and the read volume doesn't require horizontal sharding yet." That specificity separates a passing answer from a generic one.

Which Framework Actually Works for Mid-Level Candidates?

There's a practical five-step approach used by candidates who consistently pass this round:

1. Clarify scope. Ask 4-6 targeted questions: expected load, data retention, latency requirements, user geography, read-vs-write ratio.
2. Define the API contract. Before any diagram, write out the key endpoints or interfaces. This forces clarity on what the system actually does.
3. Sketch the data model. What are the primary entities? What gets stored, for how long, and in what shape?
4. Design the core flow first. Build the happy path end-to-end before adding resilience.
5. Layer in scale. Only now introduce caches, queues, sharding, and replication — with explicit tradeoffs for each.

This order matters. Most candidates invert steps 2-3 and step 1, which means they spend the interview solving a problem they didn't fully understand.

The biggest design decision you make in any system design interview is what you choose NOT to include — and why.

IntervYou's mock design sessions follow this exact order, with the coach interrupting at the same checkpoints a real interviewer would. The difference from watching a YouTube walkthrough: you're forced to practice the habit, not just recognize it.

Worked Example 1: Designing a URL Shortener

Here's what a passing mid-level system design answer looks like in dialogue form.

Interviewer: Design a URL shortener similar to bit.ly.

Candidate: A few questions before I start — what's the expected daily volume? Are we talking thousands of shortened links or millions of redirects per day?

Interviewer: Let's say 100 million redirects per day, 1 million new URLs created daily.

Candidate: Got it. Should users be able to customize their short codes, or is random generation fine? And do we need analytics — like click counts per link?

Interviewer: No custom aliases for now. Analytics are out of scope.

Candidate: So the core API is two operations: POST /shorten to create a short link, and GET /{code} to redirect. The write path is simple — generate a unique 6-7 character code, store the mapping, return the short URL. The read path is what matters at 100M daily redirects.

At this scale, reads are 100x writes. I'd put a cache layer — Redis or Memcached — in front of the database for the redirect lookup. Cache hit rate should be high since link distribution is typically power-law: 20% of links account for roughly 80% of traffic. Database can be SQL or NoSQL — the schema is trivial with this access pattern. I'd choose SQL for auditability unless we hit horizontal sharding needs.

Notice what the candidate didn't mention: Kafka, CDNs, or microservices. None were needed. Starting with the API contract and read/write ratio made clear exactly what the scale actually required.

Worked Example 2: Designing a Notification System

Interviewer: Design a notification system for a mobile app — push notifications and emails.

Candidate: What types of notifications — transactional only, or also promotional? And what's the volume?

Interviewer: Transactional: order updates, payment confirmations. Up to 5 million per day.

Candidate: What are the latency expectations? Does an order confirmation need to arrive in under a second, or is a few seconds acceptable?

Interviewer: A few seconds is fine for most; under 10 seconds for payment confirmations.

Candidate: Then I'd separate notification creation from delivery. The API that creates a notification should be fast — it writes a record to a queue and returns immediately. A separate consumer handles delivery, calling Apple/Google push services or an email provider like SendGrid. This decoupling means a spike in order volume doesn't block your payment API.

For delivery, I'd have separate worker pools per channel — push and email have very different retry logic. Emails can queue for minutes; push notifications have tighter windows.

Separating notification creation from delivery at the queue boundary is the decisive design choice here — and you need to say it out loud and explain why, not just draw the arrow.

Worked Example 3: Designing a Ride-Sharing Location Tracker

Interviewer: Design the location-tracking component for a ride-sharing app.

Candidate: Who's sending location updates, and who's reading them? Drivers send GPS updates every few seconds, and riders query in real time?

Interviewer: Yes. Drivers update every 3-5 seconds. Riders poll or stream driver location.

Candidate: What's the fleet size — 10,000 concurrent drivers or closer to a million?

Interviewer: Peak 500,000 concurrent drivers.

Candidate: At 500,000 drivers updating every 4 seconds, that's roughly 125,000 writes per second. Standard SQL databases struggle at that write rate without specialized design. I'd use Redis geospatial commands — GEOADD, GEOPOS, GEORADIUS — built for exactly this problem. For riders reading driver location, I'd push updates via WebSocket or Server-Sent Events rather than polling. Polling from a million riders every 3 seconds generates enormous load. A pub/sub layer routes each driver's updates to any rider subscribed to that driver's ID.

The hard part here isn't the write volume — it's routing the right update to the right rider, which is a subscription management problem, not a storage problem.

What Mistakes Do Mid-Level Engineers Make Most Often?

1. Designing the schema before the API. If you don't know what the system needs to do, you can't know what it needs to store.

2. Treating scale as uniform. Not every component needs to scale the same way. In the URL shortener, reads are 100x writes. In the notification system, writes are bursty. Match your scaling decisions to the actual bottleneck, not to an imaginary worst case.

3. Skipping tradeoff articulation. Saying "I'd use PostgreSQL" without saying why leaves the interviewer nothing to evaluate. They know PostgreSQL exists. They want to hear: "I'd choose Postgres because the data is relational, the team has SQL expertise, and 100K QPS reads are within range of a properly indexed cluster."

4. Running out of time before addressing failure modes. At L4-L5, interviewers expect you to mention at least one failure scenario: what happens if the cache goes down, or a queue worker crashes? You don't need to solve it completely — you need to show you thought about it.

5. Accepting scope creep mid-design. If the interviewer says "let's ignore analytics for now," don't sneak analytics back into the design phase. Staying in scope is a signal — it shows you can manage requirements in a real engineering context, not just in code.

Which System Design Framework Should You Use?

Several frameworks exist for structuring this interview. Here's how the most common ones compare:

For most mid-level candidates, Requirements-first is the right default — it mirrors how engineers actually approach building systems, which is exactly what interviewers are calibrating against.

If you're consistently struggling with pacing or depth in design rounds, the issue usually isn't knowledge — it's that you've never had someone stop you mid-session and ask "why did you make that choice?" Practice that format with IntervYou before you need to do it under real pressure.

System design is the one interview round where communication and structure matter more than raw technical knowledge. Most mid-level engineers have enough depth to pass — the ones who don't are skipping requirement-gathering, over-engineering from the start, and never saying the word "tradeoff" out loud.

Start a free mock →

Related reading

• Apple Software Engineer Interview Process Explained
• How to Prepare for a Google Software Engineer Interview
• How to Prepare for a Software Engineer Interview in 4 Weeks