Tell me about a time you gave an unfavorable solution to solve a problem.

How did you arrive at your unfavorable conclusion?

How did you prepare to communicate this difficult message?

What steps did you take to help stakeholders understand and accept the solution?

How did you address pushback or resistance?

• How did stakeholders ultimately respond to your recommendation?
• What was the measurable impact of implementing this solution?
• What did you learn about delivering difficult messages?
• How has this experience shaped how you approach similar situations?

Sample Answer (Junior / New Grad) Situation: During my internship on a mobile app team, we were planning a major redesign that the product manager was very excited about. The PM wanted to launch all new features simultaneously in one big release. As I worked on implementing the backend APIs, I discovered significant performance issues that would cause crashes on older devices, which represented about 30% of our user base according to analytics.

Task: I was responsible for the API implementation and load testing. Even though I was just an intern, I knew I needed to speak up about what I'd found. My manager expected me to flag any technical risks, and I had the data showing this approach wouldn't work for a large portion of users.

Action: I documented the performance test results showing response times and memory usage on different device types. I scheduled a meeting with my manager first to review the findings and get advice on how to present them. Then I prepared a short presentation for the PM showing the crash rates we'd likely see and proposed a phased rollout instead—launching features incrementally over three releases. I made sure to acknowledge the excitement around the redesign while explaining the technical constraints clearly with graphs and specific metrics.

Result: The PM was initially disappointed and pushed back, wanting to keep the original timeline. However, my manager supported my findings, and we agreed on a two-phase approach as a compromise. The first phase launched successfully with zero crashes, and user satisfaction scores improved by 15%. The PM later thanked me for catching this early, and I learned that delivering bad news with data and alternative solutions makes difficult conversations more productive.

Sample Answer (Mid-Level) Situation: I was the tech lead for a customer-facing dashboard project that had been pitched to leadership as taking three months to build. After the kickoff, I spent two weeks doing technical discovery with my team of four engineers. We uncovered that the third-party data provider we planned to integrate had API rate limits and latency issues that would make real-time updates impossible without a complete architecture change. The VP of Product had already demo'd mockups with real-time features to the executive team.

Task: As tech lead, I owned the technical architecture and feasibility assessment. I needed to tell the VP and project stakeholders that we couldn't deliver what had been promised—at least not in the timeline or budget allocated. My responsibility was to provide an honest assessment and offer viable alternatives that would still meet core business objectives.

Action: I created a detailed technical brief documenting the API limitations, including specific rate limits (100 requests per minute) and average response times (3-5 seconds). I analyzed our expected user load and showed that we'd hit limits within the first week. Rather than just presenting the problem, I developed three alternative approaches: accept 15-minute data refresh intervals with the existing provider, switch to a more expensive provider that could support near-real-time updates (adding $80K annually), or build a lightweight version now and plan a v2 with real-time in six months. I met with the VP one-on-one first, then presented to the broader stakeholder group with cost-benefit analyses for each option.

Result: The VP was frustrated initially, especially having already set executive expectations. However, she appreciated that I brought solutions rather than just problems. After discussing with finance and her leadership, we chose the third option—launching with 15-minute intervals and adding real-time to the roadmap for Q3. The project launched on time, achieved 85% of the original business goals, and user feedback indicated that 15-minute updates were actually sufficient for their use cases. I learned the importance of doing deep technical discovery before commitments are made, and now I advocate for discovery phases in project planning.

Sample Answer (Senior) Situation: I was leading the engineering team for a major platform migration that would move our services from a monolithic architecture to microservices. The executive team had committed to the board that this migration would reduce infrastructure costs by 40% while improving reliability. Six months into the 12-month project, after migrating about 30% of services, my analysis showed we were actually going to increase costs by 25% due to the complexity of service mesh, observability tooling, and the additional engineering headcount needed to maintain distributed systems.

Task: As the senior engineering leader, I owned the success and budget of this migration. I had to tell the CTO and CFO that not only would we miss the promised cost savings, but we'd actually spend significantly more. I needed to recommend either continuing with a revised cost model or fundamentally changing our approach, knowing that either option would damage credibility with the board and potentially affect funding.

Action: I spent three weeks building an exhaustive financial model with my team, breaking down actual vs. projected costs across infrastructure, tooling, and personnel. I interviewed engineering managers to understand hidden costs and gathered data from companies that had completed similar migrations. I identified that the 40% savings target had been based on a vendor's marketing materials rather than real-world case studies. I then developed a comprehensive recommendation: pause the full migration, keep the 30% we'd already moved to prove value and learn, and instead invest in optimizing our existing monolith with modern practices. I presented this to the CTO in a pre-read with all supporting data, then to the executive team with transparent acknowledgment of the planning failure. I framed it as a course correction that would save $3M over two years compared to continuing the flawed plan.

Result: The initial executive meeting was tense, and there were serious questions about why this wasn't caught in planning. However, the CTO appreciated the rigorous analysis and the fact that I brought a clear alternative rather than just stopping the project. We implemented my recommendation, which required explaining the change to the board. Over the next 18 months, we achieved 15% cost reduction from the optimized hybrid approach while improving reliability to 99.95% uptime. Two executives later told me that my willingness to deliver bad news early prevented what could have been a $5M mistake. This experience taught me to validate bold claims with independent research during planning, and I now ensure my teams do proof-of-concept work before making major commitments.

Common Mistakes

• Bringing only problems, no solutions -- Always prepare alternative approaches when delivering bad news
• Avoiding the difficult conversation -- Delaying only makes the situation worse; address issues early
• Being too apologetic -- Present your recommendation with confidence backed by data
• Surprising stakeholders publicly -- Brief key decision-makers privately before larger meetings
• Lacking data and specifics -- Support your unfavorable recommendation with concrete evidence and analysis
• Not acknowledging the impact -- Show empathy for how your recommendation affects others' plans and commitments
• Focusing only on what won't work -- Explain the trade-offs and why your solution is the best available option

Result: The initial executive meeting was tense, and there were serious questions about why this wasn't caught in planning. However, the CTO appreciated the rigorous analysis and the fact that I brought a clear alternative rather than just stopping the project. We implemented my recommendation, which required explaining the change to the board. Over the next 18 months, we achieved 15% cost reduction from the optimized hybrid approach while improving reliability to 99.95% uptime. Two executives later told me that my willingness to deliver bad news early prevented what could have been a $5M mistake. This experience taught me to validate bold claims with independent research during planning, and I now ensure my teams do proof-of-concept work before making major commitments.