Tell me about a time when you had to go against management or your colleagues

How did you prepare your case before raising concerns?

What specific steps did you take to voice your disagreement constructively?

How did you gather support or data to strengthen your position?

How did you navigate the interpersonal dynamics of challenging authority?

• How did leadership or your colleagues respond to your pushback?
• What was the final decision, and what impact did it have?
• What did you learn about organizational influence and navigating disagreement?
• Would you handle a similar situation differently in the future?

Sample Answer (Junior / New Grad) Situation: During my internship on a mobile development team, my manager decided we should build a new user onboarding flow using a complex animation library to make it feel premium. The timeline was tight—just three weeks before the feature freeze for our quarterly release. I had researched the library and discovered it had poor documentation, hadn't been updated in over a year, and had several open issues related to performance on older devices.

Task: As the intern assigned to implement the animations, I was expected to follow the technical direction my manager had chosen. However, I felt responsible for raising my concerns because implementing this library could put our release timeline at risk and potentially cause crashes for users on older devices. I knew I needed to speak up despite being the most junior person on the team.

Action: I spent an evening creating a brief document comparing three approaches: the complex library my manager suggested, a simpler built-in animation framework, and a lightweight alternative library with active maintenance. I included examples, performance benchmarks I'd run on my test device, and a risk assessment for each option. The next morning, I scheduled a 15-minute 1:1 with my manager and walked her through my findings respectfully, emphasizing that I wanted to make sure we shipped quality on time. I acknowledged her experience and explained I was coming from a place of wanting to de-risk our project.

Result: My manager appreciated that I'd done the homework and brought data rather than just gut concerns. She agreed to pivot to the lightweight alternative library, which took me only one week to implement instead of the estimated three. We shipped on time, and the feature performed well across all devices with zero crash reports. My manager told me during my final review that she valued my initiative and that speaking up constructively showed real ownership. I learned that junior team members can influence decisions when they come prepared with evidence and approach disagreement respectfully.

Sample Answer (Mid-Level) Situation: I was a senior engineer on a payments platform team when our director announced a major architectural decision to consolidate three separate payment processing services into a single monolithic service. The rationale was to reduce operational overhead and simplify our codebase. However, having worked closely with these services for two years, I understood that they served distinct use cases with very different scaling characteristics and compliance requirements. The credit card processing service handled 10x the traffic of our bank transfer service, and our cryptocurrency service had completely different regulatory constraints.

Task: As the tech lead for one of these services, I felt responsible for ensuring we made the right architectural decision for long-term maintainability and reliability. I needed to challenge the director's plan, but I also had to be mindful that this decision had already been socialized with senior leadership and had buy-in from other teams. My task was to present a compelling alternative without appearing obstructionist or territorial about my service.

Action: I organized a working session with the other two tech leads to understand their perspectives and concerns. We collectively identified specific technical risks: the consolidated service would become a single point of failure handling $500M in daily transaction volume, we'd lose the ability to scale services independently, and we'd create compliance complexity by mixing regulated and unregulated payment types. I then requested a design review meeting with our director and drafted a detailed RFC proposing a middle ground—keeping services separate but introducing a shared libraries and unified observability layer to address the operational concerns. I presented failure scenarios with financial impact projections and offered to lead the implementation of the alternative approach. Critically, I framed my pushback around achieving the director's goals through a different path rather than simply opposing the plan.

Result: The director was initially defensive but asked thoughtful questions during the review. After discussing with her peers and the VP of Engineering, she agreed to pilot the shared-libraries approach for one quarter. The pilot was successful—we reduced operational alerts by 40% while maintaining service independence. Six months later, she publicly credited our pushback with preventing what could have been a major architectural mistake. I learned that challenging leadership decisions requires doing the work to understand their underlying goals and proposing alternatives that achieve those goals more effectively. The experience also taught me the importance of building coalitions and using data to depersonalize technical disagreements.

Common Mistakes

• Appearing contrarian or territorial -- Frame pushback around achieving better outcomes, not protecting your domain or simply disagreeing for its own sake
• Coming unprepared without data -- Challenging authority requires rigorous homework; gut feelings won't persuade leadership to change course
• Making it personal or emotional -- Keep the focus on technical tradeoffs, business impact, and customer outcomes rather than personalities or ego
• Only identifying problems without solutions -- Always propose concrete alternatives that address the underlying goals leadership is trying to achieve
• Failing to build coalition support -- Gather perspectives from peers and stakeholders to strengthen your position and demonstrate broader concern
• Going public before going private -- Give leaders the opportunity to hear concerns in a private setting before escalating or making disagreement visible to the broader organization
• Being vague about impact or risk -- Quantify the consequences of the decision you're challenging with specific financial, timeline, or customer impact projections
• Not knowing when to commit after disagreeing -- If leadership makes a final decision after hearing your concerns, commit fully to execution rather than remaining visibly skeptical

Result: The director was initially defensive but asked thoughtful questions during the review. After discussing with her peers and the VP of Engineering, she agreed to pilot the shared-libraries approach for one quarter. The pilot was successful—we reduced operational alerts by 40% while maintaining service independence. Six months later, she publicly credited our pushback with preventing what could have been a major architectural mistake. I learned that challenging leadership decisions requires doing the work to understand their underlying goals and proposing alternatives that achieve those goals more effectively. The experience also taught me the importance of building coalitions and using data to depersonalize technical disagreements.