Tell me about a time you had to change your communication style to solve a problem.
Asked at:
Microsoft
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers ask this to understand whether you can recognize that effective communication is audience-dependent and adjust deliberately instead of using a one-size-fits-all style. They are also testing whether you diagnose the real barrier correctly: was the problem confusion, trust, pace, detail level, emotional temperature, or misaligned incentives? Strong answers show intentional adaptation, empathy, and a concrete improvement in outcome.
“Describe a situation where the way you were communicating wasn't working, and you had to adjust.”
“Tell me about a time you had to tailor your message for a different audience to get unstuck.”
“Have you ever realized someone wasn't hearing your point the way you intended? What did you change?”
“Give me an example of when you had to present the same issue differently to make progress.”
“What's a time when changing the format or tone of your communication helped solve a problem?”
Key Insights
- You should explain why your original communication approach was not working. Without that diagnosis, changing style can sound like random people-pleasing rather than thoughtful problem-solving.
- Communication style is broader than being nicer or more concise. You can adapt format, level of detail, timing, channel, framing, cadence, or how much context you provide based on what the other person needed.
- Don't make the story about how difficult the other person was. Strong answers show that you assumed the gap might be in translation, understanding, or context, and took responsibility for helping the conversation work.
What interviewers probe atlevel
Top Priority
At junior level, interviewers want to see that you noticed the misunderstanding and adjusted on purpose, not just accidentally changed tone.
Good examples
🟢I noticed my updates used a lot of implementation detail, but my product partner mainly needed timeline and risk, so I changed what I emphasized.
🟢When my senior engineer kept re-explaining the task, I realized I was asking broad questions in meetings and saving specifics for later, which made me seem less prepared.
Bad examples
🔴I realized they weren't getting it, so I just repeated the same explanation more slowly until they agreed.
🔴My teammate preferred a different style, so I switched to chat instead of meetings, but I didn't really know why that helped.
Weak answers treat the problem as the other person failing to understand; strong answers identify the actual mismatch between message, audience, and context.
Even at junior level, strong candidates show they were trying to help the other person succeed, not just get their own point across.
Good examples
🟢I realized my teammate was context-switching between several tasks, so I packaged the key information in a way that was easier for them to skim and respond to.
🟢My mentor liked to understand the reasoning before the implementation details, so I started with the goal and tradeoffs instead of walking through every line.
Bad examples
🔴My teammate was hard to work with because they asked a lot of questions, so I started making my explanations shorter.
🔴The reviewer kept misunderstanding my code changes, so I made my comments more obvious.
Weak answers frame adaptation as managing someone difficult; strong answers show curiosity about what the other person needed.
Valuable
For junior candidates, the bar is not perfection; it's taking some responsibility and showing that your change actually improved the interaction or result.
Good examples
🟢After I changed how I sent updates, my mentor started catching blockers earlier and I finished the task with fewer back-and-forths.
🟢I checked with my teammate afterward to see if the new format was more useful, and they said it made it easier to review quickly.
Bad examples
🔴Once I changed how I explained it, the other person finally understood and we moved on.
🔴I adapted my style and after that there were no more issues.
Weak answers claim success without ownership or evidence; strong answers show follow-through and a believable improvement.
A strong junior answer often ends with a simple lesson: different people need different kinds of clarity, and you now check for that earlier.
Good examples
🟢It taught me to ask earlier how someone prefers updates instead of assuming my default style works for everyone.
🟢After that, I started checking whether people needed the high level or the detailed version before jumping into an explanation.
Bad examples
🔴Since then I always try to be clearer with everyone.
🔴The main thing I learned is that communication is important.
Weak answers offer generic lessons; strong answers show a practical shift in future behavior.
Example answers atlevel
Great answers
During my internship, I was working with a designer on a small feature and I kept explaining implementation details when she asked for progress. I noticed she still seemed unsure about what would actually change for users, so I realized I was answering from my perspective instead of hers. I switched to showing a quick before-and-after flow and started giving updates in terms of what was done, what was still blocked, and whether it affected the user experience. That made our conversations much smoother, and she was able to give feedback earlier instead of waiting until the end. I took away that being accurate isn't enough if I'm not packaging the information in a way the other person can use.
As a junior backend engineer I was responsible for a small database migration that required sign-off from our security and operations teams. At first I sent an email full of schema diagrams and SQL examples, and got a dozen follow-up questions and visible concern about downtime and data loss. For the next meeting I rewrote the communication: a one-page summary that listed what would change for users, a clear rollback plan, a short risk table (impact, likelihood, mitigations), and a proposed outage window with exact responsibilities. That shift from technical detail to risk-and-responsibility reassured non-engineering stakeholders, we got the approvals faster, and the migration went smoothly with zero customer impact. I learned that when safety or uptime is at stake, being structured and mitigation-first is more effective than sharing raw technical detail.
Poor answers
I had a time where a teammate kept asking me for updates on a task I was doing. I usually gave detailed explanations, but they still seemed confused, so I just started giving shorter answers and only responding when they asked specific questions. That worked pretty well because it cut down on back-and-forth. We finished the task on time, so I think it showed I can adjust how I communicate.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late January, 2025
Microsoft
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.