What do interviewers evaluate in Are Right, A Lot questions?

Interviewers listen for signals like: Did you reason from the data available at the time, or are you narrating with hindsight bias? Did you actively seek to disconfirm your own view - dissenting opinions, a devil's advocate, contradicting data? Did you state in advance what would change your mind, then actually update when it did?

gitGood.dev

Amazon LPAdvanced Premium

Are Right, A Lot (Amazon Leadership Principle)

This LP is a trap if you read it as 'I'm always right.' Interviewers screen for strong judgment under uncertainty AND willingness to be disconfirmed.

About this theme

Are Right, A Lot is one of Amazon's 16 Leadership Principles. The principle states that leaders are right a lot, that they have strong judgment and good instincts, and - critically - that they seek diverse perspectives and work to disconfirm their own beliefs. The second half is what most candidates miss. The principle is not about being infallible; it is about having a process that produces correct decisions more often than not, which necessarily includes actively hunting for evidence that you are wrong before you commit. In interviews, this LP is one of the harder ones to answer well because the obvious reading - "tell me about a time you were right" - leads candidates into arrogant, hindsight-biased stories. Skilled interviewers probe the reasoning you used at the moment of decision, when the outcome was still unknown. They want to hear how you weighed limited data, where you sought a dissenting opinion, what would have changed your mind, and how you updated when new information arrived. They will often pair this with a "tell me about a time you were wrong" follow-up to test whether your judgment is calibrated or just lucky. This is typically asked of senior and above candidates.

What interviewers are evaluating

→Did you reason from the data available at the time, or are you narrating with hindsight bias?
→Did you actively seek to disconfirm your own view - dissenting opinions, a devil's advocate, contradicting data?
→Did you state in advance what would change your mind, then actually update when it did?
→Did you make a sound decision under genuine uncertainty, with incomplete information?
→Are your good outcomes the result of repeatable judgment, or were you simply lucky?
→Can you separate the quality of the decision from the quality of the outcome?

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 made a decision with incomplete information.
?Describe a time your judgment turned out to be right when others disagreed.
?Tell me about a time you had to make a hard call quickly.
?Give an example of a time you were wrong and how you handled it.
?Describe a time you changed your mind based on new data.
?Tell me about a time you relied on instinct or experience rather than data.
?How do you make decisions when the team is split?

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: Called a risky launch hold, then disconfirmed my own fear

Prompt: "Tell me about a time you made a decision with incomplete information."

Situation: Two days before a major checkout redesign launch, our load test showed p99 latency spiking to 3 seconds under peak load, but only intermittently and only in one of three test runs. The team was split: half wanted to launch on schedule because the spike was inconsistent, half wanted to hold indefinitely. We had real revenue pressure to ship for the holiday season.
Task: As the tech lead I owned the go/no-go recommendation, and I had maybe 24 hours of data and no clean reproduction.
Action: Rather than trust my gut that it was a real risk, I tried to disconfirm my own fear. I stated up front what would change my mind: if we could prove the spike was a test-harness artifact, I would say launch. I had two engineers reproduce in a clean environment while I pulled the connection-pool metrics myself. We found a pool that exhausted under a specific concurrency pattern - a real bug, not an artifact. I also explicitly invited the strongest 'launch now' engineer to argue against me, and his pushback surfaced that the bug only triggered above a traffic level we would not hit for a week. So I made a calibrated call: launch on schedule but with a feature flag and a hard auto-rollback at p99 over 1 second, and fix the pool bug in parallel within the week.
Result: We launched on time. The flag never tripped because we shipped the pool fix three days later, before traffic reached the dangerous level. Checkout conversion improved 4 percent. Most importantly, the decision held up because it was based on the actual mechanism, not on who argued loudest.

Why this works

What makes this strong: (1) Reasons from data available at the time, not hindsight. (2) Explicitly states what would change his mind, then tests it. (3) Invites the strongest dissent rather than avoiding it. (4) Separates a calibrated decision (flag + auto-rollback) from a binary gut call.

STRONG

Strong: Was wrong about a database choice and updated fast

Prompt: "Give an example of a time you were wrong and how you handled it."

Situation: I championed moving a high-write analytics service from Postgres to a document store, arguing the flexible schema would speed up our iteration. I was fairly confident based on past experience. We migrated about 30 percent of the workload over six weeks.
Task: Three weeks in, our query latency for the dashboard team's aggregation queries got noticeably worse, and I had to decide whether to push through or reverse my own recommendation.
Action: I had committed up front to a kill criterion: if aggregation p95 regressed by more than 50 percent and we could not recover it in two weeks of tuning, we would roll back. We hit that criterion. Rather than defend my original call, I pulled the query plans and benchmarks, presented the data to the team including the parts that contradicted me, and recommended we reverse. I owned that I had over-indexed on write flexibility and under-weighted the read patterns that actually dominated this workload. We rolled the 30 percent back to Postgres and added partitioning instead.
Result: The rollback took one sprint because we had migrated incrementally and kept the old path warm. Aggregation p95 returned to baseline. The partitioning approach we landed on cut write contention by about 40 percent without the read regression. The team's trust in my judgment actually went up, because I had pre-committed to the kill criterion and honored it.

Why this works

What makes this strong: (1) Owns being wrong without excuses. (2) Pre-committed to a falsifiable kill criterion - the hallmark of calibrated judgment. (3) Presented the disconfirming data himself rather than burying it. (4) Shows that updating fast preserved trust, reframing 'wrong' as good process.

WEAK

Weak: 'I just knew I was right'

Prompt: "Describe a time your judgment turned out to be right when others disagreed."

Situation: My team wanted to use a certain approach but I had a feeling it was a bad idea.
Task: I needed to convince them I was right.
Action: I told them based on my experience it wouldn't work, and I pushed for my approach instead. Eventually they went along with it because I was pretty sure about it.
Result: It turned out I was right and my approach worked better. They should have listened to me sooner.

Why this is weak

Why this is weak: (1) Pure gut and authority - no data, no reasoning at the time. (2) Zero attempt to disconfirm his own view or seek dissent. (3) Hindsight bias and arrogance ('they should have listened') - the opposite of seeking diverse perspectives. (4) No metrics, no mechanism, no evidence the outcome wasn't luck.

Common pitfalls

×Reading the LP as 'I'm always right' and telling an arrogant, hindsight-biased story.
×Relying on gut and authority with no description of the reasoning or data used at the time.
×Never mentioning seeking a dissenting view, a devil's advocate, or contradicting evidence.
×Being unable to state what would have changed your mind, which signals you were not actually open to being wrong.
×Confusing a good outcome with a good decision - claiming credit for what was actually luck.
×Picking only 'I was right' stories and freezing when asked the 'tell me about a time you were wrong' follow-up.

Follow-up strategies

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

→Expect a paired 'tell me about a time you were wrong' question - prepare a story where you updated fast, and lead with the kill criterion you set in advance.
→If asked 'What would have changed your mind?' - have a concrete, falsifiable answer ready; vagueness here reads as closed-mindedness.
→If asked 'How did you separate the decision from the outcome?' - explain the information you had at the moment of the call, not what you learned later.
→If asked 'Who disagreed and what did they say?' - name the dissent and show you engaged it seriously, not that you steamrolled it.
→If pressed on luck, point to the repeatable process (data pulled, dissent invited, criteria pre-committed) that would produce the same call again.

Related behavioral themes

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.

Learning from Failure

Microsoft

Microsoft's Growth Mindset core. Also tested at Google, Anthropic, and any company that screens for self-awareness. The signal is whether you actually changed.

Companies that test this theme

Amazon

Senior SDE (L6 / SDE III)

Amazon

Principal SDE (L7)

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 LPAdvanced Premium

Are Right, A Lot (Amazon Leadership Principle)

This LP is a trap if you read it as 'I'm always right.' Interviewers screen for strong judgment under uncertainty AND willingness to be disconfirmed.

About this theme

What interviewers are evaluating

→Did you reason from the data available at the time, or are you narrating with hindsight bias?
→Did you actively seek to disconfirm your own view - dissenting opinions, a devil's advocate, contradicting data?
→Did you state in advance what would change your mind, then actually update when it did?
→Did you make a sound decision under genuine uncertainty, with incomplete information?
→Are your good outcomes the result of repeatable judgment, or were you simply lucky?
→Can you separate the quality of the decision from the quality of the outcome?

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 made a decision with incomplete information.
?Describe a time your judgment turned out to be right when others disagreed.
?Tell me about a time you had to make a hard call quickly.
?Give an example of a time you were wrong and how you handled it.
?Describe a time you changed your mind based on new data.
?Tell me about a time you relied on instinct or experience rather than data.
?How do you make decisions when the team is split?

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: Called a risky launch hold, then disconfirmed my own fear

Prompt: "Tell me about a time you made a decision with incomplete information."

Situation: Two days before a major checkout redesign launch, our load test showed p99 latency spiking to 3 seconds under peak load, but only intermittently and only in one of three test runs. The team was split: half wanted to launch on schedule because the spike was inconsistent, half wanted to hold indefinitely. We had real revenue pressure to ship for the holiday season.
Task: As the tech lead I owned the go/no-go recommendation, and I had maybe 24 hours of data and no clean reproduction.
Action: Rather than trust my gut that it was a real risk, I tried to disconfirm my own fear. I stated up front what would change my mind: if we could prove the spike was a test-harness artifact, I would say launch. I had two engineers reproduce in a clean environment while I pulled the connection-pool metrics myself. We found a pool that exhausted under a specific concurrency pattern - a real bug, not an artifact. I also explicitly invited the strongest 'launch now' engineer to argue against me, and his pushback surfaced that the bug only triggered above a traffic level we would not hit for a week. So I made a calibrated call: launch on schedule but with a feature flag and a hard auto-rollback at p99 over 1 second, and fix the pool bug in parallel within the week.
Result: We launched on time. The flag never tripped because we shipped the pool fix three days later, before traffic reached the dangerous level. Checkout conversion improved 4 percent. Most importantly, the decision held up because it was based on the actual mechanism, not on who argued loudest.

Why this works

STRONG

Strong: Was wrong about a database choice and updated fast

Prompt: "Give an example of a time you were wrong and how you handled it."

Situation: I championed moving a high-write analytics service from Postgres to a document store, arguing the flexible schema would speed up our iteration. I was fairly confident based on past experience. We migrated about 30 percent of the workload over six weeks.
Task: Three weeks in, our query latency for the dashboard team's aggregation queries got noticeably worse, and I had to decide whether to push through or reverse my own recommendation.
Action: I had committed up front to a kill criterion: if aggregation p95 regressed by more than 50 percent and we could not recover it in two weeks of tuning, we would roll back. We hit that criterion. Rather than defend my original call, I pulled the query plans and benchmarks, presented the data to the team including the parts that contradicted me, and recommended we reverse. I owned that I had over-indexed on write flexibility and under-weighted the read patterns that actually dominated this workload. We rolled the 30 percent back to Postgres and added partitioning instead.
Result: The rollback took one sprint because we had migrated incrementally and kept the old path warm. Aggregation p95 returned to baseline. The partitioning approach we landed on cut write contention by about 40 percent without the read regression. The team's trust in my judgment actually went up, because I had pre-committed to the kill criterion and honored it.

Why this works

WEAK

Weak: 'I just knew I was right'

Prompt: "Describe a time your judgment turned out to be right when others disagreed."

Situation: My team wanted to use a certain approach but I had a feeling it was a bad idea.
Task: I needed to convince them I was right.
Action: I told them based on my experience it wouldn't work, and I pushed for my approach instead. Eventually they went along with it because I was pretty sure about it.
Result: It turned out I was right and my approach worked better. They should have listened to me sooner.

Why this is weak

Common pitfalls

×Reading the LP as 'I'm always right' and telling an arrogant, hindsight-biased story.
×Relying on gut and authority with no description of the reasoning or data used at the time.
×Never mentioning seeking a dissenting view, a devil's advocate, or contradicting evidence.
×Being unable to state what would have changed your mind, which signals you were not actually open to being wrong.
×Confusing a good outcome with a good decision - claiming credit for what was actually luck.
×Picking only 'I was right' stories and freezing when asked the 'tell me about a time you were wrong' follow-up.

Follow-up strategies

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

→Expect a paired 'tell me about a time you were wrong' question - prepare a story where you updated fast, and lead with the kill criterion you set in advance.
→If asked 'What would have changed your mind?' - have a concrete, falsifiable answer ready; vagueness here reads as closed-mindedness.
→If asked 'How did you separate the decision from the outcome?' - explain the information you had at the moment of the call, not what you learned later.
→If asked 'Who disagreed and what did they say?' - name the dissent and show you engaged it seriously, not that you steamrolled it.
→If pressed on luck, point to the repeatable process (data pulled, dissent invited, criteria pre-committed) that would produce the same call again.

Related behavioral themes

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.

Learning from Failure

Microsoft

Microsoft's Growth Mindset core. Also tested at Google, Anthropic, and any company that screens for self-awareness. The signal is whether you actually changed.

Companies that test this theme

Amazon

Senior SDE (L6 / SDE III)

Amazon

Principal SDE (L7)

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 →