Describe a time when you needed to influence a peer who had a differing opinion about a shared goal.
Asked at:
Salesforce
OpenAI
Amazon
Netflix
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers are assessing how you handle disagreement when you cannot rely on authority and still need to make progress toward a shared outcome. They want to see whether you understand the other person's reasoning, adapt your approach, and influence in a way that preserves trust rather than just "winning." For more senior candidates, this also tests whether the scale of the disagreement and the way they resolved it match their expected scope.
“Tell me about a time you and a colleague wanted the same outcome but disagreed on how to get there.”
“Describe a situation where you had to persuade a peer who initially pushed back on your approach.”
“Have you ever had to win support from another engineer or manager who saw a shared problem differently? What happened?”
“Walk me through a disagreement with a peer where neither of you had authority over the other, but you still needed to make progress.”
“What's an example of a time you changed a peer's mind on an important decision without escalating right away?”
Key Insights
- Conflict here does not need to be emotional. You will often do better with a story about differing priorities, risk tolerance, or assumptions than with a story about obvious interpersonal friction.
- You should show that you understood why the peer disagreed before trying to persuade them. Strong answers usually uncover a legitimate concern, not just an obstacle to overcome.
- Do not frame success as "I convinced them" alone. The strongest answers show movement toward a better shared decision, a compromise, or a durable working relationship.
What interviewers probe atlevel
Top Priority
You do not need authority to tell a strong story; show that you adjusted your approach and used concrete reasoning.
Good examples
🟢I compared the two options with a small test and walked through the risks and effort so we could decide on facts instead of preference.
🟢Once I understood their timeline concern, I proposed a smaller first step that addressed the main risk without delaying the release as much.
Bad examples
🔴I kept restating that my solution was safer until they stopped arguing.
🔴I brought our lead into the conversation right away so they could settle it.
Weak answers rely on persistence or authority; strong answers use facts and adapt the proposal to address the peer's concern.
Even at junior level, the best stories do not end with "I won"; they end with a workable decision and a healthy relationship.
Good examples
🟢We agreed to a smaller version of my proposal and checked the results together afterward, which made future collaboration easier.
🟢Even though we did not choose my exact solution, we landed on an option that addressed their schedule concern and my reliability concern.
Bad examples
🔴They finally agreed to my approach, and we moved on.
🔴I proved my point in front of the team, so there was no more debate.
Weak answers celebrate victory; strong answers show joint progress and ongoing trust.
Valuable
Do not stop your story at the conversation; show what happened after the decision and what you learned.
Good examples
🟢After we aligned, I owned the first implementation steps and checked whether the change solved the issue we were debating.
🟢We reviewed the result after release, and I used that feedback to improve how I handle similar disagreements.
Bad examples
🔴They agreed, so I considered it done.
🔴After the meeting we just implemented it, and I assumed it worked out.
Weak answers end at persuasion; strong answers include execution and verification.
Pick a real disagreement with some consequence, but one that fits the scope of someone contributing on a small project.
Good examples
🟢I disagreed with another engineer about whether to add a quick workaround or spend an extra day fixing the root cause before release because support load was a concern.
🟢On a small feature, a peer wanted to skip validation to move faster, and I had to persuade them that the failure cases would affect users and create rework.
Bad examples
🔴We disagreed about variable names, and I explained my preference until they accepted it.
🔴A teammate wanted to use a different testing style, so I showed them the team guideline and that settled it.
Weak stories are trivial or purely preference-based; strong stories involve a real tradeoff with visible impact.
Example answers atlevel
Great answers
On a small feature for our internal support tool, a teammate and I disagreed about skipping input validation so we could finish by the end of the sprint. We both wanted to ship on time, but I was worried we'd create avoidable errors for the support team. Instead of debating in the pull request, I asked if we could talk for ten minutes and learned they were mainly worried about missing our commitment. I put together a small compromise: we added validation for the two highest-risk fields now and left the less common cases for a follow-up task. We shipped on time, support didn't see the bad data issue I was concerned about, and my teammate later came to me earlier on a similar tradeoff because the conversation had stayed collaborative.
In my first few months at an edtech startup I was building a small lesson player and a teammate suggested skipping keyboard navigation and screen-reader labels to finish before a big client demo. I pushed back because many of our users rely on assistive tech, so I spent ten minutes showing how a screen reader behaves without labels and explained that simple ARIA attributes would make the demo meaningfully testable. I offered to implement the basic accessibility fixes while they polished the visuals, and proposed a follow-up ticket for more advanced interactions. We shipped the demo on time, the client could actually try the feature, and my teammate started asking me earlier about accessibility tradeoffs on later tasks because they saw how small changes increased our audience.
Poor answers
I had a peer who wanted to structure a test differently from how I usually do it. I explained that my style was cleaner and more readable, and we went back and forth a little in the review. I kept commenting until they updated it to match my version. That worked well because we ended up with a more consistent solution.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early May, 2026
OpenAI
Senior
Late March, 2026
Salesforce
Mid-level
Early August, 2025
Salesforce
Staff
Hello Interview Premium
Your account is free and you can post anonymously if you choose.