Tell me about a time when you've had to push back or say no to a customer request.
Asked at:
Roblox
Meta
Uber
Amazon
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.
“Describe a time you had to tell a customer their requested solution wasn't something you were going to build.”
“Have you ever had to push back on a feature ask from a customer or client? What happened?”
“Tell me about a situation where a customer wanted something, but you believed saying yes would be the wrong decision.”
“What's an example of a customer request you declined or redirected, and how did you handle that conversation?”
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
At junior level, interviewers mainly want to see that you did not reflexively say no; you tried to understand the request and the constraint.
Good examples
🟢Before responding, I asked what problem they were having and learned they were manually combining two exports every week, which changed how I thought about the request.
🟢I spent a little time with the account rep to understand why the customer wanted the feature and found out they mainly needed a one-time way to unblock a renewal conversation.
Bad examples
🔴The customer wanted a change to the report, but it wasn't how our system worked, so I told support we couldn't do that.
🔴I knew the request would be a lot of work, so I pushed back right away and said it wasn't in scope.
Weak answers treat the request itself as the whole problem; strong answers uncover the customer goal behind the request and use that to shape the response.
You do not need a dramatic conflict story; what matters is showing respect for the customer while still being clear about limits.
Good examples
🟢I acknowledged that their request made sense from their perspective and explained why the current behavior was frustrating before I walked through our constraints.
🟢I was clear that we couldn't do exactly what they asked, but I tried to make sure they felt heard and understood why we were saying no.
Bad examples
🔴The customer kept insisting, so I repeated that it wasn't possible and that was basically the end of it.
🔴They were asking for something unreasonable, so I was pretty direct that engineering couldn't keep changing things for one person.
Weak answers frame the customer as the problem; strong answers preserve the relationship by validating the need while holding the line.
Valuable
A solid junior story ends with evidence that the customer got clarity or help, not just that you delivered the message.
Good examples
🟢I followed up to make sure the workaround actually solved enough of the problem and updated our internal notes so the same confusion wouldn't repeat.
🟢After the conversation, I checked with the customer-facing partner to confirm the message landed well and there were no new blockers.
Bad examples
🔴After I said no, I assume support handled the rest because I didn't hear more about it.
🔴I sent the explanation and moved on to my next task.
Weak answers end when the message is sent; strong answers verify outcome and close the loop.
You do not need a perfect business case, but you should show that your pushback was based on real constraints or risks, not personal preference.
Good examples
🟢I explained that making the change quickly could break an existing workflow for other users, so it wasn't just about effort.
🟢The reason I pushed back was that the request conflicted with a current release commitment and introduced risk for many customers, which seemed too costly for the benefit.
Bad examples
🔴I didn't think the request was worth the effort, so I pushed back on it.
🔴It felt like a bad use of time, and my lead agreed, so we said no.
Weak answers rely on intuition or convenience; strong answers show an actual tradeoff between customer value, risk, and constraints.
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
Meta
Mid-level
Late April, 2026
Uber
Senior
Mid March, 2026
Roblox
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.