Tell me about a time you had to insist on a course of action or decision despite pushback from others
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you handle principled disagreement when you believe something important is at stake. They are usually trying to distinguish healthy conviction from stubbornness: can you hold your ground based on sound reasoning, understand why others are pushing back, and persist without damaging trust? At higher levels, they also look for whether the stakes and scope of the decision match your level, and whether your influence comes from judgment rather than authority.
Key Insights
- Conflict here does not need to be dramatic or personal. You will usually sound stronger if you frame the pushback in terms of differing constraints, risk tolerance, incentives, or priorities rather than portraying others as unreasonable.
- You should explain why this issue was worth insisting on. If the decision was low-stakes or mostly about personal preference, persistence can read as inflexibility instead of leadership.
- Strong answers show both backbone and adaptability: you stayed firm on the core principle, but you were willing to change the framing, evidence, rollout plan, or compromise around the edges to get to a better outcome.
What interviewers probe atlevel
Top Priority
Even when you believe you're right, show that you listened carefully and tried to understand what others were worried about.
Good examples
🟢When my reviewer pushed back, I asked which part felt risky and learned they were worried about test coverage, so I came back with additional tests and a smaller change.
🟢I set up a quick conversation after a meeting because I wanted to understand the concern better, and it turned out they had seen a similar bug before and were trying to avoid a repeat.
Bad examples
🔴My teammate disagreed, but I assumed they just hadn't looked closely enough, so I repeated my original point more strongly.
🔴I saw the pushback as mostly resistance to change, so I focused on defending my idea instead of asking what specific concern they had.
Weak answers flatten pushback into obstruction; strong answers treat disagreement as useful information about risks or constraints.
Valuable
Example answers atlevel
Great answers
On a small feature, I noticed the planned implementation accepted user input without the same validation our older flow used. A teammate felt it was fine because the form already limited what users could type, but I was worried that copied or retried requests could still send bad data. I reproduced the issue with a simple test and showed that it could save an invalid value, which would have been hard to clean up later. I suggested we add one server-side check now instead of redesigning the whole flow, and that made the change small enough that the team agreed. We added it, and during testing it caught the exact case I had been concerned about. What I was happy about was that I didn't just say no—I brought evidence and a practical way forward.
At my last internship, I was helping update a weekly operations report that a few teams relied on for staffing decisions. The dashboard owner wanted to remove one metric because it made the report look more complicated, but I kept pushing to keep it since that number was the clearest signal we had for whether we were short on coverage. I knew it would annoy people to add another line to the report, so I brought a few weeks of historical data and showed that when that metric dipped, we almost always saw missed handoffs the next day. After that, the team agreed to keep it in and just move it lower on the page so it was easier to read. I’m glad I spoke up because the report ended up being used in the morning check-in, and later my manager said it helped them catch a staffing issue before it affected customers.
Poor answers
In one project, I insisted we use the structure I originally built because I thought it was cleaner and easier to understand. Another engineer wanted to simplify it, but I felt that would make the code less organized over time. We went back and forth in review comments for a while, and I kept explaining why my version was better. Eventually they accepted it and we merged my approach. To me that showed I could stand my ground when I know I'm right.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid June, 2026
Mid June, 2026
Early April, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.