System Design Interview: A Practical Guide for Mid-Level Engineers

Why System Design Suddenly Matters at L4+

Here's something nobody tells you when you're grinding LeetCode: once you hit mid-level (L4 at Google, E4 at Meta, SDE II at Amazon), the coding rounds are only half the battle. System design becomes a make-or-break signal. And it's a completely different skillset than algorithm puzzles.

I watched a colleague — brilliant coder, could solve hard LeetCode problems in 15 minutes — bomb three senior-level interviews in a row. The reason? He'd freeze up when asked "design a URL shortener" because there's no single correct answer. It's open-ended and that freaked him out.

The truth is, system design interviews test how you think about building real software. Can you handle ambiguity? Do you understand trade-offs? Can you communicate technical decisions clearly? That's what senior engineers do every day, and that's what interviewers are looking for.

The Typical Format (and Why It Trips People Up)

Most system design rounds are 45-60 minutes. You'll get an open-ended prompt like "Design Instagram" or "Design a chat system." From there, it's on you to drive the conversation.

This is where most candidates mess up immediately. They hear "design Twitter" and start drawing boxes on the whiteboard — databases here, servers there, a load balancer somewhere. No requirements. No constraints. Just vibes.

Don't do that. The interviewer gave you a vague prompt on purpose. They want to see you clarify it. That's part of the evaluation.

A Framework That Actually Works

After sitting on both sides of these interviews, here's the structure I've seen work consistently:

Step 1: Requirements Gathering (5-7 minutes)

Ask questions. Lots of them. For "Design Twitter," you'd want to know:

• Are we focusing on the tweet feed, posting, or both?
• How many users? 10 million? 500 million? This changes everything.
• Do we need real-time updates or is polling okay?
• What about media — images, videos, or just text?
• Read-heavy or write-heavy? (Twitter is massively read-heavy.)

Write down functional and non-functional requirements. It takes two minutes and it shows you're methodical.

Step 2: High-Level Design (10-15 minutes)

Now sketch the big picture. Don't get into implementation details yet. Draw the main components: client, API gateway, services, database, cache. Show the data flow.

For a Twitter-like feed, your high-level design might include:

• A Tweet Service to handle posting
• A Fan-out Service to distribute tweets to followers' timelines
• A Timeline Service to fetch a user's feed
• A User Service for profiles and follow relationships

Step 3: Deep Dive (15-20 minutes)

Pick two or three components and go deep. The interviewer will usually steer you toward what they care about. This is where you show your depth.

For the fan-out service, you'd discuss: do we fan out on write (pre-compute everyone's timeline when a tweet is posted) or fan out on read (assemble the timeline when someone opens the app)? For celebrities with 50 million followers, fan-out-on-write is insanely expensive. So you'd use a hybrid: fan-out-on-write for normal users, fan-out-on-read for celebrities.

Step 4: Trade-offs and Scaling (5-10 minutes)

This is where strong candidates separate themselves. Talk about what could go wrong. What are the bottlenecks? How would you handle 10x traffic? What if the database goes down?

The Concepts You Actually Need to Know

You don't need a PhD in distributed systems. But you need to be comfortable with these building blocks:

Load Balancing. Distributing traffic across multiple servers. Know the difference between round-robin, least connections, and consistent hashing. When someone asks "what happens when one server goes down?" — that's a load balancer question.

Caching. Redis and Memcached are your friends. Know cache-aside vs. write-through vs. write-behind patterns. Understand cache invalidation — it's genuinely one of the hard problems in CS, and saying that in an interview shows awareness.

Database Sharding. When your single database can't handle the load, you split it across multiple machines. Horizontal sharding by user ID is common. But what about queries that need data from multiple shards? That's where it gets tricky.

CDN. Content delivery networks for static assets, images, videos. If your system serves media to a global audience, a CDN isn't optional — it's essential.

Message Queues. Kafka, RabbitMQ, SQS. When you need asynchronous processing — sending emails, processing uploads, fan-out — a message queue decouples your services and handles spikes gracefully.

Worked Example: Design a URL Shortener

Let me walk through this one since it's probably the most common system design question out there.

Requirements I'd clarify: How many URLs shortened per day? (Let's say 100 million.) How long should shortened URLs be? Do they expire? Do we need analytics (click counts)?

Back-of-envelope math: 100M URLs/day = ~1,160/second. Each URL entry is maybe 500 bytes. That's about 50 GB/day of new data, 18 TB/year. We'll need to plan for storage growth.

URL generation strategy: Base62 encoding (a-z, A-Z, 0-9) gives us 62^7 = 3.5 trillion possible 7-character strings. More than enough. We could use a counter with a hash, or pre-generate IDs with a service like Snowflake.

Architecture:

• API servers behind a load balancer
• A key-value store (DynamoDB or Cassandra) for URL mappings — reads are way more frequent than writes
• A cache layer (Redis) for hot URLs — the top 20% of URLs get 80% of traffic
• Analytics pipeline using Kafka to process click events asynchronously

Trade-offs I'd mention: Pre-generating IDs is faster but needs a coordination service. Hashing is simpler but you need collision handling. NoSQL gives us horizontal scaling but loses ACID transactions. Each choice has a cost.

Common Questions You Should Practice

Beyond the URL shortener, make sure you can talk through these at a high level:

1. Design a chat system — WebSockets, message ordering, offline delivery, group chats
2. Design a news feed — fan-out strategies, ranking algorithms, real-time vs. batch
3. Design a rate limiter — token bucket vs. sliding window, distributed rate limiting
4. Design a notification system — push vs. pull, priority queues, delivery guarantees
5. Design a file storage service — chunking, deduplication, metadata storage, sync

Mistakes I See All the Time

Jumping straight to the solution. Spending 30 seconds on requirements and then drawing a complex architecture nobody asked for. Slow down. Ask questions.

Over-engineering. Not every system needs Kubernetes, a microservice architecture, and three levels of caching. Start simple. Scale when there's a reason to.

Ignoring trade-offs. Every design choice has a downside. If you're only presenting upsides, the interviewer knows you haven't thought it through. "We could use a relational database for strong consistency, but if we're expecting 100K writes per second, we might want a NoSQL store and accept eventual consistency."

Not doing the math. Back-of-envelope calculations show you can reason about scale. How much storage do we need? How many requests per second? What's the latency budget? These numbers inform design decisions.

How to Actually Prepare

Reading about system design isn't enough — you need to practice explaining designs out loud. Grab a whiteboard (or a blank page) and talk through a design as if someone's listening. Time yourself. If you can't explain your URL shortener design in 35 minutes, you're not ready.

Work through 8-10 designs thoroughly rather than skimming 30 superficially. Depth beats breadth here. And practice with a real person when you can — the back-and-forth with an interviewer is half the challenge.

If you want to simulate that experience, Craqly's AI interview copilot can run you through system design questions with follow-up probes, just like a real interviewer would. It's surprisingly good at pushing you on weak spots.

System design interviews reward engineers who think clearly under pressure. You don't need to memorize architectures — you need to practice thinking through problems out loud. Start with the framework, learn the building blocks, and practice until it feels natural.