Why Interviewers Care About Narration at All
An interviewer watching you code in silence only sees the end result, which tells them almost nothing about how you got there or how you would behave on a real team facing a hard bug. Talking through your reasoning gives them visibility into your process: how you break down a problem, how you weigh tradeoffs, and how you recover when something does not work. Many interviewers explicitly grade on this, sometimes as heavily as they grade correctness.
It also helps you. Saying your plan out loud before coding forces you to notice gaps in your own logic earlier than you would by just staring at the screen.
Narrate the Plan Before You Write Any Code
State your understanding of the problem in your own words first, including any constraints you were given. Then describe your intended approach at a high level before writing a single line, something like naming the data structure you plan to use and roughly why. This single habit prevents the most common failure mode, which is coding for several minutes in the wrong direction because you jumped straight to implementation.
- Restate the problem to confirm you understood it correctly
- Mention your first idea and whether it is a brute force approach or your best guess at an optimal one
- State the rough time and space complexity you are aiming for before you start typing
What to Say While You Are Actually Writing Code
You do not need to narrate every keystroke, which becomes exhausting for both of you. Narrate decisions, not syntax: why you chose a hash map instead of a list, why you are handling a specific edge case now instead of later, or why you are naming a variable a certain way to keep the logic readable. When you hit something uncertain, say so directly rather than going silent, for example noting that you are not sure whether a built-in function handles negative numbers and that you will check.
If you realize partway through that your approach is not going to work, say that out loud too. Interviewers see this constantly and generally respect a candidate who catches their own mistake and adjusts far more than one who never says anything is wrong and quietly struggles.
How to Talk When You Get Stuck
Going silent when stuck is the single biggest way candidates lose points that have nothing to do with actual ability. Instead, describe what specifically you are stuck on: is it the algorithm, a syntax detail, or an edge case you cannot reason through. Naming the specific obstacle often reveals the next step on its own, and it also gives the interviewer a natural opening to nudge you in the right direction if they choose to.
A useful habit is to think out loud about two or three possible next steps and say which one you want to try first and why, rather than freezing until the perfect idea appears.
Practicing This Skill Deliberately
Narrating your thinking out loud feels unnatural at first because most people solve problems silently by default. Practice it deliberately by solving a few practice problems while actually speaking out loud to an empty room, or by explaining your solution to a friend after the fact as if they were watching you solve it live. Recording yourself once or twice and listening back is uncomfortable but genuinely useful, since it reveals whether you tend to trail off, go quiet under pressure, or narrate too much unimportant detail.
The goal is not a scripted performance, it is building the habit so that when real interview pressure hits, narrating your thinking feels like your default mode rather than an extra task competing for your attention.
Useful Phrases If You Are Not Sure What to Say
If narrating out loud feels awkward at first, having a few reliable phrases ready can make it feel far more natural than trying to invent commentary on the spot. Before coding, something like 'I am going to start with a brute force approach because it is straightforward, and then look at optimizing it' sets expectations clearly. While coding, 'I am choosing a hash map here because I need constant time lookups' explains a decision without narrating syntax.
When checking your work, 'let me trace through this with a small example to make sure the logic holds' signals a verification habit. When something feels off, 'I think there might be an issue here, let me look closer' is far better than silence, and when you are genuinely unsure, 'I am not fully certain this handles negative numbers correctly, let me check' is honest without sounding like you are failing.
- Use short, declarative sentences rather than long, hedging ones
- State the reason behind a decision, not just the decision itself
- Say when you are checking something, not just when you have already found a problem
These are starting points, not a script to memorize word for word. The goal is to build the habit of narrating decisions until it feels like your normal way of working rather than a performance layered on top of it.
Do Not Stop Narrating Just Because Things Are Going Well
It is common for candidates to narrate carefully at the start of a problem and then go quiet once the code is flowing smoothly, treating narration as something only needed during difficulty. Keep narrating through the easy parts too, briefly noting what each block of code is accomplishing, since a long stretch of silence can make an interviewer unsure whether you are still thinking clearly or simply typing on autopilot.
A short running commentary, even something as simple as noting you are now handling the edge case you identified earlier, keeps the interviewer oriented on your progress the entire time, not just during the hard parts.