Tell me about a time you had to convince a group of skeptics and what you did to win them over
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers ask this to understand how you influence without relying on authority, especially when the initial audience is unconvinced. They want to see whether you can diagnose the source of skepticism, adapt your approach to the people in front of you, and move a group toward a decision while preserving trust. At higher levels, they are also testing whether the scale and complexity of the skeptical audience matches your expected scope.
Key Insights
- You should explain why people were skeptical, not just that they were. Good answers show that you understood their concerns as rational responses to risk, past experience, incentives, or missing information.
- Don't make the story about 'presenting harder' until others gave in. Strong answers show that you listened, changed your approach, and sometimes even changed the proposal itself based on what you learned.
- You need to show an outcome beyond verbal agreement. Explain what actually changed afterward: a decision was made, an experiment was approved, a launch moved forward, or trust improved for future work.
What interviewers probe atlevel
Top Priority
For junior candidates, a strong ending is concrete and proportionate: what decision changed, what was tried, and what that showed.
Good examples
🟢The team agreed to let me make the change behind a flag, and after a week with no issues we kept it and used the same pattern in a couple of nearby areas.
🟢They approved a limited trial, and the result was that review time went down and the teammate who had been most skeptical told me the simpler flow was easier to follow.
Bad examples
🔴After I explained it, everyone seemed okay with it, so I took that as a win.
🔴In the end they agreed, and that showed I had convinced them.
Weak answers stop at perceived agreement; strong answers show a real decision, action, and result.
Valuable
Example answers atlevel
Great answers
In my first few months on a product team, I was working on a small feature that accepted uploads, and I suggested adding a lightweight validation step earlier in the flow. The two engineers reviewing my work were skeptical because they thought it would add complexity for a minor edge case. Instead of just repeating my opinion, I asked what worried them most, and I learned they were mainly concerned about introducing bugs into a part of the feature that was already close to done. I put together a small test version behind a flag and showed that the change was isolated and caught several bad inputs before they reached the later processing step. I also simplified my original version after one reviewer pointed out that I was handling more cases than we actually needed. They agreed to ship the smaller version, and after release we kept it because it reduced avoidable failures without causing issues elsewhere. That experience taught me that when people are skeptical, it's usually better to answer the actual risk they're seeing than to argue harder for the whole idea.
At my last internship, I helped on a small internal dashboard for our operations team, and I suggested changing the way we displayed late deliveries so the most urgent ones would appear first. A couple of analysts pushed back because they were used to the old layout and worried it would make the report harder to trust. Instead of arguing, I sat with them for one morning and watched how they actually used the report, then I built a simple mockup that kept the same data but reordered it by urgency and added a short explanation next to each item. I also asked one of the analysts to compare the old and new views on real cases from the previous week, which helped show that the new version made it easier to spot problems quickly without hiding anything. Once they saw they could still get to the same information and save time during their review, they were comfortable trying it. That experience taught me that people are usually more open to change when they feel heard and can see that their workflow is still respected.
Poor answers
I had a situation where I wanted to clean up part of a feature I was building, but the other engineers didn't really see why it mattered. I felt pretty strongly that my approach was better, so I walked them through the code in detail and explained why the structure I chose was cleaner. After a few discussions they said okay and I moved forward with it. For me the key was being persistent and not backing down when I knew the solution was right.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early May, 2026
They were interested in who the group were, the context of the disagreement and what my specific actions and involvement was.
Hello Interview Premium
Your account is free and you can post anonymously if you choose.