Library
AmazonSoftware Engineer· Behavioral

Tell me about a time when you took ownership of a problem that wasn't strictly yours to solve.

Amazon's second Leadership Principle is Ownership. Leaders act on behalf of the entire company, beyond just their own team — they never say 'that's not my job.' Interviewers ask this to probe whether you'll step up when something falls between the cracks, or wait for someone else to handle it. A strong answer makes it unambiguous that *you* identified the gap, *you* decided to act, and *you* drove the outcome — even though no one assigned it to you.

How to think about it

STAR — but spend most of your time on Action. The Action section is where Ownership lives. Use 'I' (not 'we'), name the specific steps you took, and end with a quantified Result.

Weak · sample answer

42/100

So on my last team we had this issue where deployments kept failing on Fridays. We talked about it a lot in standup but nobody really owned it.

Vague situation, no personal stake
'We had this issue' doesn't tell the interviewer why it mattered, how big it was, or what your relationship to it was.

Eventually we decided as a team that something had to change, so we started looking into it together.

'We' framing erases ownership
The whole question is about *you* taking initiative when no one else did. 'We decided as a team' is the opposite signal.

I ended up helping out with some of the investigation and we figured out it was a config drift problem. After we fixed it, deploys got better.

I think the lesson is that sometimes you have to step up when something needs fixing.

No quantified Result
'Deploys got better' is unmeasurable. Interviewers will assume the impact was small or you didn't track it.

Why this scores weak

The answer describes a real problem and a real fix, but it sounds like a group story rather than yours. There's no clear moment where the candidate decided to act, no specific actions, and no measurable result.

Key takeaways

  • Replace every 'we' that describes a decision or action with 'I' if you were the one driving.
  • Name the moment you decided to take this on — what tipped you over.
  • End with a number: minutes saved, incidents prevented, % reduction in failures.

Average · sample answer

70/100

On my previous team, we owned the checkout service. About six months in I noticed that our on-call rotation was getting hammered every Friday afternoon — usually 2 or 3 pages, often the same kinds of deployment-related issues.

Nobody was officially assigned to look into it. The on-call engineer would resolve the immediate issue and move on. Our manager mentioned it a couple of times in 1:1s but didn't task anyone with the root cause.

Clear gap identified
Naming the gap — and that nobody was assigned to it — sets up the Ownership moment well.

I decided to dig into it. I pulled three months of pager logs and noticed the failures clustered around Friday afternoon deploys, specifically ones that touched the inventory configuration.

Personal initiative, concrete first step
'I decided to dig in' is the Ownership moment. Pulling pager logs is a specific, observable action.

I worked with the platform team to understand what was different about Fridays and eventually traced it to a config drift issue between staging and prod. I wrote a small validator that caught the drift before deploy, and we rolled it into the pipeline.

Skips over the harder Action
The interesting part is *how* you traced the drift and *how* you convinced the platform team to add your validator. This skips both.

After that, Friday pages dropped significantly. The team was happier and I think it helped reduce our on-call burden.

Why this scores average

Solid Ownership story with a clear gap, a clear personal initiative, and a real outcome. Held back by skipping over the technical details of the investigation and ending with vague impact ('dropped significantly' rather than a number).

Key takeaways

  • When you say you 'investigated' or 'worked with another team', describe the specific technical steps and the specific conversations.
  • Quantify the Result: '15 pages a quarter down to 2', '60% reduction', etc.
  • Mention any second-order effect — did this become a team norm? A doc? A runbook?

Strong · sample answer

91/100

About a year into my role on the checkout service, I noticed our on-call rotation was burning out — we'd been at 12-15 pages per week for two months, well above our team's 5/week SLO. The pages weren't going to my queue often, but I was watching them stack up in the channel.

Specific situation with numbers up front
12-15 pages vs a 5/week SLO is concrete. The interviewer immediately knows the scale.

There was no owner. On-call engineers would resolve the immediate page and move on — totally rational, because root-causing a flaky pager isn't a sprint commit. My manager had raised it twice in team meetings, but it kept getting deprioritized against feature work.

Acknowledges why nobody owned it
Showing you understand *why* the gap existed (it was rationally deprioritized) signals empathy, not just opportunism.

I decided to take it on outside my sprint commits. I spent two evenings pulling six months of pager data into a notebook and clustering by service, error class, and time-of-day. Three patterns popped: 70% of pages were deployment-related, 80% of those happened between 2pm Friday and 6am Saturday, and 60% of those touched the inventory config service.

Owning it on personal time, with concrete numbers
'Two evenings' shows you didn't ask permission. The 70/80/60 breakdown shows you actually did the analysis.

I wrote up a one-pager: this is the pattern, here's the data, here's a proposed two-week fix. I sent it to my manager and the platform team's tech lead. The platform TL pushed back at first — they thought it was a workflow problem, not an infra problem. I asked her to look at the data with me on a call, and after walking through the clusters she agreed there was a real config-drift root cause.

Handles disagreement, doesn't escalate it
The strongest part of this answer. You raised a problem, got pushback, and resolved it with data rather than authority.

I built a pre-deploy validator that compared staging and prod inventory configs and blocked deploys on drift. The platform team reviewed it and rolled it into the shared pipeline. I also wrote a runbook for the failure mode so future on-call engineers wouldn't have to rediscover the cause.

Pages dropped from 12-15/week to 3/week within a month, and stayed there. The runbook caught two unrelated config-drift bugs in other services over the next quarter. My manager later told me the validator pattern got picked up by two other teams.

Quantified Result + second-order impact
Three numbers, plus the spread to other teams. This is what 'Ownership at Amazon scale' looks like in an interview answer.

Why this scores strong

Hits every Ownership beat: identifies a gap that wasn't anyone's job, takes action on personal time, handles a real disagreement with data, ships a fix with measurable impact, and the fix propagates beyond the original team. The numbers throughout (12-15 → 3 pages/week, two other teams adopting the pattern) make the story unambiguous.

Key takeaways

  • Frame the Situation with a baseline and an SLO so the gap is quantifiable.
  • Show *why* the gap existed — it signals empathy, not just opportunism.
  • When you describe pushback, show how you resolved it with data rather than authority.
  • End with second-order impact (other teams adopted it, runbook caught unrelated bugs).