Tell me about a situation where poor communication led to a problem.
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you recognize, diagnose, and recover from communication breakdowns. They are usually not looking for a perfect story; they want to see whether you can honestly explain your role in the problem, understand why the communication failed, and take effective action to repair both the work and the working relationship. At higher levels, they also want to see whether you improve the surrounding system so the same failure is less likely to recur.
“Describe a time when a misunderstanding on your team caused a real problem. What happened?”
“Can you give me an example of when something went wrong because expectations were not clearly communicated?”
“Tell me about a time you realized people were not aligned and it created an issue.”
“What's a situation where your message did not land the way you intended, and what did you do next?”
Key Insights
- You do not need a dramatic failure. A strong answer often comes from an ordinary but consequential misalignment where expectations, context, or ownership were unclear.
- You should name your own contribution to the communication problem, even if others were involved. Mature candidates do not frame the story as 'they misunderstood me'; they show how they investigated the gap and adjusted.
- Do not stop at the immediate fix. Strong answers explain what changed afterward in your habits, team process, or communication style so the issue became less likely to repeat.
What interviewers probe atlevel
Top Priority
At junior level, interviewers mainly want to see that you can admit your part in the problem without becoming defensive or collapsing into self-blame.
Good examples
🟢I realized I assumed my teammate understood my progress from a brief chat, but I had not clearly stated what was finished versus what was still blocked.
🟢Part of the problem was that I asked a vague question and then moved forward based on my own interpretation instead of confirming the expectation.
Bad examples
🔴I sent the update, but the product manager clearly did not read it, so the delay really came from them missing my message.
🔴The issue happened because nobody told me the format they wanted, so I just did what made sense and it caused confusion later.
Weak answers treat communication as something that happened to the candidate; strong answers show the candidate sees themselves as an active participant in the breakdown.
A strong junior answer shows you can move beyond 'there was confusion' and identify the actual gap in understanding, timing, or assumptions.
Good examples
🟢When I looked into it, I found that we were using the same term to mean two different things, so we both believed we were aligned when we were not.
🟢The issue came from me sharing the status in a chat thread after hours, while the person waiting on me only tracked updates in our task board.
Bad examples
🔴We had a miscommunication and the wrong code got written, so I just corrected it and moved on.
🔴The problem was basically that communication was poor, and that is why the work slipped.
Weak answers label the problem; strong answers diagnose the mechanism that created the misunderstanding.
Valuable
A good junior answer shows a simple, concrete habit change that proves you learned something from the incident.
Good examples
🟢After that, I started summarizing decisions and next steps in the task itself so I was not relying on memory from quick chats.
🟢I now repeat back my understanding when requirements seem obvious, because I learned that shared words do not always mean shared meaning.
Bad examples
🔴Since then I just try to communicate more carefully.
🔴After that I made sure to be more proactive.
Weak answers offer generic intentions; strong answers describe a repeatable behavior change.
Example answers atlevel
Great answers
On a small feature project, I told a teammate that my part was 'ready,' and they started building on top of it. What I meant was that the basic path worked, but I still had one edge case and a test issue open. When their work started failing, I realized I had used a shortcut description that sounded much more complete than it really was. I reached out right away, explained exactly what was done versus still in progress, and we spent a few minutes aligning on what they could safely use. After that I updated the task with a clearer status summary and started being more explicit about what 'ready' means when I give updates. It helped us finish the feature without more confusion, and my lead later mentioned that my updates had become much easier to work from.
On a small bug-fix I picked up while working remotely, the ticket description said “match legacy behavior” but didn’t say which edge case counted as legacy; I guessed and pushed a change that made a few UI texts inconsistent. QA caught it and we had to revert and rework the fix, which cost the team a day of cycles. I owned up, fixed the immediate issue, and then updated the ticket with a clear acceptance checklist and examples of expected text for each state so there was no room for guessing. I also started sending one quick clarifying question in the ticket or a Slack thread before I began coding on ambiguous tasks. That small change cut down follow-ups and made handoffs smoother, which my QA partner appreciated because it saved them time when testing.
Poor answers
I had a situation where another engineer used my work before it was finalized and it caused some extra debugging. I had already mentioned in chat that I was working on it, so I think the main issue was that they moved a little too quickly. Once we found the problem, I explained what my code was doing and they adjusted their part. After that, I just made sure to answer messages faster so things would keep moving.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Hello Interview Premium
Your account is free and you can post anonymously if you choose.