You've read the system design primer. You've gone through hundreds of LeetCode solutions. You can mentally trace through a B-tree insertion. But when the interviewer asks you to "walk me through how you'd design a URL shortener," your mind goes blank.
Most developers have experienced some version of this. You spend hours reading about a topic, feel confident about it, and then someone asks you to explain it and you realize... you can't. Not clearly. Not in a way that sounds like you actually understand it.
The illusion
There's a specific thing that happens when you read about a concept: your brain registers familiarity and interprets it as understanding. You read about how database indexing works, the explanation makes sense, and you think "ok, I know this." But making sense of someone else's explanation is not the same as being able to produce your own.
I noticed this when I was prepping for a system design interview a couple of years ago. I'd read about event sourcing — understood the diagrams, nodded along to the examples, felt good about it. Then I tried to explain it out loud, and what came out was: "So basically, you store events instead of current state, and then... you can replay them? And there's a read model that's eventually consistent, I think?"
That's not an explanation. That's a half-remembered summary of someone else's explanation. I'm a frontend developer — I don't work with event sourcing daily. And it showed the moment I tried to produce my own words instead of recognizing someone else's.
Here's what bothers me about this, though. I'd spent maybe two hours reading about event sourcing that week. Two hours. And I couldn't produce a coherent 30-second explanation. What were those two hours actually worth?
What happens when you say things out loud
The gaps become obvious immediately. When you're reading, your brain fills in missing pieces automatically. When you're speaking, you hit a gap and there's just... silence. You either know the next step or you don't. No hand-waving. No skimming past the hard part.
You build the actual skill the interview tests. Interviews don't test whether you can read about distributed systems. They test whether you can explain them in real time, under mild pressure, to someone who's evaluating you. Reading practices the wrong skill. Speaking practices the right one.
Your explanations develop structure. The first time you try to explain something out loud, it comes out messy. By the third time, you've naturally developed a sequence: you start with the problem, explain the mechanism, mention the trade-offs. This structure doesn't come from reading about "how to structure answers" — it emerges from the act of trying to say coherent things and failing enough times.
I want to be careful not to oversell this, though. Speaking out loud doesn't magically fix knowledge gaps. If you don't understand how a hash map works, saying it out loud won't help. It just makes the gap painfully visible, which is a different thing. Useful, but not the same as learning.
The production gap
Musicians don't get better by listening to music. Athletes don't improve by watching game tape. But developers preparing for interviews? They mostly read. Articles, textbooks, solution write-ups. For hours.
The gap between consuming information and producing explanations is the single biggest blind spot in how most people prepare. It feels productive to read for three hours. It feels uncomfortable to speak out loud for five minutes. But the five minutes of speaking will improve your interview performance more than the three hours of reading.
I keep coming back to this ratio and it still seems wrong. Five minutes versus three hours. But every time I've tested it — on myself, watching candidates — it holds up.
What changes when you start doing this
The first few times you try explaining something out loud, it's painful. You stumble on concepts you thought you knew. You trail off mid-sentence because you realize you don't actually understand the next step. You use the word "basically" four times in 30 seconds.
After about a week of doing it regularly — even just one concept a day — something shifts. Your explanations start having a shape. You instinctively start with the problem, not the solution. You mention trade-offs without thinking about it.
There's a side effect I didn't expect: you start studying differently. Instead of passively reading, you read something and immediately try to explain it out loud. If you can't, you go back and re-read. The explaining becomes the test, and the reading becomes targeted instead of aimless. Whether this actually leads to "better" understanding or just better interview performance, I'm honestly not sure. Probably both. Maybe just the second one. Either way, it works for the thing you care about right now.
The hard part
Talking out loud to yourself feels weird. Hearing your own stumbling explanation is uncomfortable. There's no immediate feedback — nobody's telling you "that was good" or "you lost me at the third sentence."
I keep thinking there should be a way to make this less awkward. There probably isn't. The discomfort is the whole mechanism. Interviews are uncomfortable. The candidates who handle them well are the ones who've already practiced being uncomfortable.
If you're preparing for an interview right now, try this: pick one concept you expect to be asked about. Don't look it up. Just explain it out loud, right now, for 60 seconds.
Notice where you stumbled. That's where your prep should go tomorrow.
Top comments (0)