Tell me about a time when you've had to push back or say no to a customer request.
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess whether you can protect engineering, business, and customer outcomes when a request should not simply be accepted at face value. They want to see judgment under pressure: how you understood the real need, handled the relationship, communicated constraints clearly, and worked toward a constructive path forward rather than just blocking. At higher levels, they also look for whether your pushback reflected product, organizational, or strategic judgment rather than only personal preference.
Key Insights
- A strong answer is rarely just 'I said no.' You should show that you first understood what the customer was actually trying to accomplish, because seasoned interviewers care about your judgment and empathy, not your willingness to deny requests.
- Pushback is strongest when it is paired with an alternative. If your story ends with refusal rather than a safer path, phased option, tradeoff discussion, or expectation reset, you may sound rigid instead of customer-focused.
- Don't frame the customer as unreasonable. Even when the request was a bad idea, interviewers look for whether you treated the ask as a signal about unmet needs, urgency, incentives, or missing context.
What interviewers probe atlevel
Top Priority
A good junior answer often includes a workaround, clarification, or next step that helped the customer make progress even though the exact request was declined.
Good examples
🟢I couldn't implement the exact change, but I suggested a different export setting and documented the steps so the customer could keep moving.
🟢Since the request wasn't feasible right away, I partnered with my lead on a temporary approach that solved most of the customer's problem safely.
Bad examples
🔴We couldn't do the request, so I closed the loop and told them maybe it could be considered in the future.
🔴I said no and passed it back to the support person to handle from there.
Weak answers end at refusal; strong answers help the customer succeed within real constraints.
Valuable
Example answers atlevel
Great answers
In my last role, a customer asked for us to change the format of a report export because their team was manually combining it with another spreadsheet every week. My first thought was that we couldn't do exactly what they wanted because the export format was shared by many customers, so I talked with the support rep to understand the real pain point before responding. We found out they mainly needed one extra field and a more consistent column order, not a fully custom report. I explained why we couldn't make a customer-specific change that might break other users, but I also suggested a safer configuration we already had and helped test it with support. That solved most of their issue right away, and I added internal notes so if a similar request came in again the team would know the workaround.
At my last job I was a junior developer on a small team building a patient scheduling app used by clinics. One clinic asked if we could remove the multi-factor step for certain staff because it slowed check-ins. I dug into why they wanted it and checked our compliance rules—our product needed to maintain strong authentication and an audit trail for patient privacy, so I couldn't agree to a blanket removal. I explained the legal and security reasons to the clinic contact in plain terms, apologized for the inconvenience, and proposed two alternatives: extend session time for specific kiosk devices and add a fast 'verified check-in' mode that kept full logging. I then built the simpler of the two changes, wrote acceptance criteria, and worked with QA to pilot it with that clinic so we could validate it didn't weaken protections. They were satisfied with the speed improvement and I kept notes for the team about how to evaluate similar requests going forward.
Poor answers
A customer once wanted a custom change to one of our exports. I pushed back because we already had a standard format and changing it for one customer would have created extra work. I told support that if we started doing one-off requests, everyone would ask for them. They understood, so we left the export the way it was and moved on.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late April, 2026
Late April, 2026
Mid March, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.