What do interviewers evaluate in Insist on the Highest Standards questions?

Interviewers listen for signals like: Did you raise the bar for a team or system, not just hold yourself to a high personal standard? Did you define the quality bar concretely (a metric, a checklist, an SLO) rather than gesturing at 'quality'? Did you fix problems so they stayed fixed - a durable mechanism, not a one-off heroic cleanup?

gitGood.dev

Amazon LPFoundational Premium

Insist on the Highest Standards (Amazon Leadership Principle)

Interviewers screen for a high bar you raised for others - not perfectionism on your own work. The trick is showing high standards without tanking delivery.

About this theme

Insist on the Highest Standards is one of Amazon's 16 Leadership Principles. It states that leaders have relentlessly high standards - standards many people may think are unreasonably high - that they continually raise the bar and drive their teams to deliver high-quality products, services, and processes, and that they ensure defects do not get sent down the line and problems get fixed so they stay fixed. The phrase "fixed so they stay fixed" is central: it is about durable quality through better processes, not heroic one-off cleanups. In interviews, the strongest version of this LP is not personal perfectionism; it is raising the bar for a team or system and making the higher standard stick. Interviewers listen for whether you defined a concrete quality bar, held the line when it was inconvenient, and built a mechanism - tests, a checklist, an SLO, an automated gate - so the standard did not erode the moment you looked away. They are also testing judgment: insisting on quality cannot mean blocking all delivery, so they probe how you balanced the bar against shipping. A weak answer is either "I just care about quality" with no mechanism, or rigid perfectionism that ignored real deadlines.

What interviewers are evaluating

→Did you raise the bar for a team or system, not just hold yourself to a high personal standard?
→Did you define the quality bar concretely (a metric, a checklist, an SLO) rather than gesturing at 'quality'?
→Did you fix problems so they stayed fixed - a durable mechanism, not a one-off heroic cleanup?
→Did you hold the line when it was inconvenient or unpopular to do so?
→Did you balance the standard against delivery, rather than letting perfectionism block shipping?
→Can you show the defect rate, incident count, or quality metric actually improved and stayed improved?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you raised the quality bar on your team.
?Describe a time you were not satisfied with the status quo and pushed for higher standards.
?Tell me about a time you refused to ship something that did not meet your standards.
?Give an example of when you had to balance quality against a deadline.
?Describe a time you fixed a recurring problem so it stayed fixed.
?Tell me about a time you held a high standard that others thought was excessive.
?How do you ensure quality across a team, not just in your own work?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Turned a flaky test suite into a hard merge gate

Prompt: "Tell me about a time you raised the quality bar on your team."

Situation: Our team's CI test suite was flaky enough that people routinely re-ran it until it passed or merged through red builds 'because it's probably just the flaky tests.' We were shipping real regressions - we had three customer-facing bugs in a quarter that a passing test would have caught, but nobody trusted the suite enough to gate on it.
Task: As a senior engineer I decided the bar had to change: a green build should mean something, and red should block merge. The hard part was getting there without halting everyone's delivery.
Action: Rather than mandate the gate overnight, I made the standard durable in stages. First I instrumented the suite to track per-test flake rates and quarantined the worst offenders into a separate non-blocking lane so the core suite became trustworthy. I fixed or deleted the top 15 flaky tests over two weeks, driving the core suite's flake rate from about 12 percent to under 1. Only then did I turn on the hard merge gate, with the team's buy-in because the suite was now reliable. I added a weekly flake report so any new flaky test got caught and triaged instead of silently eroding the bar again.
Result: Merging through red stopped entirely because red now meant a real failure. Customer-facing regressions from this team dropped from three that quarter to zero over the next two. The flake report kept the suite under 1 percent flaky for the following year - the standard stayed fixed because the mechanism, not vigilance, enforced it.

Why this works

What makes this strong: (1) Raised the bar for the whole team, not personal perfectionism. (2) Defined the bar concretely (flake rate, a merge gate). (3) Built a durable mechanism (the weekly report) so it stayed fixed. (4) Balanced the bar against delivery by sequencing - made the suite trustworthy before gating - so he didn't halt shipping.

STRONG

Strong: Held the line on a launch, but scoped it to ship on time

Prompt: "Give an example of when you had to balance quality against a deadline."

Situation: A week before a feature launch, I found that our new data-import flow had no handling for partial failures - if an import died halfway, it left the customer's account in a corrupted half-imported state with no way to recover. The PM wanted to ship on the committed date and 'fast-follow' the error handling.
Task: I was the engineer who owned the flow. I believed shipping a feature that could silently corrupt customer data was below the bar, but I also did not want to be the person who blocked a committed launch on perfectionism.
Action: Instead of a binary fight, I separated the non-negotiable from the nice-to-have. The non-negotiable bar was: no path that leaves data corrupted. So I proposed wrapping the import in a transaction with an all-or-nothing commit and a clear error message on failure - about two days of work - and explicitly deferred the richer retry-and-resume UX to the fast-follow. I showed the PM a concrete corruption scenario to make the risk real rather than arguing in the abstract.
Result: We shipped on the committed date with the atomic import. In the first month, the failure path triggered for about 4 percent of large imports and every one rolled back cleanly with zero corrupted accounts - exactly the cases that would have become support escalations and data-loss incidents. The richer resume UX shipped three weeks later as planned.

Why this works

What makes this strong: (1) Held a high standard (no data corruption) while explicitly NOT blocking the launch. (2) Defined the non-negotiable bar precisely and deferred the rest. (3) Made the risk concrete to win the argument. (4) Quantified that the bar mattered - 4 percent would have corrupted without it.

WEAK

Weak: 'I have really high standards'

Prompt: "Describe a time you were not satisfied with the status quo and pushed for higher standards."

Situation: The code on my team wasn't as clean as I would have liked.
Task: I wanted everything to be high quality.
Action: I always wrote really clean code myself and left detailed comments in code reviews when other people's code wasn't up to my standards. I cared a lot about doing things the right way.
Result: My own code was high quality and I think people knew I had high standards.

Why this is weak

Why this is weak: (1) Personal perfectionism, not raising a team or system bar. (2) No concrete standard defined - 'clean' and 'the right way' are subjective. (3) No durable mechanism - just nitpicking reviews, which erodes the moment he stops. (4) No metric and no balance with delivery; detailed review comments can read as a bottleneck, not leadership.

Common pitfalls

×Framing the story as personal perfectionism instead of raising the bar for a team or system.
×Defining 'quality' subjectively ('clean code,' 'the right way') with no concrete bar, metric, or gate.
×A heroic one-off cleanup with no mechanism, so the problem comes back the moment you stop watching.
×Rigid perfectionism that ignored a real deadline and blocked delivery - high standards without judgment.
×Nitpicking others' work in reviews and calling it 'high standards' rather than systemic improvement.
×No measurement that the standard actually improved defect rate, incidents, or quality, and that it stayed improved.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'How did you make it stick?' - point to the durable mechanism (a gate, an SLO, a recurring report) rather than personal vigilance.
→If asked 'How did you balance it with the deadline?' - show how you separated the non-negotiable bar from the nice-to-have and shipped on time.
→If asked 'How did you define the bar?' - have a concrete metric ready (flake rate, defect escape rate, p99, an explicit checklist).
→If asked 'Did anyone push back?' - describe holding the line with evidence (a concrete failure scenario), not just asserting authority.
→If pushed on whether you slowed the team down, show the standard reduced rework or incidents downstream, making the team faster overall.

Related behavioral themes

Tech Debt Pragmatism

General

The judgment test. Can you ship fast when speed matters, say no to over-engineering, AND make the case for paying down debt when it's earning interest - or do you have a single mode?

Dive Deep

Amazon LP

Leaders operate at all levels. The interviewer is testing whether you actually understand your own systems - or whether you summarize what your team built.

Companies that test this theme

Amazon

SDE II

Amazon

Senior SDE (L6 / SDE III)

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

Amazon LPFoundational Premium

Insist on the Highest Standards (Amazon Leadership Principle)

Interviewers screen for a high bar you raised for others - not perfectionism on your own work. The trick is showing high standards without tanking delivery.

About this theme

What interviewers are evaluating

→Did you raise the bar for a team or system, not just hold yourself to a high personal standard?
→Did you define the quality bar concretely (a metric, a checklist, an SLO) rather than gesturing at 'quality'?
→Did you fix problems so they stayed fixed - a durable mechanism, not a one-off heroic cleanup?
→Did you hold the line when it was inconvenient or unpopular to do so?
→Did you balance the standard against delivery, rather than letting perfectionism block shipping?
→Can you show the defect rate, incident count, or quality metric actually improved and stayed improved?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you raised the quality bar on your team.
?Describe a time you were not satisfied with the status quo and pushed for higher standards.
?Tell me about a time you refused to ship something that did not meet your standards.
?Give an example of when you had to balance quality against a deadline.
?Describe a time you fixed a recurring problem so it stayed fixed.
?Tell me about a time you held a high standard that others thought was excessive.
?How do you ensure quality across a team, not just in your own work?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: Turned a flaky test suite into a hard merge gate

Prompt: "Tell me about a time you raised the quality bar on your team."

Situation: Our team's CI test suite was flaky enough that people routinely re-ran it until it passed or merged through red builds 'because it's probably just the flaky tests.' We were shipping real regressions - we had three customer-facing bugs in a quarter that a passing test would have caught, but nobody trusted the suite enough to gate on it.
Task: As a senior engineer I decided the bar had to change: a green build should mean something, and red should block merge. The hard part was getting there without halting everyone's delivery.
Action: Rather than mandate the gate overnight, I made the standard durable in stages. First I instrumented the suite to track per-test flake rates and quarantined the worst offenders into a separate non-blocking lane so the core suite became trustworthy. I fixed or deleted the top 15 flaky tests over two weeks, driving the core suite's flake rate from about 12 percent to under 1. Only then did I turn on the hard merge gate, with the team's buy-in because the suite was now reliable. I added a weekly flake report so any new flaky test got caught and triaged instead of silently eroding the bar again.
Result: Merging through red stopped entirely because red now meant a real failure. Customer-facing regressions from this team dropped from three that quarter to zero over the next two. The flake report kept the suite under 1 percent flaky for the following year - the standard stayed fixed because the mechanism, not vigilance, enforced it.

Why this works

STRONG

Strong: Held the line on a launch, but scoped it to ship on time

Prompt: "Give an example of when you had to balance quality against a deadline."

Situation: A week before a feature launch, I found that our new data-import flow had no handling for partial failures - if an import died halfway, it left the customer's account in a corrupted half-imported state with no way to recover. The PM wanted to ship on the committed date and 'fast-follow' the error handling.
Task: I was the engineer who owned the flow. I believed shipping a feature that could silently corrupt customer data was below the bar, but I also did not want to be the person who blocked a committed launch on perfectionism.
Action: Instead of a binary fight, I separated the non-negotiable from the nice-to-have. The non-negotiable bar was: no path that leaves data corrupted. So I proposed wrapping the import in a transaction with an all-or-nothing commit and a clear error message on failure - about two days of work - and explicitly deferred the richer retry-and-resume UX to the fast-follow. I showed the PM a concrete corruption scenario to make the risk real rather than arguing in the abstract.
Result: We shipped on the committed date with the atomic import. In the first month, the failure path triggered for about 4 percent of large imports and every one rolled back cleanly with zero corrupted accounts - exactly the cases that would have become support escalations and data-loss incidents. The richer resume UX shipped three weeks later as planned.

Why this works

WEAK

Weak: 'I have really high standards'

Prompt: "Describe a time you were not satisfied with the status quo and pushed for higher standards."

Situation: The code on my team wasn't as clean as I would have liked.
Task: I wanted everything to be high quality.
Action: I always wrote really clean code myself and left detailed comments in code reviews when other people's code wasn't up to my standards. I cared a lot about doing things the right way.
Result: My own code was high quality and I think people knew I had high standards.

Why this is weak

Common pitfalls

×Framing the story as personal perfectionism instead of raising the bar for a team or system.
×Defining 'quality' subjectively ('clean code,' 'the right way') with no concrete bar, metric, or gate.
×A heroic one-off cleanup with no mechanism, so the problem comes back the moment you stop watching.
×Rigid perfectionism that ignored a real deadline and blocked delivery - high standards without judgment.
×Nitpicking others' work in reviews and calling it 'high standards' rather than systemic improvement.
×No measurement that the standard actually improved defect rate, incidents, or quality, and that it stayed improved.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→If asked 'How did you make it stick?' - point to the durable mechanism (a gate, an SLO, a recurring report) rather than personal vigilance.
→If asked 'How did you balance it with the deadline?' - show how you separated the non-negotiable bar from the nice-to-have and shipped on time.
→If asked 'How did you define the bar?' - have a concrete metric ready (flake rate, defect escape rate, p99, an explicit checklist).
→If asked 'Did anyone push back?' - describe holding the line with evidence (a concrete failure scenario), not just asserting authority.
→If pushed on whether you slowed the team down, show the standard reduced rework or incidents downstream, making the team faster overall.

Related behavioral themes

Tech Debt Pragmatism

General

The judgment test. Can you ship fast when speed matters, say no to over-engineering, AND make the case for paying down debt when it's earning interest - or do you have a single mode?

Dive Deep

Amazon LP

Leaders operate at all levels. The interviewer is testing whether you actually understand your own systems - or whether you summarize what your team built.

Companies that test this theme

Amazon

SDE II

Amazon

Senior SDE (L6 / SDE III)

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →