"Make sure you think out loud!"
It's the most common piece of interview advice on the internet. But for most developers, it translates into nervously narrating every keystroke: "Okay, now I'm typing let i = 0... then I'm making a for loop..."
That's not thinking out loud. That's audio transcription.
Interviewers don't need you to read your code to them. They can see your screen. What they can't see is the invisible decision tree in your head. Why did you choose a Set instead of an Array? What edge cases are you worried about? Why are you restructuring that function?
Here is a concrete framework for explaining your code like a senior engineer.
The "PREP" Communication Framework
When faced with an interview problem, structure your communication using the PREP method: Plan, Reason, Execute, Prove.
1. The Plan Phase
Never touch the keyboard until you've successfully communicated your plan and the interviewer has given you the green light.
What it sounds like:
"To solve this, I'm thinking of using a two-pointer approach. I'll start one pointer at the beginning and one at the end. Since the array is sorted, I can move them inward based on the sum. This will give us an O(n) time complexity, which is better than the O(n^2) brute force. Does that approach make sense?"
2. The Reason Phase
As you start setting up your variables and structures, narrate the why, not the what.
❌ Bad (Narrating typing):
"I'm creating a
const map = new Map()..."
✅ Good (Narrating reasoning):
"I'm going to use a Map here instead of a standard object because I want to keep track of the insertion order, and I'll need to do frequent lookups."
3. The Execute Phase
While you're in the thick of coding, you don't need to talk constantly. Silence is fine when you're actually writing a tricky block of logic. The key is to "bookmark" your silence.
If you need a moment to think, tell the interviewer.
Don't just freeze. Say: "Give me just a moment to think through the logic for this while loop condition." This transforms awkward silence into productive, professional thinking time.
4. The Prove Phase
Once you finish writing, do not say "Done!" and wait for the interviewer to run the tests.
Take the initiative to prove your code works. Pick a small, non-trivial test case and trace it verbally.
What it sounds like:
"Let's trace this with the input
[2, 7, 11, 15]and a target of9. On line 12,iis 0 andnums[0]is 2. The complement is 7. We check the map on line 14—it's not there. So we add{2: 0}to the map. Next iteration..."
Practice Makes Perfect
Explaining code while writing it is not a natural human behavior. It requires splitting your brain's processing power between logic and language.
The only way to get good at it is to practice it out loud, in an empty room, until you feel slightly crazy.
Tired of practicing in an empty room? Rubduck is designed specifically to train this skill. Our AI interviewers listen to your explanations and grade your communication, not just your code. Start practicing for free.