“Tell me about a time you made a decision based on customer needs” or “Give an example of going out of your way for a user” are common in product-focused companies, and they’re easy to answer badly. The weak answers are about effort (staying late for a client) or about results nobody can check (conversion went up 30%). What makes a customer story convincing is evidence: what users actually experienced, how you found out and what changed afterwards.
What customer focus looks like for an engineer
For engineers, the customer isn’t always the person paying. It can be an end user, another team calling your API, a support agent using your admin tool, or the on-call engineer reading your runbook at 3 a.m. The question is the same in each case: did you look at what they actually experienced, or did you build what the ticket said?
Amazon’s leadership principles put it as starting with the customer and working backwards. You don’t need to work at Amazon to use the idea in an interview: begin your story with what the user was going through, and let the technical work follow from that.
Evidence versus assumption
Assumptions sound like “users want a dark mode” or “people find the settings page confusing.” Evidence sounds like “41 support tickets in a month mentioned losing their form data” or “in three session recordings, people clicked the disabled button repeatedly.”
Useful sources for engineers include support tickets, error logs, analytics funnels, session recordings, user interviews and notes from sales or customer success calls. In your answer, name the source and roughly how much of it you looked at. That one detail separates a story about customers from a story about your opinions.
Worked example: an upload error nobody could recover from
Here’s an illustrative scenario. Use the structure; build the details from your own work.
A job-application portal gets about 25 support tickets a week from applicants saying they “lost” their application. The ticket queue treats them as user error.
A weak answer (illustrative):
I’m really passionate about the customer experience. I noticed our error messages were confusing, so I rewrote them, and conversions went up 30%.
There’s no evidence of the problem, the fix is vague, and the 30% will be the interviewer’s next question. If the candidate can’t explain how it was measured, the story falls apart.
Stronger version (illustrative; replace with your own evidence and results):
Support was getting around 25 tickets a week from applicants who said they’d lost their application, and they were being closed as user error. I read through about forty of them and noticed most mentioned attaching a CV. I reproduced it: if the file was over 5 MB, the server rejected it, the page showed “Error 413” and every field the applicant had filled in was cleared. I also watched a few session recordings of the error, and people typically gave up after the second attempt.
I made three changes. The form now checks file size before submitting, it keeps everything the applicant has typed if anything fails, and the message says what happened and what to do: the file’s size, the limit, and a suggestion to export the CV as a PDF. I asked support to tag any new tickets about lost applications so we could compare.
Over the next month the tagged tickets dropped from about 25 a week to about 3, and rejected uploads in the server logs fell to near zero, since the check happens first. We didn’t have analytics on completed applications at the time, so I can’t tell you how many more people finished applying, only that far fewer got stuck.
The candidate found the evidence themselves, traced it to a specific cause, fixed the cause rather than just the wording, set up a way to measure, and said honestly what they couldn’t claim.
Measuring honestly with what you have
Many teams don’t have perfect analytics, and interviewers know that. What they want is a reasonable measure and honesty about its limits. Ticket volume, error counts in logs, the number of times a support agent has to step in, or direct feedback from the users you spoke to can all show a change.
What hurts is precision you can’t back up. If you say a number, expect “How did you measure that?” and “Compared with what?” If the honest answer is “I estimated it,” say so up front.
When the customer asks for the wrong thing
Customers usually describe solutions, not problems. “Can you add an export to Excel?” might mean they need to reconcile your data with their accounting system every month, in which case a scheduled file in the format their accounting tool imports could save them more time than a button.
A good customer story sometimes includes a moment where you asked “What will you do with it once you have it?” and built something different because of the answer. That shows you care about the outcome they need, not just closing the request.
Internal customers count
If your work is mostly backend or platform, your customers are often other engineers, and those stories are just as valid. For example, a payments API might return a generic 500 error for invalid input, so the mobile team can’t tell a bad request from an outage. Changing it to return a 400 with the failing field names, then checking with the mobile team that their error handling became simpler, is a customer-impact story with clear evidence on both sides.
Mistakes that weaken the answer
- Invented or inflated numbers. They’re the most likely thing to be probed.
- Effort instead of impact. Working all weekend for a client says nothing about whether it helped them.
- Building exactly what was asked. Without understanding the need, you might have built the wrong thing well.
- “Users” with no actual user. If you never looked at a ticket, recording or conversation, the story is about assumptions.
- No follow-through. If you didn’t check afterwards, you don’t know whether it worked.
Follow-up questions to expect
“How did you know that was the main problem?” Point to the evidence: the share of tickets mentioning uploads, the reproduction and the recordings.
“What did you decide not to change?” Perhaps you considered raising the size limit and decided against it because of storage costs and scanning time. Showing what you rejected shows judgment.
“How did you balance this against other work?” Mention the cost of the problem (support time, applicants lost) next to the size of the fix.
Interview practice: one customer’s demand
A large customer insists on a feature only they would use, and sales says their renewal depends on it. What do you do?
Answer and reasoning
Start by understanding the need behind the request. Ask, or ask the account manager to find out, what problem the feature solves for that customer and what they do today without it. Requests that sound unique often turn out to be a version of something other customers need too, or something an existing setting or integration already covers.
Then gather evidence beyond the one customer. Check whether other accounts have asked for something similar in support tickets or sales notes. That changes the decision from “build for one customer” to “build for a group.”
Lay out the options with their costs: a configuration or workaround using existing features, a general version of the feature that others could use, or a custom build with its ongoing maintenance cost. The decision about whether a renewal justifies the cost belongs to the product manager and the business, so bring those options with a recommendation rather than deciding alone.
A strong answer shows curiosity about the real need, evidence beyond one loud voice, honest costs including maintenance, and respect for who owns the decision. A weak one either builds whatever sales asks for or refuses because “it’s only one customer.”