Interview Communication Rules

Coding interviews are collaborative problem-solving sessions, not exams. Half the signal an interviewer collects is how you communicate. A correct silent solution often scores worse than a slightly imperfect one with strong communication.

Core Principles

1. Narrate continuously, but not constantly. Your mouth does not need to track your fingers character-by-character. It tracks your intent.
2. Show your reasoning, not just your conclusion. “I’m choosing a hashmap because we need O(1) lookup by ID” beats silently typing Map<String, Foo>.
3. Two-way street. Pause for confirmation at decision points. The interviewer wants to be involved.
4. Hide nothing. If you’re unsure, say so. If you don’t remember an API, say so. Hiding looks worse than admitting.
5. Forward motion always. Even when stuck, narrate progress: “I’m now going to try a smaller example” is forward motion.

Phase 1 — Opening (first 1–3 minutes)

What to do

• Read the problem fully (don’t start coding)
• Restate it
• Ask clarifying questions
• Confirm constraints

Sample phrases

“Let me read this through once first… OK. So if I understand correctly, I need to [restate]. Is that right?”

“Before I start, can I confirm a few things about the input? Specifically: can the array be empty? Can it contain negative numbers? Are there duplicates?”

“What’s the expected size of N here? Around 10^5? OK, so we’re targeting O(N log N) or better.”

“If there are multiple valid outputs, can I return any one, or is there a specific one expected?”

Anti-patterns

• Starting to code immediately
• Asking 15 questions in a row (drip-feed them as they become relevant)
• Asking questions whose answers are obvious from the problem statement (signals you didn’t read carefully)

Phase 2 — Brute Force (1–3 minutes)

What to do

• State the dumbest correct solution
• Compute its complexity
• Confirm whether it’s acceptable

Sample phrases

“Let me start with the brute force just to anchor. I could check every pair, which would be O(N^2). Given N is up to 10^5, that’s 10^10 operations — too slow. So we need something better.”

“The naive solution is O(2^N) — that’s fine for N=20 but won’t scale. Let me see if we can do better.”

“If we sort first, that gives us O(N log N) for the sort, and then… let me think about the scan.”

Anti-patterns

• Skipping brute force (“I know the optimal already”)
• Computing brute force complexity wrong (always double-check)
• Stating brute force without saying whether it suffices

Phase 3 — Optimization (3–10 minutes)

What to do

• Think out loud
• State observations
• Propose ideas and evaluate them
• Commit to one direction
• Sanity-check before coding

Sample phrases

“I notice the array is sorted, which means I can probably use two pointers…”

“The fact that K is small — only up to 10 — suggests we might want K in our DP state.”

“I see a pattern of repeated subproblems here. Let me define a state: dp[i][j] = …”

“Let me try a small example to verify my recurrence…”

“OK, I think my approach is: sort by start time, then greedily pick. Let me convince myself this works with an exchange argument…”

Anti-patterns

• Switching ideas every 30 seconds without exploring any
• Coding before stating the approach
• Not verifying correctness on a small example

Phase 4 — Coding (10–25 minutes)

What to do

• Narrate intent at function/block boundaries
• Explain non-obvious choices
• Stay quiet during routine syntax
• Ask “is the API I’m assuming OK?” if uncertain

Sample phrases

“I’m going to use a heap here, in Python that’s heapq. Pushing tuples to break ties by ID.”

“For the visited set, I’ll use a hash set rather than a 2D boolean array, since we’re not sure of the bounds.”

“I’m using a sentinel value of -1 to mean ‘not yet computed’ in the memoization.”

“Let me extract this into a helper function — it’ll make the recursion cleaner.”

Anti-patterns

• Silent typing for 5+ minutes
• Constant low-level narration (“now I’m typing a for loop”)
• Going down a rabbit hole on language minutiae mid-flow

Phase 5 — Testing (3–5 minutes)

What to do

• Walk through the given example
• Walk through your own edge cases
• Catch and fix bugs before the interviewer points them out

Sample phrases

“Let me trace through example 1. Initial state: … after iteration 1: … after iteration 2: … final answer: 7. Matches the expected.”

“Edge cases: what if the array is empty? My code would… let me check… yes, it returns 0, which is correct.”

“What about all negatives? Hmm, my initialization assumes a non-negative max. Let me fix that — initialize to negative infinity.”

“I think there’s an off-by-one here. Let me re-examine the loop bound.”

Anti-patterns

• Skipping testing because “the code looks right”
• Testing only the happy path
• Defending broken code when a bug is pointed out (just fix it)

Phase 6 — Complexity & Follow-Ups (2–5 minutes)

What to do

• State time and space
• Mention assumptions
• Engage with follow-ups thoughtfully

Sample phrases

“Time complexity is O(N log N) — dominated by the sort. Space is O(N) for the auxiliary array, or O(1) if we sort in place.”

“Average case for the hashmap is O(1), but worst case is O(N) under adversarial hashing. In Python the dict implementation handles that reasonably well.”

“If we needed to scale this to 10 million users, I’d consider… [sharding / external sort / approximate counters / etc.]”

“If reads were much more frequent than writes, we might precompute and cache.”

Anti-patterns

• Claiming O(N) when it’s actually O(N log N)
• Forgetting space complexity
• Defensive answers to follow-ups (“I’d need more info” instead of engaging)

Handling Hints

If the interviewer gives a hint:

“Ah, that helps — so you’re saying we should [restate]. Let me adjust my approach…”

Then commit out loud to the new direction. Don’t second-guess. Take the hint, integrate it, move forward.

If you need a hint:

“I’ve explored [X] and [Y]. I’m having trouble seeing how to avoid the O(N^2) here. Could you nudge me toward the family of approach?”

A well-asked hint costs you almost nothing. Frozen silence is fatal.

Handling Mistakes

When you find your own bug:

“Hmm, let me re-examine this — I think there’s a bug at line N. Yes, the comparison should be < not ≤. Let me fix that.”

When the interviewer finds a bug:

“Oh, you’re right — the empty case isn’t handled. Let me add a guard.”

Never:

• Argue
• Explain why the bug is “not really a bug”
• Get flustered

Always:

• Acknowledge briefly
• Fix
• Move on

Handling Pressure / Freezing

If you blank:

“Give me 30 seconds to think.” (Then actually think — don’t fake it.)

Then run the stuck protocol. Out loud:

“OK, let me back up. What I know is [X]. The brute force was [Y]. The constraint that’s hinting at something is [Z]…”

Talking through the stuck protocol restarts your thinking and shows the interviewer you have a process for being stuck.

Closing Strong

Final 1–2 minutes:

“To summarize: I’m using [data structure] with [algorithm]. Time is O(…), space is O(…). Edge cases handled: empty, single element, duplicates, max constraints. The main risk in production would be [X], which I’d address by [Y].”

A clean summary leaves the interviewer with a tidy mental model of your work — much better than ending mid-test.

Body Language & Tone (Video / In-Person)

• Sit up. Look at the interviewer when explaining, at the editor when coding.
• Speak at moderate pace. Faster than normal = nervous, slower = padding.
• Avoid filler (“um”, “like”) — silence is preferable to filler.
• Don’t apologize repeatedly. One apology when you fix a bug is enough.
• Show interest in the problem. Curiosity is a positive signal.

Phrases To Avoid

• “This is easy” — even if it is, this can read as arrogant
• “I’ve seen this before” — be careful; if you go on autopilot you’ll miss the variant
• “I don’t know” with no follow-up — replace with “I don’t know X, but I can reason about it via Y”
• “That won’t work” without explanation
• “Just” used dismissively (“we just need to…”)

What Strong Communication Buys You

• Partial credit when your code is incomplete (the interviewer saw your reasoning)
• Hints offered earlier (interviewers want to help engaged candidates)
• Believability of follow-up answers (a candidate who reasoned clearly throughout is trusted on production tradeoffs)
• Hire signal even on hard problems you didn’t fully solve