Tell me about a time when a customer came to you for something that wouldn't actually address their need.
Asked at:
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can look past a requested solution and understand the underlying problem the customer is actually trying to solve. Interviewers are looking for product and engineering judgment, empathy, and your ability to redirect someone without being dismissive. At higher levels, they also want to see whether you can turn one-off request handling into repeatable patterns for your team or organization.
“Describe a time when someone asked you for a specific feature or fix, but the real problem turned out to be something else.”
“Have you ever had to redirect a customer from the solution they wanted to a different solution that better fit their need?”
“Tell me about a situation where a user or customer was very clear about what they wanted, but you realized that request wouldn't actually solve their problem.”
“What's an example of a time you had to dig past a customer's request to understand the outcome they were really after?”
Key Insights
- You should not frame the customer as wrong or confused; the strongest answers show that their request made sense given what they knew, and that you took responsibility for uncovering the real need.
- Don't stop at 'I said no and explained why.' Strong answers show how you investigated the underlying problem, proposed a better path, and verified it actually solved the need.
- If you're senior or above, show that you did more than handle one conversation well; explain how you reduced the chance of similar misalignment happening again through process, documentation, or team guidance.
What interviewers probe atlevel
Top Priority
At junior level, interviewers mainly want to see curiosity and that you checked what problem the person was trying to solve before building what they asked for.
Good examples
🟢When the customer asked for a CSV download, I asked how they were using the data and learned they only needed two metrics each morning, so I suggested a simpler report instead.
🟢I first repeated back what I thought they wanted, then asked what they were trying to accomplish; that uncovered that the real issue was finding one status quickly, not seeing more data.
Bad examples
🔴The user asked for an export button, so I started adding one right away because it seemed straightforward, and later we found out they mainly needed a weekly summary email.
🔴A customer requested a new field on a form, and I assumed that was the requirement instead of asking why they needed it or what workflow was failing.
Weak answers treat the request itself as the problem; strong answers investigate the job the customer is trying to get done.
Even if the request was misguided, show respect for why the customer asked for it and avoid sounding like you corrected them from a position of superiority.
Good examples
🟢I could see why they asked for that feature because the current screen made it hard to find the information they needed, so I started by acknowledging that frustration.
🟢I made sure to understand what deadline they were under and why the request felt urgent before suggesting a different approach.
Bad examples
🔴I explained that their idea wouldn't work because they didn't really understand how the system was designed, and then I told them what we should build instead.
🔴The customer kept asking for the wrong thing, so I just clarified that their request was out of scope and moved on.
Weak answers reduce the customer to a bad request; strong answers show the request as a rational response to their constraints and experience.
Valuable
At staff level, interviewers look for leverage: did you influence how multiple people or teams recognize and handle this pattern?
Good examples
🟢I introduced a lightweight pattern for framing asks as problems, alternatives, and expected outcomes, and multiple teams adopted it.
🟢I used the case to improve the interface between engineering, product, and customer-facing teams so solution requests were vetted more consistently.
Bad examples
🔴I personally handled the situation well, but the organization still had no shared approach to distinguishing needs from requested solutions.
🔴The lesson stayed with me rather than being codified into planning, intake, or discovery practices.
Weak answers show individual competence only; strong answers show leveraged improvement in how the system works.
For junior candidates, a strong story can involve escalation or support from others, but you should still show your own contribution clearly.
Good examples
🟢I did the initial investigation, shared my findings with my lead, and helped shape the alternative we offered the customer.
🟢I knew where I needed help, but I still owned my part: gathering examples, clarifying the need, and following up after the solution shipped.
Bad examples
🔴I mostly handed the issue to my manager because it seemed important, and they handled the conversation from there.
🔴I say 'we' throughout the story, but it's not clear what I personally did besides attending a meeting.
Weak answers hide behind senior help; strong answers show appropriate independence with sensible use of support.
Example answers atlevel
Great answers
In an internship, a customer-facing teammate asked me to add a button that exported a whole page of data to a spreadsheet. Before I started, I asked how the customer was using that export, and we learned they were actually copying just two numbers into a daily email because they couldn't find them quickly in the product. I worked with my mentor to add a small summary section on the page instead of building a full export flow. We showed it to the teammate, and they confirmed it covered the customer's real need with much less effort. I also added a short note to our task tracker so if similar requests came in, we'd check the underlying workflow first.
At a small fintech where I was a junior engineer, a customer success rep asked me to remove a file-format validation because a client kept failing uploads. I reached out to the customer and ran through their workflow with them — they weren’t trying to bypass security, they had hundreds of tiny receipt images and needed a way to import them in bulk. Instead of turning off validation, I proposed and built a simple drag-and-drop uploader that zips and validates files client-side before sending, so the checks still ran but the user could batch their receipts. I paired with a senior engineer to make sure we stayed compliant with our data rules, and we shipped it as a small, low-risk improvement. The change cut similar support tickets by half and the customer was happy, and I also wrote a short note for support on how to triage future upload complaints.
Poor answers
A customer asked for an export feature, and I could tell it wasn't necessary because the data was already on the screen. I explained that building exports for every request would create extra work, so I recommended they just use the page as it was. My lead agreed with me, so we didn't build it. I think that was the right call because it's important not to overreact to customer requests.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid December, 2024
Amazon
Mid-level
How would you handle a situation where a customer makes a bad request
Early November, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.