How to Communicate During Interviews
A candidate can reach the optimal solution and still leave without an offer. The code may be correct, but if the reasoning stays hidden, the interviewer has little to evaluate beyond the final answer.
In interviews, your thought process matters as much as your code. Solving without explanation hides your approach, trade-offs, edge cases, and decision-making.
Good communication is not about sounding polished or talking nonstop. It is about making your reasoning easy for another engineer to follow.
Why Communication Carries So Much Weight
Consider two candidates working through the same problem.
Candidate A reads the question, stays quiet for a few minutes, and then writes a correct O(n) solution. When asked, "why did you use a hash map?", they reply, "because it's faster."
Candidate B takes a different approach. They start by saying, "we're looking for pairs that sum to a target, so this feels like a complement problem." They clarify a few edge cases, briefly walk through a brute-force idea, explain why it's O(n²), and then move to a hash map solution, explaining how it improves the time complexity to O(n).
Both candidates arrive at the same answer.
What separates them is the visibility of their reasoning. Candidate B's process can be followed step by step, which lets the interviewer score the approach in addition to the result, and which more closely resembles how engineers solve problems together at work.
Phase 1: Asking Clarifying Questions
When you first hear the problem, resist the urge to start coding right away.
Spend a minute or two asking a few thoughtful questions. It helps you avoid unnecessary mistakes, clears up ambiguity early, and gives you a clean starting point before you begin solving.
What to Ask
- Input constraints: "What is the range of input sizes? Can the array be empty? Can values be negative?" These questions help you avoid running into edge cases halfway through your solution.
- Expected behavior: "If there are multiple valid answers, should I return any one of them or all of them? What should I return if no solution exists?" Small ambiguities like this can completely change your implementation.
- Data characteristics: "Is the input sorted? Are there duplicate values? Can I assume the input fits in memory?" These questions directly influence which approach makes the most sense.
- Modifications allowed: "Can I modify the input array, or should I treat it as read-only?" This affects whether in-place algorithms are viable.
Example: Two Sum
Here's how a strong candidate might begin:
"So we have an array of integers and a target sum, and we need to find two numbers that add up to the target. A few questions before I dive in. Can the array contain duplicate values? Can I use the same element twice? Is there always guaranteed to be exactly one solution? And are we looking for the indices or the values themselves?"
In about a minute, that opening clarifies the problem and removes the main sources of ambiguity before any code is written.
Questions to Avoid
Avoid asking things that are already clearly mentioned in the problem. It makes it seem like you didn't read it carefully.
Also avoid open-ended questions like "any hints?" before you've even tried to think through the problem. It's better to take a moment, gather your thoughts, and then ask more focused questions if you get stuck.
Phase 2: Explaining Your Approach Before Coding
Before any code gets written, walk through the plan out loud: what you intend to build and why. A short explanation up front organizes your own thinking and gives the interviewer a chance to redirect you before time gets spent on the wrong approach.
A Simple Structure That Works
A good approach explanation follows this pattern:
- State the core observation: What's the key insight behind your approach?
- Mention the technique (if applicable): If this is a known pattern like sliding window, two pointers, or BFS, call it out.
- Walk through the high-level steps: Keep it simple. Think 3 to 5 steps, not detailed pseudocode.
- State the complexity: Give a quick sense of time and space, and why.
Example: Approach Explanation
"My first thought is the brute force approach where we check every pair, but that would be O(n²). We can improve this using a hash map. The idea is that for each element, we know the complement we're looking for, which is target minus the current value. So as we iterate through the array, we check if that complement is already in the map. If it is, we've found our pair. If not, we store the current element and continue. This brings the time complexity down to O(n) with O(n) extra space."
That explanation takes about 20 seconds, and in that time it conveys the thought process, the move from a baseline to a better solution, and the plan the code is about to follow.
When the Interviewer Pushes Back
A follow-up like "can you think of another approach?" or "what about the space complexity?" usually means the interviewer wants to go deeper into the trade-offs, not that the current approach is wrong.
Phase 3: Narrating While Coding
Once you start coding, try not to go completely silent.
It's natural to focus and get lost in the code, but long stretches of silence make it hard for someone else to follow what's happening. A little bit of narration goes a long way in making your thinking visible.
The goal isn't to explain every line. Just give enough context so that someone watching you can follow your decisions.
What to Narrate
- Structural decisions: "I'll start by initializing the hash map, then iterate through the array." This shows you are following the plan you described.
- Why you chose something: "I'm using a HashMap here instead of an array because the values could be negative or very large." Voicing the reason shows the choice was deliberate.
- When you are handling edge cases: "Let me add a check for an empty array at the top." This makes the happy path and the edge cases easy to tell apart in the code.
- When you change direction: "Actually, I realize I need to check the complement before inserting, not after, otherwise I might match an element with itself." Catching and fixing your own mistake in real time is exactly the kind of self-correction that happens during normal engineering work.
What Not to Narrate
Don't read your code line by line. "Now I'm declaring i, incrementing i…" doesn't add value.
Also avoid filling every pause with "let me think…" repeatedly. A short silence to think is fine; constant filler talk is not.
Finding the Right Balance
The rhythm to aim for is mostly coding, with short bursts of explanation in between.
After a few lines, briefly say what you just did or what comes next. It should feel like walking another engineer through your thinking, not like lecturing.
Constant narration is unnecessary, and so are long silent stretches where the interviewer can no longer tell what is being worked on.
Phase 4: Discussing Trade-Offs
A working solution is rarely the end of the conversation. The discussion that follows often centers on trade-offs: how the solution would change if memory were tighter, the input were larger, or the access pattern were different.
Trade-Off Categories
| Category | What to Discuss |
|---|---|
| Time vs Space | "We could reduce space to O(1) with a two-pointer approach, but that requires sorting the input first, which adds O(n log n) time." |
| Simplicity vs Performance | "The recursive solution is cleaner, but the iterative version avoids stack overflow for large inputs." |
| Generality vs Specificity | "This works for any hash-able type, but if we know the inputs are small integers, we could use an array for better cache performance." |
| Preprocessing vs Query Time | "We spend O(n) upfront to build the hash map, but each lookup is O(1). If we had multiple queries, this amortizes well." |
How to Bring Up Trade-Offs Naturally
You don't need to wait for someone to ask. Once you've confirmed your solution works, you can add:
"So this runs in O(n) time and O(n) space. If memory were a constraint, we could sort the array first and use two pointers to bring space down to O(1), but that would cost us O(n log n) time. For most practical cases, the hash map approach is preferable since memory is cheap and we want the faster runtime."
A line or two like this connects the current solution to how it would behave under different constraints, which is the same kind of reasoning that comes up during real design discussions on the job.
Signaling When You Are Stuck vs Silent Struggling
Getting stuck during an interview is a normal part of the process. The way that moment is handled is often what decides how it gets scored.
The Wrong Way: Going Silent
A common reaction to being stuck is to go quiet and try to work everything out internally. From the outside, that silence is hard to read: there is no way to tell whether the candidate is close to the answer, going in the wrong direction, or fully blocked. After a minute or two, the round starts to feel stalled.
A Better Approach: Think Out Loud
When stuck, the most useful thing to do is say what is currently going through your head.
For example:
"I know I need to find the shortest path, so BFS seems right. But I'm not sure how to handle the constraint that we can only visit each node once with a specific state. Let me think about whether I need to track visited states differently."
That one sentence is enough to expose the current line of reasoning and pinpoint where the blocker is, which often turns a stalled round into a usable conversation again.
Asking for Hints the Right Way
There's a big difference between:
"I'm stuck, can you give me a hint?"
and
"I'm considering using a priority queue here, but since all edges have equal weight, I'm wondering if a regular queue would work just as well. Does that make sense?"
The second one shows you've already thought through the problem and just need a small nudge.
A Communication Framework You Can Practice
The phases above turn into a single flow that can be practiced until it runs automatically during real interviews:
- Repeat the problem in your own words. ("So we need to find...")
- Ask 2-3 clarifying questions. ("Can the input be empty? Are there duplicates?")
- Brute force first. State the obvious approach and its complexity.
- Optimize with an explanation. State the key insight that improves the solution.
- Confirm with the interviewer. ("Does this approach sound reasonable?")
- Narrate as you code. Explain blocks, not lines.
- Test out loud. Walk through an example with your code.
- Discuss trade-offs and extensions.
Clear communication shapes how your thinking is perceived, but it only helps if you reach each phase of the interview with enough time left. The next chapter is about budgeting those 45 to 60 minutes so nothing important gets cut short.