DEV Community: ScaleDojo

Interview Ready (Gaurav Sen) vs Hands-On Practice: What's Missing

ScaleDojo — Mon, 21 Sep 2026 13:24:31 +0000

I spent a solid chunk of my prep time on Gaurav Sen's InterviewReady content before an interview loop, and I want to talk honestly about what it gave me and what it didn't-because I think a lot of people (including past me) treat "I watched all of Gaurav Sen's videos" as equivalent to "I'm ready," and those are not the same thing.

What InterviewReady actually is

Gaurav Sen is an ex-Google engineer and a genuinely excellent teacher. InterviewReady's content is built around deep, first-principles explanations of distributed systems concepts-consistent hashing, distributed consensus, operational transformation (the algorithm behind Google Docs' real-time collaborative editing), and coverage of systems most courses skip, like chess engines and live video streaming infrastructure.

There are also bi-weekly live Zoom sessions, which is a nice touch-direct instructor access is rare in this space.

What it gets right

The teaching quality is legitimately some of the best I've encountered. Gaurav doesn't hand you a memorized framework and call it a day-he actually explains why a distributed system behaves the way it does, at a level of depth that sticks with you. If your goal is building genuine intuition for how distributed systems work, not just passing an interview, this content delivers.

The gap I ran into

Here's the thing that became obvious about three weeks in: I could explain every concept Gaurav taught. I could not, at first, actually design something from scratch without freezing, because watching someone else reason through a problem and reasoning through one yourself are different skills that don't automatically transfer.

InterviewReady is fundamentally a video-first platform. There's no interactive sandbox where you build something yourself and get told what's wrong with it. You're watching a brilliant engineer think out loud, which is valuable-but it's passive. The muscle that actually gets tested in an interview is the one where you're the one thinking out loud, under a bit of pressure, with someone occasionally pushing back.

What actually closed the gap for me

I ended up supplementing InterviewReady with ScaleDojo, specifically because it's built around the opposite thing-instead of watching an explanation, you're on an interactive canvas actually assembling the architecture yourself, submitting it, and getting AI-scored feedback on the specific decisions you made. It's not a replacement for the depth InterviewReady gives you; it's the practice rep that depth alone doesn't provide.

A rough way I'd describe the difference: InterviewReady taught me why consistent hashing works the way it does. ScaleDojo was where I actually had to decide, cold, whether a given problem called for it-and got told specifically when I was wrong.

Who should use InterviewReady

If you learn well through deep, patient, first-principles explanation and you want real conceptual grounding before you start producing designs yourself, it's an excellent starting point. Just don't mistake finishing the video library for being interview-ready-the name is a little aspirational in that specific sense.

The honest takeaway

Depth and practice are two different inputs, and you probably need both. InterviewReady is one of the best sources I've found for the first one. It's worth pairing with something that forces you to actually build, not just understand, before you assume you're ready for the real thing.

ML System Design vs GenAI System Design: What's Actually Different

ScaleDojo — Sat, 19 Sep 2026 14:42:49 +0000

I got asked to "design a machine learning system" in one interview and "design a GenAI system" in another, about two weeks apart. I walked into the second one assuming it was basically the same interview with different vocabulary.

It was not. And figuring out why took me embarrassingly longer than it should have.

Same energy, different everything

Both interviews start the same way: someone describes a product, and you're expected to design the system behind it. But the actual engineering problems underneath are pretty different, and conflating them is an easy way to give an answer that sounds right but misses what the interviewer is actually probing for.

Classic ML system design: prediction is the product

Think recommendation engines, fraud detection, search ranking, ad click prediction. The core loop looks like this:

Collect and process training data (often at massive scale, often messy)
Train a model offline
Serve predictions online, usually with a strict latency budget
Monitor for model drift and retrain periodically

The hard problems here are things like: how do you keep training data and serving data consistent (the classic training/serving skew issue)? How do you A/B test a new model safely? How do you handle a feature store that needs to serve both batch and real-time features?

It's fundamentally a data pipeline and prediction-serving problem. The model itself is often treated as a black box you're building infrastructure around.

GenAI system design: retrieval, generation, and control are the product

Now think RAG-powered support bots, AI coding assistants, document Q&A systems. The shape of the problem is completely different:

Retrieval: how do you find the right context to feed the model (chunking strategy, embeddings, vector search)?
Generation: which model do you call, how do you prompt it, how do you handle streaming responses?
Control: how do you keep the model from hallucinating, leaking data it shouldn't, or going off-script?

You're usually not training a model from scratch-you're orchestrating a pipeline around a model someone else built. The hard problems are things like keeping a knowledge base fresh without full re-indexing, routing between cheap and expensive models based on query complexity, and designing guardrails that catch bad outputs before a user sees them.

Where people mix them up

The most common mistake I see (and made myself) is bringing classic ML instincts into a GenAI interview. If someone asks you to design a RAG system and your answer is mostly about training data pipelines and model evaluation metrics, you're solving the wrong problem-the LLM itself usually isn't something you're training, so that entire section of classic ML system design doesn't apply here.

The reverse mistake also happens: bringing RAG/prompt-engineering instincts into a classic ML interview, like suggesting you'd "prompt" a fraud detection model, which doesn't map onto how that kind of system actually works.

A rough way to tell which one you're in

Ask yourself: is the interviewer's problem centered on predicting a number or a label from structured data (churn probability, fraud score, ranking position)? That's classic ML system design.

Is it centered on generating or retrieving unstructured content in response to a query (an answer, a summary, a piece of code)? That's GenAI system design.

If you're not sure which one you're being asked, it's a completely fair clarifying question to ask out loud-"just to confirm, are we training a model here, or orchestrating around an existing LLM?" Interviewers generally respect that question, because it shows you know the two are different disciplines instead of assuming they're the same skill with new terminology slapped on.

Why this gap matters more in 2026

Two years ago, most system design interviews with an ML flavor were classic ML system design. That's shifting fast-GenAI-flavored questions (RAG pipelines, AI agent architecture, vector database design) are showing up regularly now, especially at companies building AI-native products, and a lot of interview prep material hasn't caught up. It's easy to prep the "old" version of the ML interview and get blindsided by the new one.

I ended up leaning on ScaleDojo's GenAI Systems Lab specifically to close this gap-it's a dedicated track for RAG pipelines, AI agent design, vector databases, and model routing, separate from classic HLD/LLD practice, which turned out to be exactly the distinction I was missing.

If your prep has only ever covered one of these two flavors, it's worth checking which one, before you find out the hard way in an interview which one you were actually asked.

Why ScaleDojo Is the Best System Design Learning Platform for Aspiring Engineers

ScaleDojo — Wed, 16 Sep 2026 11:55:20 +0000

I'll be upfront: I'm writing this after trying most of the "big name" system design resources first-the video courses, the diagram-heavy blogs, the flashcard decks. Not because they're bad, but because none of them actually made me better at designing systems. They made me better at recognizing good designs when I saw them, which is a completely different skill.

Here's why ScaleDojo ended up being the one that actually moved the needle for me.

The problem every other resource has in common

You can watch fifty hours of system design videos and still freeze the moment someone asks you to build something from scratch. This isn't a knowledge gap-it's a practice gap. Watching someone else design a system trains pattern recognition. It does not train the muscle of actually producing an architecture yourself, under a little pressure, with someone asking follow-up questions.

Almost every popular system design resource is built around reading or watching. ScaleDojo is the first one I used that's built around building.

What it actually is

ScaleDojo is a hands-on system design practice platform-think of it less like a course and more like the LeetCode of system design. Instead of reading about how to design a rate limiter, you're on an interactive canvas actually dragging in load balancers, connecting services, and wiring up the data flow yourself.

It's organized into a few focused labs:

HLD Architecture Lab — the classic big-picture stuff: load balancers, caching, message queues, service boundaries

LLD Schema Design Lab — database schema design on an actual ER canvas, not a diagram you're just supposed to memorize

API Design Lab — REST endpoint design, pagination, error handling-the part almost every other resource skips entirely

GenAI Systems Lab — RAG pipelines, vector databases, AI agent architecture, which is genuinely the newest and most underserved part of system design prep right now

The part that actually changed how I practice

Every submission gets scored, and then reviewed by an AI Architect that tells you specifically what you got right, what you missed, and what a senior engineer would have done differently. That loop-build, get specific feedback, fix it, build again-is the entire thing that was missing from every book and video course I'd used before.

It's not asking "is your diagram correct." It's asking does this actually hold up,and telling you exactly where it doesn't.

Who this is actually for

If you already understand the concepts-you know what a load balancer does, you've heard of consistent hashing-but freeze when asked to apply any of it live, this is built for exactly that gap. It's less useful if you're a complete beginner with zero foundation; pair it with a good book or video series first to build the mental models, then come here to turn that understanding into an actual skill.

The honest bottom line

I'm not saying skip everything else. Read the books, watch the videos that explain the internals well-that part still matters. But at some point you have to stop reading about system design and start actually doing it, with something in front of you that tells you when you're wrong and why. That's the gap ScaleDojo closed for me, and it's why it's the one resource out of everything I tried that I'd actually recommend first.

I Practiced 50 Mock Interviews. Here's What Actually Changed

ScaleDojo — Wed, 16 Sep 2026 11:20:14 +0000

I Practiced 50 Mock Interviews. Here's What Actually Changed.

I used to think I was ready. I'd read the classic problems, I could explain consistent hashing on a whiteboard by myself, I had my mental model of a rate limiter down cold. Then I sat in front of an actual interviewer, and about four minutes in, I completely lost the thread of my own answer.

Not because I didn't know the material. Because I'd never once said any of it out loud, to another person, who could interrupt me.

That gap is what this post is actually about.

The skill nobody tells you to practice

Everyone practices knowing system design. Almost nobody practices performing it under mild social pressure,
which is a completely different skill.
Here's the thing that took me way too long to figure out: an interview isn't a knowledge test. It's closer to a
performance. You're not being graded on whether the "correct" architecture exists somewhere in your head-you're being graded on whether you can produce it, live, while someone occasionally says "wait, why not just do X instead?"

Reading doesn't train that. Only doing it, badly, in front of someone, over and over, trains that.

What actually happened over 50 mock interviews

I'm not going to pretend the first ten were good. They weren't. Here's roughly how it went:

Interviews 1–10: pure chaos. I rambled. I jumped straight to a solution without asking a single clarifying question.
When someone pushed back on a choice, I either caved immediately or got defensive. Both are bad.

Interviews 11–25: structure started showing up. I stopped jumping to solutions. I started asking about scale,read/write ratio, latency requirements-not because I memorized a checklist, but because I'd been burned enough times by skipping it.

Interviews 26–40: the pushback stopped being scary. This was the real shift. Early on, "why not use a cache here?" felt like an attack on my design. By interview 30-ish, it just felt like a normal part of the conversation-something to reason through, not defend against.

Interviews 41–50: I started enjoying it, which is a weird sentence to type. Somewhere around here the format
stopped being the hard part. The actual system design problem became the interesting part again, the way it should
be.

The specific things that only mock practice fixes

A few things I genuinely don't think you can fix by reading more:
• Rambling. You don't know how much you ramble until you hear yourself do it in real time with no script.
• Freezing when challenged. The first few times someone questions your design, it feels personal. It stops
feeling personal only through repetition.
• Skipping requirements gathering. It's obvious in hindsight when you're reading someone else's clean
write-up. It is not obvious when you're the one staring at a blank whiteboard.
• Explaining trade-offs instead of just naming them. "I'd use a cache" is not an answer. "I'd use a cache here
because reads outnumber writes 100:1 and staleness for a few seconds is fine" is. You only notice the difference
once someone asks you "why?" a few dozen times.

If you don't have 50 people to practice with

Most people don't have unlimited access to willing interviewers, which is the actual bottleneck here, not motivation.
A couple of things that helped me bridge that:

• Practicing out loud alone still beats not practicing out loud at all-record yourself if you can stand to listen back.

• Trading mock interviews with peers who are also prepping works, but the quality varies a lot depending on how
good they are at pushing back.

• I ended up leaning on ScaleDojo's Mock Interview Arena for a good chunk of these reps-it's built specifically for this gap, alongside their hands-on HLD, LLD, API design, and GenAI/RAG labs, so the practice isn't just"explain your design" in a vacuum, it's tied to the same kind of hands-on architecture work you'd actually be building.

The honest takeaway

If your prep has been mostly reading and watching, that's not wasted time-you need the mental models. But at some point, the highest-leverage thing you can do stops being "read one more article" and becomes "get one more rep of saying it out loud to someone who'll push back."

I wish I'd figured that out around mock interview 5 instead of mock interview 25.

What Happens When You Actually Kill a Server Mid-Design (Not Just Read About It)

ScaleDojo — Wed, 09 Sep 2026 12:57:23 +0000

Most system design content teaches you to draw the "correct" final architecture. Almost none of it makes you sit through the moment where that architecture breaks.

That gap is a problem, because "does your design survive failure" is exactly what senior and staff interviews probe for. So I want to walk through one specific scenario end to end-build it, break it, watch the metrics, fix it-the way it actually plays out when you're doing this hands-on instead of just describing it on a whiteboard.

The setup: a URL shortener, the "easy" level

Everyone starts system design prep with a URL shortener, so let's use it. Baseline design:

Client → Load Balancer → Web Server → Database
Web server handles hash generation and lookups
Single database, no replication yet

On paper this looks fine. It passes the "does it work" check. It does not pass the "does it survive Tuesday afternoon" check, and that's the part most prep material skips entirely.

Now break it

This is where I've been using ScaleDojo's Murphy's Lab, a chaos engineering simulator built directly into the HLD challenges. Instead of just submitting a diagram and getting a checkmark, you can inject real failure conditions into the running system and watch it respond live:

Crash a specific server
Spike incoming traffic
Sever a network connection between components
Watch latency, error rate, and throughput update in real time as the system reacts

Run that crash scenario against the baseline design above and here's roughly what happens: your single web server goes down, the load balancer has nowhere to reroute traffic, error rate climbs hard, and if your database was co-located or under-provisioned, you get cascading latency on top of it. Nothing about the diagram was "wrong" in a static sense-it just wasn't built to survive the failure it eventually met.

That distinction matters a lot in an interview. A candidate who can point at a diagram and say "this is correct" is worth less than a candidate who can say "this specific part fails first, and here's why."

What the fix actually looks like

Once you've watched the failure happen instead of just imagining it, the fixes stop being abstract vocabulary and start being specific responses to a specific symptom:

Redundant web servers behind the load balancer-so one crash doesn't take down the whole path
Database replication with a read replica-so read traffic doesn't die with the primary
Circuit breakers-so a failing dependency doesn't take the whole request chain down with it
Graceful degradation-return cached or partial results instead of a hard failure when a downstream service is unhealthy
Auto-recovery / health checks-so the load balancer stops routing to a dead instance without a human intervening

Rebuild the architecture with those in place, rerun the same crash scenario, and the difference in the live metrics is immediate-latency stabilizes, error rate recovers instead of climbing, throughput holds. You're not trusting that the fix works because a textbook said so. You watched it hold up against the exact failure that broke the first version.

Why this is the part interviews actually test

The "design a URL shortener" prompt is never really about URL shortening. It's a vehicle for the interviewer to ask "what happens when this breaks," usually multiple times, with the constraints shifting each time. If your prep has only ever involved reading about replication and circuit breakers-never actually watching a system fail without them and recover with them-you're rehearsing vocabulary, not the skill.

This is also why static diagram-based prep tends to produce candidates who can describe fault tolerance patterns but freeze slightly when asked to reason through this specific failure, in this specific system, right now. The knowledge is there; the rep under pressure isn't.

If you want to run through this exact scenario yourself, Murphy's Lab is free to try on the URL shortener level-no signup required to start.

Curious what other failure scenarios people think are underrated in interview prep-network partitions and thundering herd don't get nearly enough attention compared to "the database died." What's on your list?

DSA Practice That Mirrors Real Company Problems (Uber, Netflix, Stripe)

ScaleDojo — Tue, 08 Sep 2026 13:20:59 +0000

I've done my time grinding random dsa interview questions off a list, in whatever order they happened to appear. It works, sort of-you get faster at recognizing patterns. But it never quite felt like it was preparing me for what actually gets asked in a real interview at a company that's solving real infrastructure problems.

Here's the thing nobody tells you early enough: most DSA prep is abstract. "Reverse a linked list." "Find the longest substring without repeating characters." Useful for building pattern recognition, but disconnected from why any of it matters.

The gap between LeetCode-style prep and real interviews

Companies like Uber, Netflix, and Stripe don't ask DSA questions in a vacuum. They ask them because their actual systems have to solve these problems at scale-routing a ride request efficiently, deduplicating a video encoding queue, rate-limiting a payments API without dropping legitimate traffic. The algorithm is the same one you've drilled a hundred times; the framing is what's different, and framing is exactly what trips people up in a live interview.

If your dsa interview questions practice has only ever been abstract, the first time you meet a company-specific framing is going to be in the interview itself. That's a bad place to encounter it for the first time.

Why grounding practice in real infra problems changes the skill

When a DSA problem is dressed up as "design the algorithm behind Uber's driver-matching queue" instead of "implement a priority queue," something shifts. You're not just retrieving a memorized pattern-you're mapping a real constraint (drivers need to be matched fast, fairness matters, cancellations happen mid-match) onto the right data structure. That mapping step is the actual skill interviewers are testing, and it's the one pure LeetCode grinding barely touches.

This is the exact gap I was trying to close when I started working through ScaleDojo's Forge Algorithm Lab-76 challenges built around real infrastructure scenarios from Uber, Netflix, Stripe, and Discord, supporting both Python and Java. Instead of "here's an abstract array problem," it's "here's a queue deduplication problem shaped like the one Netflix's encoding pipeline actually has to solve."

What this looks like in practice

A few examples of the framing shift:

Instead of "implement a rate limiter" → design the rate limiter a payments API needs to survive a traffic spike without dropping legitimate requests
Instead of "find shortest path" → route a ride request through the fewest hops under real-time constraints
Instead of "deduplicate array" → deduplicate a video processing queue without losing order guarantees

Same core algorithms. Completely different level of readiness when an interviewer asks the company-specific version instead of the textbook one.

If you've only ever practiced the abstract version

It's worth deliberately switching at least part of your prep to scenario-framed problems before your next interview. You don't need to abandon the fundamentals-you need to practice applying them the way they'll actually be asked. That's been the single biggest shift in how ready I feel walking into a DSA-heavy round, and it's a different kind of confidence than knowing the pattern in isolation.