How to think aloud in a coding interview

A silent candidate who reaches a working solution gives the panel very little to write down. A candidate who reaches a slightly worse solution while explaining every decision gives them a page of evidence: they understood the problem, they knew the tradeoffs, they caught their own bug. When panels compare notes afterwards, the second candidate is usually easier to say yes to.

Thinking aloud is a skill, and like any skill it has a structure you can learn. Here is the five-part script we recommend, with the exact kind of sentence that works at each step.

1. Restate the problem and pin down the inputs

Before you touch the keyboard, say the problem back in your own words and ask about the inputs. This catches misreadings early, and it shows the interviewer you do not start building before you know what you are building.

"So I'm given an array of integers and a target, and I return the indices of two numbers that add up to the target. Can the array have duplicates? Is there always exactly one answer, and can I use the same element twice?"

Good questions to have ready for almost any problem:

• How large can the input get? (This decides whether O(n²) is acceptable.)
• Can it be empty, or contain negatives, duplicates, or nulls?
• Is the input sorted? Can I modify it in place?
• What should happen when there is no valid answer?

2. Say the brute force first, with its cost

Name the simplest correct approach and its time and space complexity, even if you already see a better one. It proves you can always fall back to something that works, and it gives you a baseline to improve on out loud.

"The straightforward way is to check every pair — two nested loops, O(n²) time, O(1) extra space. That works, but with n up to 10⁵ it's about 10¹⁰ comparisons, so I want something better."

3. Explain the better approach before you code it

This is the step candidates skip most often, and it is the one that matters most. Tell the interviewer the idea, the data structure, and why it is faster — then ask whether they are happy for you to code it. If your idea has a flaw, you find out now, not fifteen minutes into the implementation.

"If I store each number's index in a hash map as I go, then for each element I can check in O(1) whether target minus that element has already appeared. One pass, O(n) time, O(n) space. I'm trading memory for time. Shall I go ahead with that?"

If the interviewer pushes back or hints at something else, that is useful information, not a failure. Adjust and say why you are adjusting.

4. Narrate while you code — the decisions, not the syntax

You do not need to read every line aloud. "Now I'm writing a for loop" adds nothing. Narrate the decisions: why this structure, why this condition, what this variable means.

• "I check the map before inserting, so an element can't pair with itself."
• "I'm returning early here because the problem guarantees one answer."
• "I'll name this seen so it's clear it maps value to index."

When you go quiet to think — and you will — say so. "Give me a moment to think about the edge case where the array is empty" is far better than thirty seconds of silence the interviewer cannot read.

5. Dry-run it, then state the final complexity

Before you say "done", walk a small example through the code by hand, line by line. Pick one normal case and one edge case. This is where most candidates catch their own off-by-one errors, and catching your own bug in front of the interviewer is a strong signal, not a weak one.

"Let me trace [2, 7, 11, 15] with target 9. At index 0, 9 − 2 = 7 isn't in the map, so I store 2 → 0. At index 1, 9 − 7 = 2 is in the map, so I return [0, 1]. Correct. For an empty array the loop never runs and I return the empty result. Final complexity is O(n) time and O(n) space."

Common ways thinking aloud goes wrong

• Narrating syntax instead of reasoning. The interviewer can read the code. Tell them what they cannot see: why.
• Going silent when stuck. Silence is the hardest thing to grade. Say what you are considering and what is blocking you — interviewers often hint when they can see where you are.
• Coding before agreeing on the approach. If you build the wrong thing quickly, you have still built the wrong thing.
• Never saying the complexity. If you do not state it, the interviewer has to ask, and that reads as a gap.
• Skipping the dry run. "I think it works" is weaker than showing it works on an example.

How to practise this

Solving problems silently on a practice site does not train this skill, because nobody is listening. You need to say the words out loud while someone asks follow-up questions. Two ways to do that:

1. With a friend. One of you solves, the other interviews and interrupts with "why?" at least twice per problem. Swap roles. Record it and listen back once — you will hear the silences.
2. With Meera on mangoose.tech. The coding round opens an editor that Meera can see while you talk. She asks follow-ups the way a panel does, and the gap report afterwards notes whether you stated your approach before coding, dry-ran your solution, and said the complexity out loud — alongside how correct and efficient the code was.