Courses › Behavioral Interviews › Question Themes

Customer & User Focus

Advocating for users — external, internal and developers — with evidence and trade-offs.

"Tell me about a time you went above and beyond for a customer" and "…argued for users over an easier option" come up at almost every product company. They're central at Amazon (Customer Obsession), Stripe (users first), Google (focus on the user) and Atlassian (don't #@!% the customer). Engineers often struggle with them because they don't think of themselves as customer-facing. But every engineer has users, and these questions are about whose interests you put first when it's inconvenient.

Who counts as "the customer"

  • External users of the product, whether consumers or businesses
  • Developers who use your API or SDK
  • Internal customers: other teams that rely on your platform, service or tooling
  • Support and operations staff who live with what you build

Any of these works. Be explicit about who the customer was and why their experience mattered.

What interviewers look for

Story sources for engineers

  • You found a confusing error message or a broken flow while reading support tickets, and fixed it.
  • You pushed back on a launch date because the experience would have hurt users, and proposed a smaller version that didn't.
  • You noticed in the metrics that a slow page was hurting a group of users nobody was watching, such as mobile users or a particular region.
  • You built a migration path or a backwards-compatible API so that customers didn't have to scramble.
  • You joined customer calls, or spent time on support, and it changed what you built.

[!EXAMPLE] Outline Our API returned a generic 400 for twelve different validation failures, and it was our second-largest source of support tickets. It wasn't on our roadmap, so I pulled a month of tickets, grouped them, and showed my manager that three error types made up 70% of them. I proposed specific error codes with fix-it messages, kept old clients compatible, and shipped it over two sprints. Related tickets fell by about 60%, and the developer-experience team adopted the pattern for other APIs.

"Users over an easier option"

Show the trade-off clearly. What was easier? Who wanted it? What did choosing the user cost? How did you get agreement? Good stories often involve disagreeing respectfully with a product manager, another team or your own manager, using data about users rather than personal preference.

Avoiding the traps

  • Heroics without judgment: "I worked all weekend to ship one customer's request" can sound like poor prioritization. Explain why it was the right call, or what you changed so it wouldn't be needed again.
  • Saying yes to everything: customer focus sometimes means saying no to a feature request and solving the underlying problem a different way.
  • No evidence: "Users loved it" isn't a result. Use a number or a concrete piece of feedback.

[!TIP] Prepare two stories One about external users and one about internal customers or developers. Together they cover most versions of the question, and the Amazon-style follow-up "tell me about another time".

[!TIP] Practice Went above and beyond for a customer · Advocated for users · Argued for users over an easier option · Stood up for the customer