Tell me about a time when you've had to push back or say no to a customer request.

How did you analyze the request against your priorities and constraints?

How did you communicate your decision and reasoning?

What alternatives or compromises did you explore or propose?

How did you work to preserve the relationship?

• How did the stakeholder respond to your decision?
• What was the impact on your team's ability to deliver on core priorities?
• What was the longer-term effect on the relationship?
• What did you learn about setting boundaries effectively?

Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, a customer success manager forwarded an urgent request from a key client who wanted a custom CSV export format delivered within 48 hours. Our team was in the final sprint before launching a major security update that had been delayed once already. The CSM emphasized that this client represented 15% of our revenue and was frustrated with our platform.

Task: As the engineer who had built the original export functionality, I was asked to evaluate the technical complexity and provide an estimate. I needed to determine whether we could realistically deliver this without jeopardizing our security release, and communicate that assessment clearly to both my engineering manager and the customer success team.

Action: I spent two hours reviewing the request and realized it would require refactoring our entire export pipeline, not just adding a template—easily 3-4 days of focused work plus testing. I documented my analysis and proposed a meeting with the CSM and my manager. In the meeting, I explained the technical complexity in plain language and shared that taking this on would delay our security update by at least a week, affecting all customers. I then offered two alternatives: a manual workaround I could document in 30 minutes that would meet 80% of their need, or prioritizing this feature for the sprint immediately after launch.

Result: The CSM was initially disappointed but appreciated the transparency and the quick workaround option. She worked with the client to implement the manual process, which actually revealed they only needed this format occasionally. We added the feature request to our backlog and delivered it three weeks later as part of normal development. I learned that saying no effectively means doing the homework, explaining the trade-offs clearly, and always offering alternatives rather than just closing the door.

Sample Answer (Mid-Level) Situation: While working as a product engineer at a B2B SaaS company, our largest enterprise client requested a custom integration with their legacy inventory system. The deal was worth $400K annually, and their procurement team made it clear this integration was essential for renewal, which was six months away. However, our product roadmap was focused on building a mobile app that would serve our entire customer base of 200+ companies, and we were already behind schedule.

Task: As the tech lead for our integrations team, I owned the decision on whether we could accommodate this request. I needed to evaluate the technical scope, assess the impact on our strategic roadmap, and make a recommendation to our VP of Engineering and Head of Sales. This wasn't just a technical decision—it had significant revenue and strategic implications.

Action: I conducted a thorough discovery session with the client's IT team and learned their legacy system used an outdated protocol that would require building a completely custom adapter with ongoing maintenance burden. I estimated three engineer-months of effort plus indefinite support costs. I prepared a detailed analysis showing the opportunity cost: delaying our mobile app would affect customer satisfaction scores across our base and slow new customer acquisition. I then met with sales and engineering leadership to present three options: declining and risking the renewal, accepting and delaying mobile by a quarter, or offering to co-fund a middleware solution through a third-party vendor. I advocated for the third option and personally researched two vendors who could deliver it. In my conversation with the client, I acknowledged their need, explained our constraints transparently, and presented the middleware solution as a win-win that would deliver faster and give them more flexibility.

Result: The client initially pushed back but agreed to evaluate the middleware approach after I arranged demos with both vendors. They selected one and we split the $45K implementation cost. The integration was live in six weeks instead of three months, they renewed their contract, and our mobile app launched on schedule, driving a 23-point increase in NPS. The experience taught me that saying no to the specific request doesn't mean saying no to the underlying need—creative problem-solving and partnership often reveal better paths forward.

Sample Answer (Senior) Situation: As a senior engineering manager at a healthcare technology company, I faced a situation where our CEO committed to a Fortune 500 health system that we would build a custom FHIR integration and patient portal white-label solution to close an $8M deal—our largest ever. The sales cycle had bypassed normal product review processes, and engineering was informed only after the deal was verbally agreed upon. The CEO expected delivery in four months. However, my assessment showed this would require reassigning 60% of my 25-person engineering organization and fundamentally compromise our platform strategy of building reusable components rather than bespoke solutions.

Task: I needed to evaluate whether this commitment was feasible and aligned with our long-term strategy, then communicate a clear recommendation to executive leadership knowing it might mean pushing back on the CEO's commitment. My responsibility was to protect my team's ability to deliver sustainable value while being a trusted business partner. I also needed to maintain credibility with the prospective client while navigating this situation.

Action: I immediately assembled my tech leads to conduct a rigorous scoping exercise, identifying that the true timeline was 7-8 months with current capacity, and that building this as fully custom would create 18-24 months of technical debt that would slow all future development by an estimated 30%. I documented these findings in a detailed memo with clear trade-off analysis. I then requested a meeting with the CEO, CTO, and Head of Sales where I presented the data transparently, acknowledged the business importance, but firmly stated we couldn't deliver quality software in the promised timeframe without significant risk. I proposed a counterproposal: extend the timeline to seven months, build 70% as platform-native components that would benefit all clients, and assign a dedicated team of eight rather than consuming the entire organization. I volunteered to join the CEO in explaining the situation to the client, taking ownership of the technical assessment rather than leaving sales to manage the message alone.

Result: The conversation was tense, but the CEO appreciated the detailed analysis and my willingness to face the client directly. We jointly presented the revised proposal to the health system, emphasizing the platform approach would give them better long-term support and faster future enhancements. They accepted the extended timeline, the deal closed at $7.2M, and we delivered in 6.5 months. More importantly, the platform components we built became the foundation for three subsequent enterprise deals worth $15M combined. This experience reinforced that senior leaders must say no to protect long-term value, but saying no requires doing the analytical work, offering viable alternatives, and personally owning the difficult conversations rather than hiding behind process.

Common Mistakes

• Saying no without offering alternatives -- Always come prepared with options or compromises rather than simply declining
• Focusing only on why you can't -- Balance your explanation with empathy for the stakeholder's needs and business context
• Making it personal or emotional -- Ground your decision in objective analysis, data, and clear trade-offs rather than opinion
• Saying yes when you should say no -- Agreeing to unrealistic commitments damages credibility and creates worse outcomes than honest boundaries
• Going solo on the decision -- Involve appropriate stakeholders and leadership rather than making unilateral calls on significant requests
• Burning the relationship -- Focus on how you maintained trust and partnership even while declining the specific request

Result: The client initially pushed back but agreed to evaluate the middleware approach after I arranged demos with both vendors. They selected one and we split the $45K implementation cost. The integration was live in six weeks instead of three months, they renewed their contract, and our mobile app launched on schedule, driving a 23-point increase in NPS. The experience taught me that saying no to the specific request doesn't mean saying no to the underlying need—creative problem-solving and partnership often reveal better paths forward.

Result: The conversation was tense, but the CEO appreciated the detailed analysis and my willingness to face the client directly. We jointly presented the revised proposal to the health system, emphasizing the platform approach would give them better long-term support and faster future enhancements. They accepted the extended timeline, the deal closed at $7.2M, and we delivered in 6.5 months. More importantly, the platform components we built became the foundation for three subsequent enterprise deals worth $15M combined. This experience reinforced that senior leaders must say no to protect long-term value, but saying no requires doing the analytical work, offering viable alternatives, and personally owning the difficult conversations rather than hiding behind process.