Course Content

User focus: anti-patterns and a worked answer

User focus has one dominant anti-pattern and two smaller ones, and all three are common in otherwise strong candidates.

This lesson works through them, then follows Ines — the platform engineer from the deploy-tooling translation in the previous lesson — through a full answer and five follow-ups. It shows exactly what the drilling looks for: who the user was, how you knew, what you changed and how it was measured.

'Built what was asked' fails at the second question, because the requirement was the only evidence there ever was.

The anti-pattern — built what was asked, no user evidence

"We built a bulk-upload feature because several enterprise customers had asked for it. I owned the backend. We shipped it in six weeks and it went out to all customers. It's used pretty widely now — I think a few hundred uploads a month."

Nothing here is wrong and nothing is scoreable. The write-up:

"Customer focus — no evidence. Requirement arrived pre-formed; candidate implemented it. Asked what they learned about how customers used it: 'I'd have to check the metrics'. Asked whether anything about the design changed based on customer input: no. Competent delivery story; not a customer story."

The salvage, where one exists, is in the details of the build. Did you look at what customers uploaded? Did you find that half the files failed validation and change the error handling? Did you notice the same customer re-uploading the same file four times? Any of those converts this into an answer. Without one of them, choose a different story — this is weak material and rewording it will not help.

Two smaller anti-patterns

The assumed benefit. "I made it three times faster, which has to be better for users" — except nobody had complained about speed, and the user-visible effect was never measured. This is the deploy-tooling trap from the previous lesson, and it is extremely common in performance work.

The proxy user. "Our product manager told us users found it confusing." That is a second-hand summary. It is better than nothing and it is not contact, and interviewers can hear the difference immediately because second-hand accounts have no texture — no quotes, no surprising detail, no moment where you were wrong.

A worked example

Worked example — "Tell me about a time you advocated for the user"

Ines, invented, a platform engineer interviewing for a senior role. About three minutes, then the drilling.

Ines: "Context — Torvus, about 200 engineers. I'm on the platform team that owns deploy tooling. Roughly forty deploys a day across the org.

The stakes: our roadmap had a four-week project to cut deploy time from eleven minutes to about four, and it was the team's biggest item for the quarter. It came from a survey where 'deploys are slow' had been the top complaint two quarters running.

What I did before starting it. I asked to spend a morning each with six engineers across four teams, watching them deploy. Not interviewing — watching, and asking what they were doing at each step.

Two things came out of it, and neither was speed. First, nobody complained about the eleven minutes while it was happening. They started something else. Second, five of the six stayed watching a dashboard for roughly twenty minutes after the deploy completed. Two had a terminal open with the rollback command typed out and not run. When I asked why, the answers were versions of the same thing: 'if this goes wrong I want to be the one who catches it, because I don't trust it to catch itself.'

So the real cost was not eleven minutes of machine time, it was about twenty minutes of human supervision per deploy. Across forty deploys a day, that's more than ten engineer-hours daily, and none of it was in the survey because nobody thinks of watching a dashboard as work.

What changed. I took that to my team and to the two engineering managers with the loudest teams, and we cancelled the speed project. Instead we built automatic rollback on an error-rate breach, with a visible countdown on the deploy page that shows the system is watching and what it will do. Three weeks.

Result: deploy time is still eleven minutes — we never touched it. Median supervision time went from about twenty minutes to under three. And deploys per day went up by roughly a third, which we didn't predict; people had been batching changes to avoid paying the supervision cost twice.

Reflection: the survey question was the actual failure. 'Deploys are slow' was the answer to a question we wrote, and it had been top for two quarters, so we'd stopped interrogating it. I'd now treat a stable top survey answer as a sign the survey is wrong rather than a sign the problem is urgent."

The follow-ups

Interviewer: Six people is a small sample. How did you convince anyone this was worth cancelling a funded project over?

Ines: It wouldn't have been enough on its own, and it wasn't what convinced people. What convinced them was that once I knew what to look for, I could measure it without asking anybody. The deploy page had access logs. I pulled the median time from deploy completion to the last page view by the deploying engineer, across about three thousand deploys in the previous quarter. Nineteen minutes.

So the six mornings gave me the hypothesis and the log data gave me the size. I'd not have found the hypothesis from the logs — nineteen minutes of page views looks like nothing until someone tells you they're sitting there with a rollback command typed.

Interviewer: Was anyone against cancelling?

Ines: One of my own teammates, fairly strongly, and their argument had a good point in it: the eleven minutes is real, it compounds across a day for someone doing four deploys, and 'users don't know what they want' is sometimes true. Their position was that we should do both, speed first because it was already scoped.

What we did in the end was neither exactly. We shipped the rollback work, and I agreed to re-measure deploy-time complaints a quarter later. When we did, deploy speed had dropped to fourth in the survey without us touching it, which I think was because the twenty minutes afterwards had been colouring how long the whole thing felt.

Interviewer: You said supervision went to under three minutes. How is that measured, and what's the error bar on it?

Ines: Same metric as before — time from deploy completion to the deploying engineer's last page view on the deploy page. Median across all deploys in a month.

The error bar is real and I'd want to name it. That metric counts a page view, not attention. Someone could close the tab and still be watching a Grafana dashboard, in which case I'm undercounting. And it doesn't capture the anxious deploys separately from routine ones — the distribution has a tail, and the tail is where the cost is. The p90 went from about thirty-five minutes to nine, which is the number I'd actually defend as the outcome.

Interviewer: And the third more deploys — how do you know that's yours?

Ines: I don't, fully. Deploy volume was already trending up about 5% a quarter as headcount grew, and the change was a step of roughly 30% over six weeks, which is bigger than the trend. The thing that makes me believe it's causal is that the increase was concentrated in the four teams that had been batching most heavily, and two of those teams told us unprompted that they'd stopped batching. That's not proof. If you asked me to state it carefully I'd say: strong circumstantial evidence, one plausible confound, and I'd rather be honest about that than claim it.

Interviewer: What would you do differently?

Ines: Two things. The survey point from my reflection — I'd audit a stable top answer instead of trusting it.

The other one is that I went to two engineering managers with the loudest teams to build support, which worked, and I skipped the teams that never complain. Six months later one of those quiet teams turned out to have written their own deploy wrapper, which is the clearest possible signal that our tooling didn't work for them, and nobody on my team knew. Silence from a user is data and I treated it as an absence of data.

What the write-up said

"Customer Obsession — strong hire. Direct observation before building, with specific physical detail (rollback command typed, not run) that could not be second-hand. Converted a qualitative hypothesis into a measurable proxy from logs — this was the strongest move. Cancelled a funded, quarter-defining project on that evidence, and can state the opposing argument fairly. Measured a user outcome (supervision time, batching behaviour) rather than the artefact; volunteered the p90 as the more defensible figure and named a confound on the deploy-volume claim unprompted. Reflection identified a systemic instrument failure (the survey) and a blind spot about quiet users. Also usable for Innovation and Problem Solving."

Two moments carried this answer: converting an observation into a metric that already existed in the logs, and volunteering the weaker interpretation of their own headline number.