Courses › Coding Interviews › Getting Started

Communicating While You Code

What to say while clarifying, choosing an approach, coding, testing and when you're stuck.

Interviewers can only score what they can see. Two candidates can write the same code, and the one who explains their reasoning, catches their own bugs and responds well to hints gets the better score. Communication is a skill you can practice like any other. This lesson gives you the words for each stage of the round.

While clarifying

Restate the problem in your own words, then ask about what changes the solution:

  • Input size and constraints: "Up to 10⁵ elements? Then O(n²) is too slow, so I'm aiming for O(n log n) or better."
  • Edge cases: empty input, duplicates, negative numbers, ties.
  • The output format: indexes or values? Any order? What if there's no answer?

Then work through one small example out loud. It catches misunderstandings before they cost you 15 minutes.

While finding an approach

Think out loud, even when your thoughts are incomplete:

"Brute force checks every pair, which is O(n²). The repeated work is looking for a complement, so a hash map of the values I've seen would make each lookup O(1). That gives O(n) time and O(n) space. Does that sound reasonable before I code it?"

That last question matters. Agree on the approach before coding. If the interviewer has concerns, you want to hear them now, not after 20 minutes of code.

While coding

  • Say the structure first: "I'll write a helper that returns the height, and track the diameter in an outer variable."
  • Narrate the decisions, not the syntax. "I'm using a deque so popping from the front is O(1)" is useful. "Now I'm writing a for loop" is noise.
  • Use clear names. Good names are communication the interviewer can read without you.
  • It's fine to go quiet for a bit while writing a tricky section. Say so: "Give me a minute to get this loop right, and then I'll walk you through it."

While testing

Don't just say "I think it works." Trace your code by hand on a small example, saying the values of the key variables at each step:

"i = 0, seen is empty, so we add 2. i = 1, the complement is 7, which is in seen, so we return [0, 1]."

Then go through the edge cases you listed at the start. When you find a bug, say so calmly and fix it. Finding your own bug is a positive signal, not a negative one.

When you're stuck

Silence is the worst option. Make your thinking visible:

  • Say what you know: "I know sorting helps, but I lose the original indexes."
  • Try a simpler version: a smaller input, sorted input, only positive numbers.
  • Go through the patterns: "Could this be two pointers? A heap? Binary search on the answer?"
  • Ask a targeted question: "Is it fine if I use extra memory here?" is better than "Can I get a hint?"

Taking hints well

A hint is the interviewer trying to help you succeed. Take it, build on it, and say how it changes your approach: "Right, if I process the intervals by end time, I can decide greedily. Let me rethink." Arguing with a hint, or ignoring it, does much more damage than needing one.

Wrapping up

End with a summary in one or two sentences: the final complexity, the trade-offs you made, and what you'd improve with more time. "O(n log n) for the sort, O(1) extra space. If the input were streaming, I'd switch to a heap."

[!WARNING] Communication anti-patterns - Coding immediately after hearing the problem - Long silences with no explanation - Narrating every keystroke instead of every decision - Saying "it works" without testing it - Getting defensive when the interviewer points out an issue

[!TIP] Practice this out loud Practice with a friend, or record yourself solving one problem a day while speaking. Most candidates find their narration falls apart the first few times. That's normal, and it improves quickly.