There's a thing interviewers talk about after debriefs that candidates never hear about.
It's not "they solved it" or "they didn't solve it." It's "I had no idea what they were thinking." That note — sometimes those exact words — shows up in more rejection decisions than people realize. Not because the candidate failed the technical problem. Because the interviewer spent 45 minutes watching someone type and came away with basically no signal about how their mind works.
You can solve the problem correctly and still get that note.
The fix is thinking out loud. And before you say "yeah, I know I should do that" — most people who know they should do it still don't, because they've never actually practiced it until it feels natural. It's one of those skills that's obvious in theory and awkward in practice.
Here's how to actually get good at it.
Why interviewers care about this so much
The interview question isn't really the point. It's a vehicle. The interviewer's actual question is: what is it like to work through a hard problem with this person?
A candidate who goes silent for 20 minutes and then presents a correct solution gives the interviewer almost nothing to work with. Were they stuck? Did they get lucky? Do they consider edge cases proactively?
A candidate who narrates their thinking answers all of those questions richly.
They want to see how you decompose problems, how you handle uncertainty, whether you catch your own mistakes, and how you react when a first approach does not work. You can only show them those things if you are talking.
There's also a practical upside: if the interviewer can hear where your thinking is going wrong, they can help you. A small hint at the right moment can save 10 minutes of spinning. But they can only hint if they know where you are.
The full verbal arc of a good interview
Thinking out loud isn't just "say stuff while you code." It has a shape — a flow that covers the whole session:
Most candidates do the last two steps occasionally. Hardly anyone does all six consistently. Let's break down what each one actually looks like.
Restate the problem. Before anything else, say the problem back in your own words, briefly. "So we're finding two numbers in an array that sum to a target." This confirms you understood it and gives the interviewer a chance to correct you before you go down the wrong path.
Ask clarifying questions. Don't assume. "Can I use the same element twice? Are there duplicates? Is there always exactly one answer?" Even if the answers are obvious, asking shows you think about constraints before you build. This is the engineering instinct interviewers are actually testing.
Name your approach (and why) before writing code. Not just "I'll use a hash map" — but "I'll use a hash map to store complements as I iterate, which gets to O(n). The two-pointer approach would also work on a sorted array, but since ours isn't sorted that adds O(n log n) — so hash map is cleaner here." That 15-second explanation is worth more signal than the next 10 minutes of code.
Narrate while coding. Not line by line — intent, not mechanics. "I'm storing the complement here so I can check for it in O(1) later..." When you hit uncertainty, name it: "Let me make sure I'm not using the same index twice..." Naming your own doubts is not a weakness. It shows careful thinking.
Trace a test case out loud. Once you're done, walk through an example step by step. Say what each variable is at each point. The interviewer will catch things with you, which is the whole point.
Name edge cases. "What if the input is empty? What if there are no valid pairs?" You don't have to handle all of them — but naming them shows you've thought past the happy path.
What it looks like when it goes wrong
Most verbal anti-patterns are recognizable once you know what to look for. Here's the honest breakdown:
| Anti-pattern | What to do instead |
|---|---|
| The silent coder: writes the whole solution without a word, then explains at the end | Commit to narrating before you type — even a rough "I am going to try a hash map approach" is infinitely better than silence |
| The over-hedger: "I am not sure, but maybe we could possibly use..." | Be assertive. Say it once if you are uncertain: "I think hash map is right here — let me try it." Then commit. |
| The solution-describer: explains what the code does, not why | Explain intent, not mechanics. "I am tracking character frequencies so I can check duplicates in O(1)" — not "here I increment the counter." |
| The freeze-and-apologize: goes silent, then "sorry, I know there is a better way..." | Narrate the stuck-ness. "I am not seeing a path below quadratic time — let me think about whether sorting first helps..." That is just a person thinking. |
When candidates freeze and start apologizing, it almost always makes things worse — now the interviewer is managing your anxiety on top of everything else. A calm "let me think through this out loud" is always better than "sorry, I am just..."
The practice routine that actually works
Here's the uncomfortable truth: you can't just decide to "think out loud more" and have it work under pressure. Under pressure, you revert to habits. If your habit is silence, silence is what you'll do when it matters.
You will feel ridiculous talking to yourself. Do it anyway. That ridiculousness is you closing the gap between thinking and saying.
The bigger picture
Here's something worth sitting with: thinking out loud isn't just an interview skill.
Every code review, design discussion, debugging session, and architecture conversation you'll ever have at a job requires the same thing — organizing your thoughts in real time, explaining your reasoning to other people, updating your approach when new information comes in.
The interview is, in this sense, actually a reasonable proxy for what they're hiring for. The candidate who can do that — who makes the 45-minute session feel collaborative — tends to be good to work with, not just good at puzzles.
So yes, practice thinking out loud because it'll help you get the offer. But also: you're practicing a skill that'll matter every day after.
Rubduck is a spoken-first interview simulator that listens to how you explain your thinking — not just what you code. The AI interviewer responds to what you say, asks follow-ups, and gives feedback on your communication. Try a free interview here.