User focus: what interviewers score and how to build the story

User focus is making technical decisions with the end user's experience as the deciding criterion — including, and especially, when that costs you something as an engineer.

This lesson defines the competency by what it excludes, sets out the signals and the phrasings (two of which engineers often misread as product-manager questions), and then deals with the most common blocker: the platform or infrastructure engineer who concludes they have no users. That conclusion is nearly always wrong, and the fix is mechanical.

The definition

The word that carries the weight is deciding. Every engineer will say they care about users. The competency is about occasions where caring about users made you do something you would not otherwise have done.

What it is not

It is not building what the product manager asked for. That is delivery. If the requirements arrived fully formed and you implemented them, no user-focus evidence was generated, however good the feature.

It is not customer support. Being helpful to a customer on a ticket is fine and it is not this. The competency wants a technical decision that changed.

It is not liking users. Empathy without a decision produces nothing to score.

The shape of a real user-focus story

The strongest ones contain a moment where engineering preference and user benefit pointed in different directions, and the user won:

"The clean solution was to return a 422 with a machine-readable error body and let the client render it. The clients didn't render it — three of the four integrations we looked at showed the raw code to their end users. So we put a human-readable sentence in the response as well, which is redundant, inelegant, and is the reason our support volume on that endpoint dropped by about two-thirds."

That is a small decision, and it is a complete answer. The engineer looked at what integrators actually did, changed a design they preferred, accepted an ugly result, and measured the consequence in support volume rather than in shipped features.

The measurement point

Interviewers listen for what you measured. Measuring the shipped feature is the default: "we launched it, adoption was 40%". Measuring the user's outcome is the signal: "the thing users were trying to do — get a refund without contacting support — went from 12% to 61% self-service".

Signals scored

Three positives, four negatives, and one signal that is much rarer than interviewers would like.

The positive indicators

1. Direct contact with users or their data. Not a summary from a product manager. The observable form names the contact:

"I sat with six of our warehouse operators for a morning each. The thing I hadn't understood is that they use the scanner one-handed, because the other hand is holding the parcel."

Or, when direct contact is impossible:

"I read three months of support tickets tagged 'checkout' — about 400 — and coded them into nine categories. Two categories were 71% of the volume."

2. Willingness to change the plan because of it. Contact without change is tourism. The scoring sentence is "so we stopped doing X and did Y instead".

3. Measuring the user-facing outcome. See the measurement point above. Interviewers specifically probe: "how did you know it worked, from the user's side?"

The negative indicators

The second row is worth flagging. Some version of "users ask for faster horses" appears in a surprising number of interviews, offered as sophistication. It is recorded as contempt.

The one that is rarest

Saying no to a request, with the user as the reason.

Most candidates have stories about building things for users. Very few have a story about declining to build something because the evidence said it would not help — which is the harder and more senior behaviour.

"Sales had a deal contingent on a CSV export with custom column mapping. I asked to see how the two existing customers who had asked for exports actually used them, and both were importing the file into the same spreadsheet template. So instead of the configurable export — about five weeks — we shipped a single fixed export matching that template in four days, and asked the prospect whether it worked. It did. The five-week version never got built."

That answer contains user evidence, a changed plan, a scope reduction, and a business outcome. It also contains a "no", which is the part that is hard to find in most story banks.

Questions asked

Six phrasings. Two of them are frequently misread as product-manager questions and answered as though the candidate were apologising for being an engineer.

1. "Tell me about a time you advocated for the user."
2. "Tell me about a time you used data to change a product decision."
3. "Tell me about a time you said no to a request."
4. "How do you make sure what you build is actually useful?"
5. "Tell me about a time you got user feedback that surprised you."
6. "Describe a trade-off you made between technical quality and user experience."

What each is really probing

Question 3 has a specific trap

"Tell me about a time you said no" is answered by most candidates with a capacity story: "we didn't have bandwidth so I pushed back on the timeline". That is a delivery answer to a customer-focus question.

The user-focus version has the user as the reason for the no:

"I said no to the configurable export because the two customers who had asked for exports were both doing the same thing with them, and a configurable version would have cost five weeks to serve a need that four days covered."

Question 6 rewards honesty about the direction you chose

Interviewers do not require that you always choose the user. A candidate who says "we chose the technically clean option and I still think that was right, and here is the user cost we accepted and how we mitigated it" scores well. What scores badly is claiming the trade-off did not exist.

Building the story, including when you have no users

The most common blocker in this competency is a candidate on a platform or infrastructure team concluding they have nothing. That conclusion is nearly always wrong, and the reframe is mechanical. First, the two tests every story has to pass.

The two tests

Test 1 — you touched the evidence yourself. A metric a product manager showed you in a slide is not contact. Reading the tickets, watching the session recordings, sitting with the users, or querying the data yourself is.

Test 2 — something changed that would not otherwise have changed. A plan, a scope, a design, or a decision to stop.

The platform and infrastructure reframe

If you build for other engineers, your users are other engineers. This is not a consolation prize — internal-developer stories often score better than consumer ones, because the evidence is easier to gather and the outcomes are easier to measure.

The translation, term by term:

The last row is the sharpest signal available on a platform team and almost nobody measures it.

A worked translation

An invented platform engineer thinks they have no story:

"I work on deploy tooling. I don't have users."

Ten minutes of reframing produces this:

"Our deploy tool's stated problem was that deploys were slow — eleven minutes — so the roadmap had a four-week project to get it to four. Before starting I sat with six engineers while they deployed, which took a morning. Nobody complained about the eleven minutes. Five of the six stayed watching a dashboard for twenty minutes afterwards, and when I asked why, the answer was some version of 'I don't trust the rollback'. Two of them had a terminal open with the rollback command typed but not run.

So the real cost wasn't eleven minutes of waiting, it was twenty minutes of supervision per deploy, times about forty deploys a day across the org. We cancelled the speed project. What we built instead was an automatic rollback on error-rate breach with a visible countdown, so the engineer can see the system watching. Deploy time is still eleven minutes. Median supervision time went from about twenty minutes to under three, and the number of deploys per day went up by roughly a third because people stopped batching changes to avoid the supervision cost."

Every element is there: direct contact, a surprising finding, a cancelled project, and a measurement of what the user actually experienced.

Level calibration