How to Think Out Loud in a Coding Interview (With a Worked Example)

To think out loud in a coding interview, say what you are deciding before you do it: restate the problem, name an approach and what it costs, outline the code, narrate each block as you write it, and test it aloud on an example. You are not narrating keystrokes. You are making each decision audible, so the interviewer can follow your reasoning, and step in before a wrong turn costs you ten minutes.

What thinking out loud is, and what it is not

A coding interview is assessed through what the interviewer can see and hear. Meta's own preparation guide puts it plainly: "Thinking out loud gives the interviewer insight into your thinking process." If you solve the problem silently and then present the answer, the interviewer saw the answer but not the thinking, and the thinking is most of what they were asked to judge. A strong silent solution and a lucky one look the same from across the table.

That does not mean a running commentary. "Now I type for, now i, now in range" tells the interviewer nothing they cannot read. What they want is the reasoning a teammate would want in a design review: what you noticed, what you considered, what you chose and why. Think of it as narrating decisions, not actions.

It also changes what kind of interview you are in. When the interviewer can hear your plan, they can correct a misread constraint after thirty seconds instead of after you have coded the wrong thing. Most interviewers want you to succeed and will nudge you, but only if they know where you are.

The five moments to talk

You do not need to talk at a constant rate. You need to talk at the points where a decision is made. In a coding problem there are five:

1. Understanding. Restate the problem in your own words and ask the questions that change what you would build. Which clarifying questions to ask has the list.
2. Approach. Say the simplest approach that works and its cost, then whether you can do better and how. Interviewers want to hear the brute force named even if you never write it.
3. Plan. Before typing, give the outline in two or three sentences: the data structure, the main loop, what you return.
4. Coding. Narrate each block as you finish it: what it does and why it is there. Silence while you type a few lines is fine if you said what you were about to write.
5. Testing. Trace your code on the example out loud, line by line, then name the edge cases and check each one.

A worked example, from the first minute to the last

Here is one problem from Devana's bank, reach a promotion threshold from a cart: given a cart total, a threshold and the prices of items the customer viewed, suggest the cheapest single item that gets the cart to the threshold, or if no single item does, the cheapest pair. This is what thinking out loud sounds like through the whole problem.

1. Understanding

You: So the cart is short of the threshold, and I want the cheapest thing to add that gets it over. One item if any single item is enough, otherwise two. Let me check a couple of things before I pick an approach.

You: If the cart already meets the threshold, I return an empty list, right? And if nothing works, even the two most expensive items together, also an empty list?

Interviewer: Yes to both.

You: Can the same price appear twice, and can a pair use two items with the same price?

Interviewer: Prices can repeat. A pair is two different items, so yes, if the price appears twice.

You: And roughly how many candidates? Tens, or hundreds of thousands?

Interviewer: Say up to a hundred thousand.

Three questions, and each one changes the code: the empty cases, whether a pair can repeat a price, and whether a quadratic search is acceptable. Notice that the candidate restated the problem first. That alone catches a large share of misunderstandings.

2. Approach

You: First I'll turn it into one number: need is the threshold minus the cart total. The brute force is to check every item for the single, then every pair with two loops. That's O(n squared), and with a hundred thousand items that's ten billion pairs, too slow.

You: If I sort the prices, both halves get easy. The cheapest single item that covers the gap is the first price at or above need, which is a binary search. For the pair, I can put one pointer at the cheapest and one at the most expensive. If they reach need, that's a candidate and I try a cheaper right side. If they don't, the left price is too small for anything still in range, so I move it up. Each step rules out one price, so the pair search is linear. Sorting dominates: O(n log n).

Interviewer: Why is it safe to move the left pointer up when the sum is too small?

You: Because the right pointer is already the largest price we haven't ruled out. If the left price can't reach need with that, it can't with anything smaller.

The candidate named the brute force and its cost, said why it fails at this size, proposed something better, and gave its complexity, all before writing a line. The interviewer probed one step, which is a good sign: they are engaging with the approach rather than trying to find out what it is.

3. Plan

You: So the code is: compute need and return early if it's zero or less. Sort a copy of the prices. Binary search for the single and return it if found. Otherwise the two-pointer loop, keeping the cheapest qualifying pair, and return it or an empty list.

4. Coding

You: Give me a moment to write the setup and the binary search, then I'll walk you through it.

A short, announced silence is fine. Then the candidate explains the block they just wrote:

You: Here I'm using bisect_left on the sorted prices with need, so I get the first index where the price is at least need. If that index is inside the list, that price alone is enough and it's the cheapest one that is, so I return it.

You: Now the pair loop. While lo is less than hi, so the two pointers are always different items. If the total reaches need, I record it only if it's strictly cheaper than my best, then move hi down. Otherwise I move lo up.

Interviewer: Why strictly cheaper?

You: So that if two pairs cost the same, I keep the first one I found, which has the cheaper first item. It makes the answer deterministic.

5. Testing

You: Let me trace the example: cart 40, threshold 50, prices 15, 8 and 20. Need is 10. Sorted: 8, 15, 20. The binary search for 10 lands on index 1, which is 15, so I return 15. Correct, since 8 only gets us to 48.

You: Edge cases: cart already over the threshold returns empty at the top. An empty list skips both searches and returns empty. A single item that is too small: the binary search misses, and the loop never runs because lo equals hi. And two items of 5 with need 10: the pointers start on different items, so 5 plus 5 is found.

That is the whole interview, and none of it is a performance. Every line spoken is either a decision, a reason, or a check. You can read the full solution, in Python and JavaScript, with hints and follow-ups, on the problem's page.

Talking while you code without losing your place

The hardest part is the middle, when you are writing code and talking at once. Most people cannot do both well at the same moment, and you do not have to. Use a cycle instead: say what the next block will do, write it with little or no talk, then explain what you wrote. Three habits help:

• Announce the silence. "Give me thirty seconds to write this loop." The interviewer now knows the quiet is planned.
• Leave anchors. A short comment such as # cheapest single item before each block gives you a place to point to when you explain it, and keeps you oriented if you are interrupted.
• Say when you change your mind. "Actually, I don't need the map here, the sorted array is enough." A visible correction reads as judgment. A silent rewrite reads as confusion.

Phrases you can use

• "Let me restate it to make sure I have it: ..."
• "The simplest thing that works is ... It's O(n squared), which is too slow for n of a hundred thousand."
• "I think we can do better, because the input is sorted / we only need the top k / we've seen this value before."
• "Before I code it, here's the plan: ..."
• "I'll write the helper first, then the main loop."
• "This line handles the empty case."
• "Let me trace it on the example."
• "One edge case I want to check is ..."
• "I'm not sure about this part yet. My guess is ..., and I'll come back to it."

When you genuinely cannot see the way forward, the phrases change. What to do when you get stuck in a coding interview has a ladder of what to say, step by step, and what to say when you don't know the answer covers the questions where the gap is knowledge rather than an idea.

Mistakes that make thinking out loud backfire

• Narrating syntax. Reading your code aloud as you type adds noise and hides the decisions.
• Talking only when asked. Answering questions is the minimum; the point is to explain before you are asked.
• Apologizing for every pause. "Sorry, sorry, one second" draws attention to the hesitation. State what you are doing instead.
• Asking permission at every step. "Is it okay if I use a hash map?" Propose and continue: "I'll use a hash map here, which gives O(1) lookups."
• Going silent when the code breaks. A bug is the moment the interviewer most wants to hear your reasoning.
• Talking so much you never write code. Ten minutes of discussion on a forty-minute problem is plenty before you start.

How to get better at it

Thinking out loud feels unnatural because daily programming is silent. It improves with repetition, and only with repetition out loud: reading this page does not change how you sound at minute twenty. Solve problems aloud with a timer, record a few and listen back, and then do it in front of someone who asks questions. How to practice interview communication on your own compares the ways to do that, and how interviewers score communication shows what the effort buys.

For material, the worked problems by pattern each have hints and a "how to say it in the interview" section, and the pattern guides explain how to talk through each pattern. To practice with someone listening, Devana's AI coding mock interviews run by voice with an editor that executes your code. Its coding rubric gives thinking out loud 25 of the 100 communication points, and communication is 60% of a coding round's score.

Frequently asked questions