How to Think Out Loud in a Coding Interview
A four-phase script for coding interview communication: what to say while clarifying, planning, coding, and testing, and how interviewers read your silence.
Short answer: talk in four phases. Clarify the problem before solving it, state a plan in plain English before typing, narrate decisions (not keystrokes) while you code, then trace an example and state complexity out loud. Never go silent for more than about 30 seconds without saying what you are doing.
Candidates who get the algorithm right still lose rounds in two ways: they say nothing, or they say everything with no structure. The interviewer cannot see inside your head, and most of what they write down comes from what you say. Good coding interview communication is also the closest thing a 45-minute round has to watching you work on a real team, where ambiguity, trade-offs, and code review happen daily.
The script below works on LeetCode, in peer mocks, and in AI mock interviews, where you can rehearse it as often as you like.
Why communication counts as much as the answer
When interviewers write up a coding round, the questions they answer look like this:
- Did the candidate break a vague problem into parts?
- Did they surface assumptions before writing code?
- Did they take hints without getting defensive?
- Could they reason about trade-offs with the clock running?
The editor shows your syntax. Your voice shows your judgment. Clear communication on a medium problem often reads as more senior than a silent, perfect solution. What FAANG interviewers score breaks the rubric down further.
The four-phase script
1. Clarify before you solve
Spend one to two minutes confirming the problem. This is not stalling; it is cheap insurance against solving the wrong thing.
Questions worth asking:
- "Can the input be empty? What should I return then?"
- "Can there be duplicates?"
- "Do you want indices or values?"
- "Should I optimize for time, memory, or readability?"
Write two or three small examples in comments, including one awkward case. The interviewer is checking that you match their expectations before you spend ten minutes on the wrong invariant. How to read a coding interview problem has a fuller checklist.
2. State a plan in plain English
Before typing, describe the algorithm in three to five sentences:
- "First I'll ... because ..."
- "That gives me ..."
- "The expensive step is ..., so overall it's O(...)."
If you see more than one approach, name them: "Brute force checks every pair in O(n²). A hash map gets it to O(n) at the cost of O(n) memory." This shows you chose an approach rather than grabbing the first one you thought of.
3. Narrate decisions while coding, not keystrokes
Alternate between:
- Intent: "I'm storing seen values in a hash map so each lookup is O(1) on average."
- Small decisions: "I'll use a half-open range here so the bounds don't go off by one."
- Quiet typing for the mechanical parts. Nobody needs to hear you spell out a for loop.
If you have been quiet for 20 to 30 seconds, say one line: "Still wiring up the loop, one second." Unexplained silence makes the interviewer wonder whether you are stuck. If you actually are stuck, the recovery playbook covers what to say.
4. Test and analyze out loud
Trace your smallest example line by line before you hit run. Then state time and space complexity, and mention one realistic extension or failure mode: "If the array were sorted, two pointers would get space down to O(1)."
Common mistakes and fixes
| Mistake | Fix |
|---|---|
| Starting to code immediately | Force yourself to state a plan for 30 seconds first |
| Apologizing constantly | Replace "sorry" with "let me restate that" |
| Trailing off mid-sentence | Finish sentences; number your steps |
| Ignoring hints | Repeat the hint back: "So you're suggesting I ..." |
| Explaining trivia | Explain why, not every keystroke |
Thinking out loud without rambling
Signpost the structure:
- "There are two parts: building the index, then querying it."
- "I'll handle the empty case first so the main loop stays clean."
Then pause briefly after each signpost. Those pauses are where the interviewer steers you, and steering is a gift.
Practicing with a voice interviewer
TechInView's DSA interview runs 45 minutes with a voice interviewer who moves through clarification, approach, coding, testing, and wrap-up, interrupts with follow-ups, and runs your code. Communication is one of the five scored dimensions; how the AI evaluates shows what it listens for. That loop (speak, get interrupted, recover, continue) is much closer to the real thing than solving silently in a browser tab.
Checklist before you click Run
- I restated the problem in my own words.
- I said my target complexity before coding.
- I explained every non-obvious data structure choice.
- I traced at least one example by hand.
- I stated complexity and one possible extension.
Learn the script once and reuse it on every problem. It gets easier with reps, so start with something small like Two Sum and talk through all four phases even when the answer is obvious.