Tell me about a time when you had a conflict with your manager and you were wrong

• How did you express your disagreement to your manager?
• What steps did you take after the decision was made?
• How did you discover or come to realize you were wrong?
• How did you acknowledge your mistake?

Share the outcome and learning:

• What was the ultimate impact of following your manager's direction?
• How did you repair or strengthen the relationship?
• What specific lessons did you take away that changed your approach?
• How have you applied this learning in subsequent situations?

Sample Answer (Junior / New Grad) Situation: During my first internship on a data engineering team, my manager asked me to implement a batch processing job that ran every six hours. I had just learned about stream processing in my coursework and was convinced that real-time processing would be much better. I pushed back during our 1-on-1, arguing that stream processing was the modern approach and batch processing was outdated. My manager listened patiently but ultimately asked me to proceed with the batch implementation as planned.

Task: My responsibility was to build a data pipeline that aggregated user activity logs for our analytics dashboard. I believed my role was not just to implement solutions but to advocate for what I thought were better technical approaches. I felt it was important to speak up when I saw an opportunity for improvement, especially given my recent academic knowledge of newer technologies.

Action: I voiced my concerns in our next meeting, explaining the benefits of stream processing with specific examples from my coursework. When my manager remained firm on the batch approach, I reluctantly implemented it but continued to research stream processing options on the side. About three weeks in, I started running into performance issues with my implementation and had to debug why the pipeline was taking so long. That's when I discovered our data volumes were relatively small, our analytics didn't need real-time updates, and the six-hour batch window was chosen because downstream systems only refreshed their reports twice daily anyway. I scheduled a follow-up with my manager, admitted I had been wrong to push back so hard, and thanked them for their patience in letting me learn this lesson firsthand.

Result: The batch pipeline I built worked perfectly for the team's needs and ran reliably throughout my internship. My manager appreciated my willingness to admit my mistake and used it as a teaching moment about understanding requirements deeply before proposing alternatives. I learned that technical elegance means nothing without understanding business context and user needs. This experience taught me to ask "why" questions about requirements before jumping to solutions. In my full-time role, I now make it a point to understand the complete context—including constraints, timelines, and downstream dependencies—before advocating for alternative approaches.

Sample Answer (Mid-Level) Situation: As a mid-level software engineer on a mobile app team, my manager decided to delay our planned rewrite of a legacy feature to focus the entire quarter on performance optimizations and bug fixes. I strongly disagreed with this prioritization because I had been maintaining the legacy code for over a year and felt the technical debt was slowing us down significantly. I argued in our sprint planning that the rewrite would ultimately save us time and make the app more maintainable. The feature had accumulated workarounds and patches, and I was confident that starting fresh would be more efficient than continuing to band-aid the old system.

Task: My responsibility was to lead the development of new features in this part of the app while maintaining the existing functionality. I felt strongly that my voice should carry weight since I was the engineer most familiar with this codebase. I believed part of my job as a mid-level engineer was to advocate for technical decisions that would benefit the team long-term, even if they required short-term investment.

Action: I made my case in a team meeting and followed up with a written proposal detailing the technical debt and projected time savings from a rewrite. My manager acknowledged my points but explained that our app's crash rate had spiked and user ratings were dropping, making stability the top priority. Reluctantly, I pivoted to focus on the performance work. Over the next two months, as I fixed bugs and optimized the existing code, I realized the legacy system was more stable than I'd thought—it just needed targeted improvements. The crash rate dropped by 65%, our app rating improved from 3.8 to 4.4 stars, and user retention increased by 12%. Most importantly, I discovered that many of the "blockers" I'd attributed to technical debt were actually my own lack of deep understanding of why certain design decisions had been made. I met with my manager to acknowledge that their prioritization had been right and that I'd let my frustration with the code cloud my judgment about what users actually needed.

Result: The quarter of stability work prevented what our product manager later told us could have been a serious user exodus based on the complaint trends. My relationship with my manager actually grew stronger because I demonstrated I could accept being wrong and learn from it. I learned to separate my personal preferences about code quality from actual user impact, and to better balance technical idealism with business pragmatism. Now when I advocate for technical changes, I first ground my argument in user impact and business metrics rather than code aesthetics. This experience directly influenced how I approach technical proposals—I now spend more time understanding the business context and alternate perspectives before pushing for my preferred solution.

Sample Answer (Staff+) Situation: As a Staff engineer and technical lead for our infrastructure organization, my director proposed consolidating our five different deployment systems into a single unified platform. I strongly disagreed with this approach, arguing that each system served distinct use cases—microservices, ML models, data pipelines, mobile apps, and edge functions—and that forcing them into one platform would create a lowest-common-denominator solution that wouldn't serve any team well. I had been involved in building several of these systems and believed their specialization was a strength, not a weakness. I made my case in our quarterly planning meeting, backed by input from several teams who expressed concerns about losing their workflow customizations.

Task: As the most senior IC in infrastructure, I felt responsible for representing the engineering teams who relied on these systems and for protecting the sophisticated deployment capabilities we'd built for different workloads. I viewed my role as providing technical wisdom that would prevent costly mistakes, and I was concerned that my director was being influenced too heavily by operational costs without fully appreciating the technical tradeoffs. I believed it was my responsibility to push back on what I saw as an oversimplified approach to a complex problem.

Action: I organized a working group to document the requirements across all five systems and created a detailed analysis showing why consolidation would sacrifice critical capabilities. I presented this to the engineering VP and director with support from several engineering managers. My director appreciated the thorough analysis but asked me to also evaluate what a unified platform could look like if we designed it properly from the start. I reluctantly agreed to lead the design effort, though I remained skeptical. Over four months of deep technical design work with stakeholders from every team, something shifted in my understanding. I realized that most of the "unique requirements" I'd been defending were actually point-in-time solutions to problems that could be solved more elegantly with better abstractions. The specialization I thought was essential was actually just accumulated complexity from years of independent evolution. The proposed unified platform, when properly designed with extensibility in mind, could serve all use cases while dramatically reducing our operational burden and cognitive load across the engineering organization. I met privately with my director to acknowledge that my initial resistance had been wrong and that I'd been too close to the existing systems to see the bigger picture.

Result:

Common Mistakes

• Refusing to admit full responsibility -- Trying to share blame or justify why you were wrong undermines the self-awareness interviewers are looking for
• Choosing a trivial disagreement -- Pick a situation with real stakes where your judgment was genuinely mistaken on something meaningful
• Not explaining what you learned -- The learning and behavior change are the most important parts of your answer
• Damaging your manager's credibility -- Frame your manager as having good reasons, not just "they got lucky" or "time proved them right"
• Lacking specific details -- Vague answers suggest you're making up a story rather than reflecting on a real experience
• No demonstration of changed behavior -- Show how this experience actually modified your approach in subsequent situations
• Being defensive -- Any hint of defensiveness or rationalization will raise red flags about your ability to receive feedback

Result: The quarter of stability work prevented what our product manager later told us could have been a serious user exodus based on the complaint trends. My relationship with my manager actually grew stronger because I demonstrated I could accept being wrong and learn from it. I learned to separate my personal preferences about code quality from actual user impact, and to better balance technical idealism with business pragmatism. Now when I advocate for technical changes, I first ground my argument in user impact and business metrics rather than code aesthetics. This experience directly influenced how I approach technical proposals—I now spend more time understanding the business context and alternate perspectives before pushing for my preferred solution.

Result: We successfully migrated to the third-party gateway over the next quarter, which freed up 3.5 engineers worth of effort that we redirected to building customer-facing features. Our API latency actually improved by 23% and we gained advanced traffic management capabilities that accelerated our expansion into new regions. My relationship with my manager deepened because I demonstrated that I could put company needs above personal attachment to my work. More importantly, I learned a crucial lesson about the bias we develop toward our own creations and the importance of staying objective about build-vs-buy decisions. This experience fundamentally changed how I approach architectural decisions—I now actively seek out perspectives that challenge my assumptions and explicitly check myself for emotional attachment to existing solutions. I've since mentored other engineers through similar situations, helping them recognize when expertise can become dogmatism.