Interview Strategy & Frameworks | System Design Fundamentals

You know the building blocks now. The question is: can you use them under pressure?

System design interviews are weird. You walk in, someone says "design Uber" or build me a URL shortener at scale, and you have 45 minutes to do what exactly? There's no compiler to check your work. No test suite. Just you, a whiteboard, and someone watching you think.

Here's what took me a while to figure out: they're not looking for the right answer. Two candidates can propose completely different architectures and both get hired. What matters is the thinking process. Can you break down a vague problem? Do you ask the right questions? Can you reason through trade-offs without getting stuck?

That's what this lesson covers.

What We'll Cover

What's actually being evaluated (it's not what you think)
A practical framework you can use for any design question
Questions that make you look good vs. questions that don't
The mistakes that sink otherwise solid candidates
What to do when you genuinely don't know something

What's Actually Being Evaluated

I've been on both sides of these interviews. Here's what's really going on.

What doesn't matter:

Drawing the exact same architecture the interviewer would
Knowing every database or message queue by heart
Producing something you could deploy tomorrow

What does matter:

Breaking down ambiguity. Design Twitter is vague on purpose. Can you turn that into concrete requirements without hand-holding?

Depth where it counts. Anyone can say use Redis for caching. Can you explain when Redis is the wrong choice? What happens when it fails?

Reasoning through trade-offs. Every decision has downsides. Candidates who pretend their design is perfect look inexperienced. Candidates who can articulate I chose X because of Y, but the downside is Z look like people you'd want on your team.

Clear communication. If the interviewer can't follow your thinking, it doesn't matter how good your design is.

Collaboration. Do you listen when they push back? Do you incorporate hints? Or do you bulldoze through with your original plan?

Think of it less like an exam and more like a working session with a colleague.

A Framework That Works: RUSHED

I'm going to give you a structure. Don't follow it robotically. The interviewer can tell when someone's running through a memorized checklist. But having a mental framework keeps you from freezing up or rambling.

R - Requirements (3-5 minutes)

Start by asking questions. This does two things: it shows you don't jump to solutions, and it actually helps you design something sensible.

For Design Twitter, you might ask:

Are we building the full product or focusing on the timeline?
Roughly how many users? Millions? Hundreds of millions?
Real-time updates, or is a few seconds of delay acceptable?
What matters more here: never losing a tweet, or always being able to post?

The interviewer might not answer everything. That's fine. Make reasonable assumptions and state them: I'll assume 200 million daily active users. Let me know if that's off.

U - Understand Scale (2-3 minutes)

Do some quick math. This isn't about getting exact numbers. It's about understanding whether you're building for thousands or billions.

plaintext
200M daily users × 2 tweets each = 400M tweets/day
200M users × 100 timeline views = 20B reads/day
400M tweets × 500 bytes = 200GB/day of new data

Now you know:

Reads vastly outnumber writes (50:1). Caching matters.
200GB/day means ~73TB/year. Single database won't cut it long-term.
Peak writes could hit 230K/second. Need to think about write scaling.

Round aggressively. 387 million becomes 400 million. Nobody cares about precision here.

S - System APIs (2 minutes)

Sketch out the main APIs. This grounds the discussion and forces you to think about what the system actually does.

plaintext
POST /tweets { text, media_ids } → { tweet_id }
GET /timeline { user_id, cursor } → { tweets[], next_cursor }
POST /follow { target_user_id } → { success }

You don't need every endpoint. Just the core ones that drive the design.

H - High-Level Design (10 minutes)

Now draw. Get the main components on the board before diving into details.

Explain the flow as you draw. User posts a tweet, it hits the API server, gets written to the tweet database, and we need to update followers' timelines somehow.

Resist the urge to go deep yet. Get the skeleton down first.

E - Explore Details (20 minutes)

This is where you show depth. Pick 2-3 areas and really dig in.

For Twitter, interesting areas might be:

How do timelines get generated? Push to followers on write, or pull on read?
What happens when someone with 50 million followers tweets?
How do we shard the database as we grow?

Let the interviewer guide you here. If they ask about something specific, that's a hint about what they want to discuss.

D - Discuss Trade-offs

Call out the trade-offs in your design. This is where experienced candidates separate themselves.

We're pushing tweets to follower timelines on write. That means celebrity tweets are expensive. But reads are fast, which matters more since reads outnumber writes 50:1.

We chose Postgres over Cassandra because the team probably knows it better. If we hit scaling limits, we can shard later or migrate. Premature optimization would slow us down.

No design is perfect. Acknowledging limitations shows maturity.

(Wrap up with Edge Cases & Bottlenecks)

Think about what could break.

Celebrity with 50M followers tweets. Do we melt our servers trying to fan out?
Database goes down. What happens to in-flight requests?
Someone tries to spam the system. How do we detect and block it?

You won't solve all of these in 45 minutes. But identifying them shows you think about production systems, not just happy paths.

Time Management

Most interviews are 45 minutes. Here's roughly how to spend it:

Requirements & estimation: 5-8 minutes. Enough to understand the problem, not so long you're stalling.
High-level design: 10 minutes. Get the architecture on the board.
Detailed design: 20 minutes. This is the meat of the interview.
Trade-offs and wrap-up: 5-7 minutes. Discuss what you'd do differently, edge cases, monitoring.

If you're running low on time, say so: I'm conscious of time. Should I keep going with the caching strategy, or would you rather discuss how we'd handle failures? Interviewers appreciate candidates who manage their own time.

Questions That Help vs. Questions That Hurt

The questions you ask tell the interviewer a lot about how you think.

Questions that make you look bad:

What database should I use? You're supposed to reason through that.
Is my design correct? There's no single correct answer.
What would you do? It's your interview, not theirs.

Questions that make you look good:

Should I focus on the timeline experience, or do you want me to cover notifications too? Shows you're thinking about scope.
What's the target latency for timeline loads? Sub-100ms, or is a second acceptable? Shows you know latency matters and varies by use case.
I'm assuming 200 million daily active users. Does that ballpark sound right? Shows you're grounding your design in reality.
Does this high-level architecture make sense before I dive into the database schema? Shows you want feedback and aren't just plowing ahead.

Mistakes That Sink Good Candidates

Jumping straight to solutions. Design a URL shortener. Okay, so we use NoSQL and generate random strings. Stop. Ask questions first. What's the scale? Do URLs expire? What's the read/write ratio? Jumping to implementation signals you don't think before coding.

Not drawing. Talking for 45 minutes without drawing anything is painful for everyone. Even rough boxes and arrows help you organize your thoughts and help the interviewer follow along. Use the whiteboard. If it's virtual, use whatever drawing tool they provide.

Going deep too early. Don't spend 15 minutes on database sharding before you've sketched the overall architecture. Big picture first, then zoom in. Otherwise you might optimize the wrong thing.

Pretending your design is perfect. Every choice has downsides. I chose Redis for caching. It's fast, which we need. The downside is it's another system to operate, and if it fails, we hit the database directly. We'd want replication and a fallback path. That's what a senior engineer sounds like.

Going silent. Two minutes of quiet thinking feels like ten minutes to the interviewer. Think out loud: I'm weighing push versus pull for timelines. Push means writes are expensive but reads are fast. Given our 50:1 read/write ratio, that might be the right trade-off.

Ignoring hints. If the interviewer asks Have you thought about what happens when a celebrity posts? they're telling you to discuss fan-out strategies. Don't get defensive. Incorporate the feedback.

When You Don't Know Something

You will hit questions where you don't know the answer. How you handle this matters more than you'd think.

What not to do: Pretend you know (they'll figure it out), shut down completely, or just say I don't know and wait.

What works:

I haven't used Cassandra in production, but I know it's optimized for write-heavy workloads with eventual consistency. Given our scale, it might fit. I'd want to dig into the consistency model before committing to it.

You're being honest, showing you know something about the technology, and demonstrating how you'd approach learning more.

I'm not sure about the best approach here. In similar situations I've used X. Does that apply, or is there something specific about this problem I should consider?

You're asking for guidance without being helpless.

I haven't built a real-time bidding system, but it sounds like the core challenge is making fast decisions under tight latency constraints. That's similar to rate limiting, which I have worked on. Let me apply that thinking.

You're connecting unfamiliar territory to things you do know.

The ability to reason through unfamiliar problems is often more valuable than having memorized the answer.

Good Answers vs Great Answers

A good answer covers the requirements, has a sensible architecture, mentions some trade-offs, and responds to interviewer questions.

A great answer does all that plus:

Identifies edge cases before being asked (What happens if a celebrity with 50M followers tweets?)
Uses numbers to drive decisions (At 50:1 read/write, caching is essential)
Considers alternatives before choosing (We could do push or pull. Here's why I'm picking push)
Thinks about operations (We'd want to monitor cache hit rates and set up alerts for replication lag)
Adapts when the interviewer pushes back

The difference isn't knowing more stuff. It's thinking more carefully and explaining your reasoning clearly.

How to Practice

Reading about system design only gets you so far. You need to practice actually doing it.

The drill:

Pick a system (Twitter, Uber, Dropbox, whatever)
Set a 45-minute timer
Talk out loud as if someone's listening. This feels weird at first. Do it anyway.
Draw on paper or a whiteboard
When the timer goes off, review what you missed

Good systems to start with:

URL shortener. Simple enough to finish, complex enough to be interesting.
Twitter or Instagram. Timelines, fan-out, caching.
Uber or Lyft. Location data, real-time matching.
WhatsApp. Messaging, presence, delivery guarantees.
Dropbox. File storage, sync, conflict resolution.

After you've done those:

Rate limiter
Notification system
Search autocomplete
Video streaming (Netflix/YouTube)
Distributed cache

When reviewing, ask yourself:

Did I ask clarifying questions, or did I just start designing?
Did I do back-of-envelope math?
Did I explain why I made each choice?
Did I go deep enough on the interesting parts?
Could someone follow my explanation?

The Short Version

If you remember nothing else:

Ask questions first. Understand the problem before solving it.

Do the math. Numbers tell you what matters.

Draw something. Boxes and arrows beat rambling.

Explain trade-offs. Nothing is perfect. Say why you chose what you chose.

Think out loud. Silence makes interviewers nervous.

Listen. If they hint at something, follow the hint.

You don't need the perfect answer. You need a reasonable answer with clear reasoning. The best candidates aren't the ones who know everything. They're the ones who can figure things out and explain their thinking.

Course Complete

Congratulations! You've completed System Design Fundamentals.

You now have the mental models, vocabulary, and frameworks to think about distributed systems and talk about them in interviews.

What to do next:

Practice. Design 10 different systems. Talk out loud. Time yourself. This is the part most people skip, and it's the part that matters most.

Read engineering blogs. Netflix, Uber, Stripe, Discord all publish detailed posts about how they solve real problems. Reading these shows you how the concepts apply in practice.

Build things. Theory only goes so far. Implement a cache. Set up a load balancer. Break things and figure out why they broke.

The best systems aren't the most complex. They're the simplest ones that actually solve the problem.

Wish you all the best.