general

Insist on the Highest Standards: Amazon Interview Questions

Insist on the Highest Standards is the Amazon leadership principle about quality, and it is one of the easiest to misread. Candidates hear "high standards" and prepare a story about being a perfectionist. Interviewers are listening for something narrower: a moment when you refused to pass a known defect down the line, and what you changed so it never came back.

It comes up in almost every Amazon loop, for engineers, product managers and operations roles alike, usually paired with a principle that pulls the other way, such as Bias for Action or Deliver Results. The interviewer wants to see where your bar sits and how you defend it when a deadline is pushing on it.

This guide covers the official wording, what the principle looks like day to day, examples from real jobs, the questions to prepare for, and a worked STAR answer.

The official wording from Amazon

Leaders have relentlessly high standards; many people may think these standards are unreasonably high.

That is the opening of the principle on Amazon's leadership principles page. The rest of the text makes two further commitments: leaders keep raising the bar and push their teams to deliver high quality products, services and processes, and they make sure defects do not get sent down the line and that problems are fixed so they stay fixed. Read it as two separate tests. Do you stop bad work from moving forward, and do you fix the cause rather than the symptom.

What Insist on the Highest Standards means in practice

You define "done" before you start, in terms someone else could check: test coverage, an error budget, an accessibility pass, a customer who can complete the task unaided.
You stop the line. When you find a defect, you do not ship it with a ticket attached and a promise to fix it later, even when someone senior wants it out the door.
You trace problems to their root. A fix that makes the alert go quiet is not the same as a fix that removes the failure mode.
You raise the bar for the group, not just for yourself. Reviews, checklists and standards are written down so the team can hold them without you in the room.
You know which corners can never be cut and which "good enough" is honestly good enough. Amazon also prizes speed, and the principle is about judgment, not polish for its own sake.

Insist on the Highest Standards examples at work

A backend engineer and the flaky test. A deploy pipeline had one integration test that failed about one run in ten. The team had been re-running it for months. An engineer blocked her own release, spent a day finding the race condition behind it, and fixed the shared fixture. Re-runs dropped to zero.

A product manager and the launch date. A checkout redesign was due to ship on a date that had been announced internally. Two days before, usability testing showed that one in four testers could not find the promo code field. The PM pulled the launch by a week, took the heat in the planning meeting, and shipped a version with a measurably better completion rate.

A data analyst and the dashboard nobody trusted. Revenue numbers on a leadership dashboard disagreed with finance by a few percent, and everyone had learned to mentally adjust. The analyst refused to add a new chart until the discrepancy was explained, found a timezone bug in the nightly job, and wrote a reconciliation check that now runs every night.

A warehouse shift lead and the packing error rate. Mispacked orders were within the site's tolerance, so nobody was looking. The lead audited a sample, found that one station's scanner was misreading a label format, and had it replaced. The error rate for that line fell below the site average within a week.

Insist on the Highest Standards interview questions

Direct questions

Tell me about a time you weren't satisfied with the quality of something you delivered. What did you do?
Describe a time you pushed back on shipping something because it wasn't good enough.
Tell me about a time you raised the bar for your team. How did they react?
Have you ever fixed a recurring problem for good? How?
Describe a time high standards put you in conflict with a deadline. How did you resolve it?
Tell me about work a teammate produced that didn't meet your standards. What did you do?
What's an example of a standard you enforce that others consider excessive?
Tell me about a time you found a defect that others had accepted as normal.

Questions that test it indirectly

Walk me through how you decide something is ready to ship.
Tell me about a time you had to choose between fixing the root cause and applying a quick patch.
Describe a time you received a deliverable from another team that fell short. What happened next?
Tell me about a mistake that reached a customer. What did you change afterward?
How do you handle a situation where your manager's bar is lower than yours?
Tell me about a time you lowered your standard deliberately. Why was that the right call?

A sample STAR answer

Question: describe a time you pushed back on shipping something because it wasn't good enough.

Situation. I was the lead engineer on a payments service at a fintech startup. We had committed to a partner integration going live on a Monday, and the partner had already told its customers.

Task. On the Thursday before launch, our load test showed that about two percent of refund requests returned a success code while the refund never reached the ledger. The volume was small and the product manager suggested we launch and fix it in the first patch.

Action. I said no, and I was specific about why: a silent failure in money movement is a defect we cannot send down the line, because the customer sees a confirmation and the money never arrives. I proposed a two-day delay instead of an open-ended one, paired with another engineer to trace the bug to a retry path that swallowed a database timeout, and added an hourly check that compares refund confirmations against ledger entries. I also wrote the partner a short note explaining the delay and the reason.

Result. We launched on the Wednesday. The reconciliation check has caught two unrelated issues since, both before any customer noticed. The partner later said the honest delay note was the reason they trusted us with a second integration.

Why this answer works

The standard had a cost: a public date, a partner, a product manager pushing the other way.
It names the defect precisely and explains why this one could not be shipped, which shows judgment rather than blanket perfectionism.
The fix stayed fixed: a root-cause repair plus a mechanism that keeps checking after the story ends.

What the interviewer probes next

How did you know the two percent figure? Interviewers want to hear that you measured, not estimated.
What exactly did you do versus the other engineer? Amazon grades individuals. Be clear about your own decisions and hands-on work.
What did you give up? A credible story names the cost: a slipped date, a tense meeting, a weekend.
What would you do differently? A good answer is specific. For the example above: load-test refunds a week earlier, not three days before launch.
Which standard did you let slide? Saying "none" is a red flag. The interviewer wants to see that you can prioritize.

Common mistakes

Telling a perfectionism story. Spending three extra days on code formatting is not insisting on a standard; it misses the point of the principle.
Describing a team standard you inherited rather than one you set or defended yourself.
Stopping at the fix. If the story ends with the bug patched and nothing changed in the process, the interviewer will ask what prevents a repeat.
Blaming. The teammate who produced weak work is a setup, not a villain. The story is what you did about it.
Picking a story with no tension. If nobody pushed back and no deadline was at risk, the standard was never really tested.

Related leadership principles

Bias for Action is the deliberate counterweight: knowing which decisions are reversible is what keeps high standards from becoming slow.
Dive Deep is how you find the defect in the first place: auditing the detail instead of trusting the summary.
Deliver Results asks whether the standard was met on time, not just eventually.

The full list, with questions for every principle, is in the Amazon leadership principles guide.

Pressure-test your stories with a coach who has sat on an Amazon loop: get matched. Build the stories first with the STAR method guide and the story bank guide.