Discuss a time when you had conflicting perspectives with teammates and how you handled it

How did you initially address the disagreement?

What steps did you take to understand the other perspective?

How did you communicate your own reasoning?

What process did you use to reach a resolution?

• What decision was ultimately made?
• How did it impact the project or product?
• What was the effect on your working relationship?
• What did you learn about handling future conflicts?

Sample Answer (Junior / New Grad) Situation: During my capstone project, my teammate and I disagreed on the tech stack for our web application. I wanted to use React because of my familiarity with it, while she advocated for Vue.js, citing better documentation and a gentler learning curve for our third teammate who was new to frontend development. The disagreement emerged during our second sprint planning meeting, and we needed to make a decision quickly to stay on schedule.

Task: As co-lead on the frontend development, I needed to help make a decision that would serve the entire team and project timeline. We had only three weeks left before our first demo, so choosing the wrong framework could jeopardize our ability to deliver a working prototype. My responsibility was to set aside my personal preference and evaluate what would truly help us succeed as a team.

Action: I suggested we each spend an evening researching and building a simple prototype in our preferred framework, then present our findings to the team. I documented the pros and cons I found with React, being honest about the steeper learning curve. During our meeting, I actively listened to her presentation about Vue.js and asked clarifying questions rather than defensive ones. We then invited our third teammate to share which framework felt more approachable, and I acknowledged that her points about team accessibility were more important than my individual comfort level.

Result: We chose Vue.js, and our third teammate was able to contribute meaningfully to the frontend within just a few days. Our project received high marks, with professors specifically noting the polished user interface. More importantly, I learned that the "best" technical decision isn't always about cutting-edge features—it's about what enables the whole team to contribute effectively. This experience taught me to lead with curiosity rather than defensiveness when disagreements arise.

Sample Answer (Mid-Level) Situation: While leading the development of a new API service at my company, I had a significant disagreement with our senior backend engineer about the authentication approach. I proposed using OAuth 2.0 with JWT tokens for its flexibility and industry adoption, while he insisted on session-based authentication, arguing it was more secure and easier to revoke access. This disagreement surfaced during our architecture review and threatened to delay our timeline by two weeks if we couldn't align quickly.

Task: As the tech lead for this service, I was responsible for making the final architectural decision, but I also needed to maintain team cohesion and ensure we built the most appropriate solution. The API would serve both internal tools and external partners, with different security requirements for each. I needed to balance security concerns, developer experience, and our aggressive launch timeline of six weeks.

Action: I scheduled a dedicated working session where we could dive deep into both approaches with our security team present. I prepared by researching hybrid approaches and documenting specific use cases for our API with their security implications. During the session, I asked him to walk through his specific security concerns with JWT, which revealed his main worry was around token revocation for compromised accounts. I then proposed a hybrid solution: JWT tokens for external partners with short expiration times, and session-based auth for internal tools where we needed immediate revocation. I also committed to implementing a token blacklist mechanism to address his revocation concerns.

Result: The senior engineer agreed with the hybrid approach, and we actually improved our original design by thinking through both perspectives. Our API launched on time and has processed over 2 million requests with zero security incidents in the past year. The relationship with the senior engineer strengthened significantly—he later told me he appreciated that I took his concerns seriously rather than pulling rank. I learned that disagreements often signal important edge cases or requirements that haven't been fully explored, and that the best solutions often emerge from synthesizing opposing viewpoints.

Sample Answer (Senior) Situation: As Engineering Manager for our payments platform, I had a fundamental disagreement with our Product Manager about the roadmap priority for Q3. She wanted to prioritize building support for cryptocurrency payments to attract a younger demographic, while I advocated for focusing on payment retry logic and dunning management to reduce our 12% failed payment rate. The disagreement came to a head during quarterly planning, with executive stakeholders expecting a unified proposal. Our CEO had specifically asked us to focus on revenue growth, but we interpreted that goal very differently.

Task: My responsibility was to advocate for the technical investments that would drive sustainable business outcomes while also maintaining a productive partnership with the PM. I needed to move beyond simply defending my position and find a way to align on priorities that would satisfy both our growth objectives and operational excellence needs. The stakes were high—our decision would determine how we allocated eight engineers for an entire quarter and would directly impact our $15M annual recurring revenue target.

Action: I proposed that we collaboratively build a data-driven framework to evaluate both initiatives rather than relying on intuition. I worked with our data analyst to model the financial impact of each option: crypto payments would potentially add $500K in new revenue but required significant compliance work, while improving payment retry logic could recover $1.8M in failed payments annually. I then scheduled a meeting where we presented both analyses to our CFO and VP of Product. Rather than positioning it as my idea versus hers, I framed it as two valid opportunities with different risk profiles and timelines. I also proposed a compromise: we'd prioritize the payment reliability work but allocate 20% of our resources to a crypto payment pilot with one provider to test the market hypothesis.

Result: The executive team supported our hybrid approach, and the payment reliability improvements we shipped in Q3 reduced our failed payment rate from 12% to 4%, recovering $1.4M in annualized revenue. The crypto pilot revealed lukewarm customer interest—only 3% of surveyed customers wanted the feature—which saved us from a major misallocation of resources in Q4. My relationship with the PM actually strengthened through this process because we established a shared decision-making framework that we continued using for subsequent roadmap discussions. I learned that as a senior leader, my job isn't to win arguments but to create structures that help teams make better decisions together, especially when smart people disagree.

Sample Answer (Staff+) Situation: As Staff Engineer, I found myself in a months-long disagreement with our VP of Engineering about our microservices migration strategy. He wanted to pursue a "big bang" rewrite of our monolithic application into microservices over 18 months, arguing that incremental migration was too slow and would leave us with a messy hybrid system. I believed a strangler fig pattern—gradually extracting services while keeping the monolith running—was less risky and would deliver value faster. This wasn't just a technical disagreement; it represented different philosophies about managing technical transformation across our 80-person engineering organization. The board was expecting a clear modernization strategy, and our divided leadership team couldn't present a coherent plan.

Task: As the most senior technical leader without direct organizational authority over the VP, I needed to influence the decision through technical credibility and strategic thinking rather than hierarchy. My responsibility extended beyond just being "right"—I needed to ensure we chose an approach that the entire engineering organization could execute successfully while maintaining our product velocity and customer commitments. The wrong choice could result in millions in wasted effort, product delays, and potentially engineer attrition if we chose an approach that felt reckless or demoralizing.

Action: I spent two weeks conducting a listening tour across engineering teams, infrastructure, and product to understand concerns and constraints that neither the VP nor I had fully considered. I discovered that teams were split 60-40 on the approach, with valuable concerns on both sides. I then wrote a detailed RFC proposing a phased approach: we'd start with the strangler fig pattern but commit to extracting three critical services in the first six months with measurable success criteria. If we hit those criteria, we'd continue incrementally; if we fell short, we'd reassess whether a more aggressive approach was needed. I presented this to the VP privately first, acknowledging the valid points in his proposal and showing how the phased approach incorporated his urgency while managing risk. When he remained skeptical, I proposed we present both options to the CTO with a joint recommendation to pilot my approach for six months with clear decision points.

Result: The CTO approved the pilot, and we successfully extracted our authentication service, notification system, and payment processing in five months, improving deployment frequency by 300% and reducing incidents in those domains by 60%. The VP became a champion of the approach after seeing the results, and we jointly presented the expanded migration strategy to the board. Over the next 18 months, we extracted 15 services while maintaining product velocity, ultimately achieving the modernization goals with 40% less risk than the big bang approach. More significantly, the collaborative process we used became a template for how senior leadership resolves strategic disagreements at our company. I learned that at the staff+ level, the most important conflicts to navigate aren't about being right—they're about establishing decision-making processes that make the organization more effective even after you've moved on to the next problem.

Common Mistakes

• Making it personal -- Focus on the ideas and outcomes, not personalities or who was "right"
• Not showing genuine listening -- Demonstrate that you tried to understand the other perspective, not just waited for your turn to talk
• Lacking specificity -- Avoid vague statements like "we talked it out"; explain the actual process you used to resolve the disagreement
• No clear resolution -- Interviewers want to see that you drove to a decision and outcome, not that the conflict just faded away
• Taking all the credit -- Acknowledge the other person's contribution to the final solution if there was one
• Blaming or badmouthing -- Even if the other person was difficult, frame it professionally and focus on what you controlled

Result: The executive team supported our hybrid approach, and the payment reliability improvements we shipped in Q3 reduced our failed payment rate from 12% to 4%, recovering $1.4M in annualized revenue. The crypto pilot revealed lukewarm customer interest—only 3% of surveyed customers wanted the feature—which saved us from a major misallocation of resources in Q4. My relationship with the PM actually strengthened through this process because we established a shared decision-making framework that we continued using for subsequent roadmap discussions. I learned that as a senior leader, my job isn't to win arguments but to create structures that help teams make better decisions together, especially when smart people disagree.

Result: The CTO approved the pilot, and we successfully extracted our authentication service, notification system, and payment processing in five months, improving deployment frequency by 300% and reducing incidents in those domains by 60%. The VP became a champion of the approach after seeing the results, and we jointly presented the expanded migration strategy to the board. Over the next 18 months, we extracted 15 services while maintaining product velocity, ultimately achieving the modernization goals with 40% less risk than the big bang approach. More significantly, the collaborative process we used became a template for how senior leadership resolves strategic disagreements at our company. I learned that at the staff+ level, the most important conflicts to navigate aren't about being right—they're about establishing decision-making processes that make the organization more effective even after you've moved on to the next problem.