What do I say when I'm just thinking and don't have an answer yet?

Narrate the tradeoffs you're weighing. 'A hash map gives me O(1) lookup but costs O(n) space — let me check if the input size makes that worth it' is thinking out loud. Silence reads as stuck even when you're not.

Won't talking slow my coding down?

Yes, by maybe 20-30%. That's the trade. A medium problem you solve in 25 minutes while narrating beats a medium you solve in 18 minutes in silence, because the interviewer needs to grade your reasoning — and they can only grade what they hear.

What if my interviewer doesn't respond when I talk?

Keep narrating. The interviewer is often deliberately quiet to see if you stay grounded without affirmation. Look for micro-signals — leaning in, taking notes, typing — but don't fish for a reaction. Their job is to observe, not to coach.

How do I think aloud without sounding scripted?

Talk like you'd talk to a coworker pair-programming with you. Real sentences, real pauses, real 'huh, that won't work' moments. Practiced narration that sounds rehearsed is worse than honest narration that occasionally stumbles.

Do I have to talk the entire time, even during simple parts?

No. Narrate setup, decisions, and tradeoffs. Stay quiet during pure typing of obvious lines. Constant chatter on every variable name tanks signal density just as badly as silence does.

Guide · coding-prep

How to Think Aloud During a Coding Interview

Narrate your reasoning, not your typing. Say what you see, what you considered, and what you ruled out — then code. Silent coding reads as either lucky or stuck; verbal coding reads as engineering, and engineering is what's being graded.

By Alex Chen, Founder, InterviewChamp.AI · Last updated 2026-05-19

How do you think aloud during a coding interview?

Narrate three things: what you understand about the problem, the tradeoffs you're weighing, and the reasoning behind every decision. You're not commenting your code — you're letting the interviewer watch you think. The grade is for reasoning quality, not typing speed, and reasoning quality only counts if it's audible.

What to narrate (and what to skip)

Talk about the things an interviewer would otherwise have to guess at:

Problem reframing. "So the input is a list of intervals — possibly overlapping — and I need to return the merged set. Sorted by start time, I'm guessing? Let me confirm."
Approach selection. "Brute force would be O(n²) by comparing every pair. I think I can do better with sorting and a single sweep, which would be O(n log n). Let me sketch that."
Tradeoffs you ruled out. "I considered a hash map, but ordering matters here, so a hash drops the structure I need. Sorting first preserves it."
Edge cases as they occur to you. "What if intervals share an endpoint — does [1,3] and [3,5] merge into [1,5] or stay separate? I'll assume merge for now and confirm."

Skip narration on the trivial parts. You don't need to say "I'm naming this variable result." You do need to say "I'm using a stack because I'll only ever look at the most recent merged interval."

The pause-don't-stall technique

When you genuinely need to think, announce the pause:

"Let me think for thirty seconds. I want to make sure the optimization I'm reaching for actually beats the brute force on space."

This is the single most underused move in coding interviews. A silent thirty-second stare reads as panic. A narrated thirty-second pause reads as discipline. The Pragmatic Engineer's writing on interview signal notes that engineers who explicitly mark thinking time consistently score higher than those who don't — even when their final solutions are the same.

After the pause, return with a one-sentence verdict: "Okay — sticking with the sort-and-sweep. Coding now."

Talking while typing

The hard part isn't talking when you're thinking. It's talking while you type. Three patterns that work:

1. Pre-line announce. Before writing a non-trivial block, say what it does. "I'm going to iterate through the sorted intervals, and for each one, either extend the top of the stack or push a new entry." Then code in near-silence for that block. Then re-emerge.

2. Decision-point narration. When you hit a fork — picking a data structure, choosing between recursion and iteration, deciding whether to mutate the input — say which way you're going and why. Don't make the interviewer guess.

3. Live debug. When you spot a bug, say it. "Wait — if the new interval starts before the top of the stack ends, I shouldn't push, I should extend. Let me fix that." Catching your own bugs out loud is one of the strongest signals you can give. Per Indeed Career Guide research on interview performance, interviewers explicitly rate "self-correction" as a positive signal even when the initial bug was avoidable.

What to do when the interviewer interrupts

When they push back ("Are you sure that's O(n)?"), don't get defensive. The script:

"Let me trace through that. The outer loop is O(n). The inner — wait, you're right, the inner is amortized O(1) but worst-case O(n) on this input. So worst-case it's O(n²). Good catch — let me fix that."

This is a gift, not an attack. The interviewer is showing you exactly which part of your reasoning was unclear or wrong, and giving you a chance to repair it on the record. The candidates who win the interruption are the ones who treat it as collaboration.

Practicing the skill

Thinking aloud feels unnatural until you've done it ~10 times under timer. Two drills that build it fast: record yourself solving a medium out loud and watch the recording (most people are shocked by how little they say — aim for one decision-narration every 60-90 seconds), and pair-program a problem on a video call where the friend can only hear your narration. If they can't follow your reasoning, the interviewer can't either.

The technical bar at most companies is lower than candidates assume; the communication bar is higher. Narrating the thinking is what closes that gap.

About the author: Alex Chen is the founder of InterviewChamp.AI and writes about the modern tech interview from the inside — what changed, what works for new grads, and where the old playbook fails.

Frequently asked questions

What do I say when I'm just thinking and don't have an answer yet?: Narrate the tradeoffs you're weighing. 'A hash map gives me O(1) lookup but costs O(n) space — let me check if the input size makes that worth it' is thinking out loud. Silence reads as stuck even when you're not.
Won't talking slow my coding down?: Yes, by maybe 20-30%. That's the trade. A medium problem you solve in 25 minutes while narrating beats a medium you solve in 18 minutes in silence, because the interviewer needs to grade your reasoning — and they can only grade what they hear.
What if my interviewer doesn't respond when I talk?: Keep narrating. The interviewer is often deliberately quiet to see if you stay grounded without affirmation. Look for micro-signals — leaning in, taking notes, typing — but don't fish for a reaction. Their job is to observe, not to coach.
How do I think aloud without sounding scripted?: Talk like you'd talk to a coworker pair-programming with you. Real sentences, real pauses, real 'huh, that won't work' moments. Practiced narration that sounds rehearsed is worse than honest narration that occasionally stumbles.
Do I have to talk the entire time, even during simple parts?: No. Narrate setup, decisions, and tradeoffs. Stay quiet during pure typing of obvious lines. Constant chatter on every variable name tanks signal density just as badly as silence does.