Communicating while you code

Interviewers cannot grade thoughts they cannot hear. Narrate at the level of intent: what the window means, why the inner loop is O(n), which helper you will write first. Do not narrate every keystroke. Do not go mute for five minutes.

The big idea

After you leave, interviewers typically score problem-solving, coding quality, communication and sometimes speed. A correct solution with muddy names and no tests can still land a weak yes. An almost-finished solution with a clear approach, careful edge-case talk and collaborative recovery from a bug can land a strong yes.

Optimize for the packet, not for feeling clever. If two approaches are similar in complexity, pick the one you can implement cleanly.

Walking through it

Intent, not keystrokes:

• "I'll keep a window [left, right] and a map of character → last index."
• "This inner loop is O(n), so overall we're O(n²) — I'll try hashing the complement next."
• "I'm going to write the helper for DFS first, then call it for each unvisited node."

When you are stuck: declare what you know ("brute force is clear; the hard part is avoiding recomputation"), try a smaller example, or ask if a particular approach is worth pursuing. Asking "should I optimize for time or is O(n²) acceptable for n ≤ 1000?" is clarifying, not cheating.

Handling hints: treat them as gifts. Restate the hint in your own words, adjust the plan and continue. Arguing with the interviewer or ignoring the hint wastes the remaining time. Using a hint and finishing strong still often passes; freezing after a hint fails.

Language choice: pick one language and know its interview toolkit cold. Python is popular because of concise collections (Counter, deque, heapq, bisect). Java and C++ are fine if that is where you are fastest. Do not learn a new language for interviews in the last two weeks. If you remember a helper, use it and say what it does — unless they ask you to reimplement it.

Bugs at minute 40: stay calm. Name the failure, patch, re-run the example. Interviewers expect bugs; they watch how you handle them — the same skill as debugging at work.

If the problem is truly unfamiliar, fall back to: correct brute force → identify bottleneck → apply the nearest pattern → communicate residual risks. A clear partial is better than a clever wrong answer.

Onsite stamina is a skill: hydrate, reset between rounds and do not replay the last problem while the next interviewer is introducing themselves. One rough round is survivable; cascading tilt is not.

Common mistakes

• Silent struggle. No signal for the interviewer. Narrate the stuck point; accept a hint.
• Arguing with a hint. Restate it and continue.
• Clever-but-muddy. The packet records names, tests and recovery, not how smart the trick felt.

Check yourself

1. You are stuck after brute force. What do you say first?

What you know, what is hard ("avoiding recomputation"), and a smaller example or a yes/no on an approach.

2. The interviewer hints at a hash map. What do you do?

Restate the hint in your own words, change the plan, and keep coding. Do not freeze or debate.

Key takeaways

• Narrate intent: invariants, complexity, next helper.
• Hints are gifts; restating them is part of the score.
• Recover from bugs by naming them, fixing them and re-testing out loud.

Further learning

Python idioms that save time (collections, heapq, slicing):

Next: practical coding rounds.