Describe a time when you needed to influence a peer who had a differing opinion about a shared goal.

How did you approach the conversation or series of conversations?

What techniques did you use to understand their perspective?

What evidence, data, or reasoning did you provide to support your viewpoint?

How did you find compromise or build consensus?

• Did you reach agreement, and what approach did you ultimately take?
• What was the impact on the project or goal?
• How did this experience affect your working relationship?
• What would you do differently next time?

Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, I worked with another intern on redesigning the user onboarding flow. We both wanted to reduce drop-off rates, but he believed we should add more explanatory screens while I advocated for a minimalist approach with contextual tooltips. We had limited time before our presentation to the product team and needed to present a unified recommendation.

Task: As co-owners of this project, we both needed to align on a single design direction. It was my responsibility to either convince him of my approach or find a compromise, since presenting two competing ideas would undermine our credibility. The product team was expecting a clear recommendation they could act on.

Action: I scheduled a coffee chat to really understand his reasoning without the pressure of our regular standups. I learned he was concerned that new users would feel lost without clear guidance. I acknowledged this was a valid concern and suggested we validate our assumptions with data from user testing. We ran quick hallway tests with five colleagues unfamiliar with the product, testing both approaches. I also researched industry benchmarks showing that simpler flows typically performed better. After reviewing the test results together, which showed users preferred the cleaner interface, he agreed to try my approach with one compromise—we'd add a single optional tutorial that users could access if needed.

Result: We presented our unified recommendation, which was approved and implemented. The new onboarding flow reduced drop-off by 23% in the first month. More importantly, I learned that leading with curiosity rather than advocacy builds better relationships. My colleague and I became close friends and still collaborate on side projects today. This experience taught me that finding the "why" behind someone's position is often more important than focusing on the "what."

Sample Answer (Mid-Level) Situation: As a product manager at a B2B SaaS company, I was leading a feature launch to improve our analytics dashboard. My engineering counterpart, who had equal decision-making authority on technical implementation, strongly preferred building a custom charting solution from scratch. I believed we should integrate an established third-party library to ship faster. We both wanted to deliver powerful analytics to customers, but our disagreement on approach was blocking progress, and we had already spent two planning meetings at an impasse.

Task: As the product lead, I needed to unblock this decision within the next week to keep our quarterly roadmap on track. I was accountable for the feature's success, but I couldn't move forward without engineering buy-in. I needed to either persuade my counterpart or find an alternative that addressed both our concerns. The team was waiting on direction, and every week of delay meant unhappy customers asking for better analytics capabilities.

Action: I started by scheduling a one-on-one to deeply understand his perspective without the audience of the broader team. I discovered his real concern wasn't about the technology itself—he worried that third-party dependencies could limit our customization abilities as customer needs evolved. Rather than defending my position, I proposed we define specific customization requirements we'd need in the next 12 months and evaluate the library against those criteria. We spent two hours together actually prototyping with the library and discovered it could handle 90% of our requirements. For the remaining 10%, I worked with him to design a wrapper architecture that would give us an escape hatch if needed. I also acknowledged his expertise by asking him to own the final technical decision after we completed this analysis together.

Result: He agreed to use the third-party library with the wrapper approach, and we shipped the feature six weeks earlier than if we'd built custom. The analytics dashboard increased customer engagement by 34% and became our second-most-used feature. Our partnership strengthened significantly—he later told me that feeling heard and having his concerns addressed with data rather than dismissed made all the difference. I learned that influence isn't about winning arguments; it's about collaborative problem-solving. This approach became my template for navigating future technical disagreements, and I've successfully used it on at least five other projects since then.

Common Mistakes

• Framing it as winning an argument -- Focus on finding the best solution together, not on being right
• Not addressing the real concern -- Often disagreements have underlying worries that aren't explicitly stated; dig deeper
• Making it personal -- Keep the discussion focused on outcomes and approaches, not on personalities or egos
• Lacking specific tactics -- Describe the exact techniques you used to influence (data, prototyping, compromise, etc.)
• No reflection on relationship -- Mention how the experience affected your working dynamic going forward
• Missing the learning -- Show what you'd do differently or how this changed your approach to influence

Result: He agreed to use the third-party library with the wrapper approach, and we shipped the feature six weeks earlier than if we'd built custom. The analytics dashboard increased customer engagement by 34% and became our second-most-used feature. Our partnership strengthened significantly—he later told me that feeling heard and having his concerns addressed with data rather than dismissed made all the difference. I learned that influence isn't about winning arguments; it's about collaborative problem-solving. This approach became my template for navigating future technical disagreements, and I've successfully used it on at least five other projects since then.

Result: We implemented the hybrid approach, achieving 100% audit coverage across all products within four months while actually reducing average compliance-related development time by 30%. Zero compliance violations were reported in our next audit. Beyond the metrics, this changed how our engineering leadership team operated—we established a practice of joint discovery before advocacy that we now use for all major technical decisions. My relationship with this peer evolved from contentious to collaborative, and we've since successfully partnered on three other major initiatives. I learned that senior leadership influence requires vulnerability and genuine partnership, not just strong opinions. The time invested in collaborative problem-solving—that full afternoon of discovery—paid dividends far beyond this single decision.

Result: We secured CEO approval and $18M in investment for our unified strategy. Over 18 months, we increased enterprise merchant retention by 28% through configurability while maintaining 99th-percentile checkout latency under 800ms. More significantly, this changed how Staff-level leaders collaborated at the company—we established a precedent that Staff+ disagreements should be resolved through joint problem-solving rather than escalation. My peer and I now co-chair the technical strategy council, and our partnership has become a model for cross-functional influence at the senior level. I learned that at the Staff+ level, influence isn't about having the best idea—it's about creating the conditions for the organization to discover the best idea together. The measure of success isn't whether your proposal wins, but whether the organization becomes more capable of making difficult strategic decisions.