What do interviewers evaluate in Have Backbone; Disagree and Commit questions?

Interviewers listen for signals like: Did you actually disagree with someone who had more authority or context, not just a peer who happened to agree later? Was your challenge backed by data and reasoning, or just a strongly held opinion? Did you challenge respectfully and persistently, or either cave early or burn the relationship?

gitGood.dev

Amazon LPAdvanced Premium

Have Backbone; Disagree and Commit (Amazon Leadership Principle)

Amazon's two-part bar: challenge decisions you disagree with respectfully, even when uncomfortable - then commit fully once the decision is made.

About this theme

Have Backbone; Disagree and Commit is the principle that leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting, and that they do not compromise for the sake of social cohesion. The second half is just as important: once a decision is made, they commit wholly, even if they personally argued against it. The hard part for engineers is that both halves have to show up in the same story - the conviction to push back hard, and the maturity to row in the same direction afterward without sandbagging or 'I told you so'. In interviews this is one of the most probed principles because it is easy to fake half of it. Interviewers will dig: did you actually disagree with someone who had more power or context than you, or did you just voice a preference and get your way? And critically, what did you do when the decision went against you? The strongest answers show a real, well-reasoned challenge backed by data, a clear moment the decision was made against your recommendation, and genuine, energetic commitment afterward - ideally with evidence you helped the chosen path succeed.

What interviewers are evaluating

→Did you actually disagree with someone who had more authority or context, not just a peer who happened to agree later?
→Was your challenge backed by data and reasoning, or just a strongly held opinion?
→Did you challenge respectfully and persistently, or either cave early or burn the relationship?
→When the decision went against you, did you commit fully - or sandbag, slow-roll, or say 'I told you so'?
→Can you separate the two halves cleanly and show both in one story?
→Do you know when to stop disagreeing - did you escalate appropriately and then disagree-and-commit?

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 strongly disagreed with your manager or a senior engineer.
?Describe a time you committed to a decision you had argued against.
?Give an example of when you challenged a technical direction the team had largely settled on.
?Tell me about a time you had to push back on a deadline or scope you thought was wrong.
?Describe a situation where you were overruled - what did you do next?
?Tell me about a time you defended an unpopular technical position.
?Describe a time you had to decide whether to keep fighting a decision or let it go.

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: losing the database argument, then making it work

Prompt: "Describe a time you committed to a decision you had argued against."

Situation: Our team was choosing the datastore for a new high-write event-ingestion service. Our staff engineer wanted to standardize on the company's existing PostgreSQL setup for operational simplicity. Based on our projected write pattern - about 12,000 writes per second at peak with append-only access - I believed a wide-column store was the right call and that Postgres would force painful sharding within a year.
Task: As the engineer who would own the service day to day, I felt obligated to challenge the choice before it was locked, and then to live with whatever was decided.
Action: I built the case rather than just objecting. I ran a load-test benchmark on both options at 1.5x projected peak, documented the Postgres write-amplification and the sharding work it would require at our growth rate, and walked the staff engineer and my manager through the numbers in a doc. I pushed twice over two meetings. The staff engineer weighed it and still chose Postgres, valuing the team's deep operational experience and the on-call burden of a new datastore over my throughput argument. Once that call was made, I committed completely: I designed the schema for the eventual sharding seam up front, set up the partitioning, and built the write-batching layer that made Postgres viable - I did not coast or wait to be proven right.
Result: The service has run on Postgres for over a year, handling peak load because of the batching and partitioning work I committed to after losing the argument. My disagreement was not wasted either - the sharding seam I insisted we design in made a later partition migration a two-day job instead of a quarter. The staff engineer cited the episode when supporting my promotion, specifically calling out that I argued hard and then made his decision succeed.

Why this works

What makes this strong: (1) both halves are present and distinct - a data-backed challenge against a more senior person, then full commitment; (2) commitment is concrete and energetic (built the batching layer that made the rejected choice work), not grudging; (3) no 'I told you so' - the engineer made the other path succeed; (4) it even shows the disagreement adding value (the sharding seam) without undermining the decision.

STRONG

Strong: pushing back on a risky launch date, committing after escalation

Prompt: "Tell me about a time you pushed back on a deadline you thought was wrong."

Situation: Product committed to a payment-feature launch in three weeks. Our PCI-relevant code path had no integration test coverage and I estimated we needed at least two more weeks to add it safely. The PM and my skip-level wanted to hit the date for a marketing moment.
Task: I was the engineer who would be on call for this code and who understood the compliance risk, so I felt responsible for challenging the date even though leadership clearly wanted it.
Action: I did not just say 'too risky' - I quantified it. I laid out the specific untested paths, the failure modes that could leak or mishandle card data, and the historical incident rate for changes shipped without integration coverage. I proposed a middle path: hit the marketing date by launching read-only and behind a flag at 5 percent, with the money-movement path gated until tests were in. I escalated once to my skip-level when the PM wanted to overrule me. Leadership heard it and decided to launch the full path on the original date anyway, accepting the risk for business reasons above my level. At that point I stopped arguing and committed - I reprioritized to write the highest-risk integration tests in the time we did have and ran a focused manual test pass to de-risk what I could.
Result: We launched on the date. The targeted tests I wrote after committing caught two real bugs in the refund path before release, and the launch had no payment incidents. I had disagreed as hard as I could with data and an escalation, and once overruled I spent my energy making the decision as safe as possible rather than protecting my position.

Why this works

What makes this strong: (1) the challenge is quantified and offers an alternative, not just resistance; (2) it shows appropriate escalation - disagreeing up one level - then knowing when to stop; (3) commitment is constructive: the engineer reduced the risk of the decision they opposed; (4) it resolves the tension honestly, not by being secretly right and waiting for failure.

WEAK

Weak: 'I disagreed and I turned out to be right'

Prompt: "Tell me about a time you disagreed with a decision."

Situation: My team wanted to use a new framework that I did not think was a good idea, but the lead really wanted it.
Task: I felt it was my job to say something because I had more experience with these kinds of migrations.
Action: I told them I thought it was a mistake and explained why a few times, but they went ahead with it anyway. I went along with it since I did not have a choice, but I kind of knew it would not go well. I did my parts but I was not super enthusiastic about it.
Result: It ended up causing a lot of problems later, just like I predicted, and we had to roll some of it back. Eventually people realized I had been right all along about the framework.

Why this is weak

Why this is weak: (1) the 'disagree' half is thin - 'I told them it was a mistake a few times' with no data, no benchmark, no reasoning; (2) the 'commit' half fails completely - 'I went along with it, was not super enthusiastic, did my parts' is sandbagging, the exact opposite of committing wholly; (3) the punchline is 'I was right all along', which is the I-told-you-so trap interviewers screen against; (4) no ownership of helping the chosen path succeed.

Common pitfalls

×Showing only the disagreement and skipping commitment - or showing only obedient commitment with no real challenge.
×Ending on 'and I was right', which reads as I-told-you-so and signals you would not commit when overruled.
×Disagreeing with a peer who later agreed with you - the principle wants tension against authority or genuine resistance.
×Sandbagging the committed work ('I did my parts but was not enthusiastic') - this fails the commit half outright.
×Challenging with opinion rather than data, so it reads as stubbornness instead of well-reasoned backbone.
×Never knowing when to stop - disagreeing endlessly or refusing to escalate-then-commit looks like poor judgment, not conviction.

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 commit after being overruled?' - give a concrete, energetic action you took to make the rejected decision succeed, not a feeling.
→If asked 'how far did you push?' - describe the number of times and the escalation path, showing you challenged hard but proportionately.
→If asked 'how did you know when to stop?' - explain you stopped once the right owner made an informed decision, even against you.
→If the interviewer probes 'were you right in the end?' - resist gloating; emphasize that you helped the chosen path work regardless of who was right.
→If asked about the relationship - show the disagreement was respectful and the relationship survived or strengthened, not that you won at a cost.

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Critical Feedback

General

Tested at every senior+ loop and every people-management interview. The signal is whether you deliver hard truths with care - or whether you avoid, soften beyond recognition, or wait for someone else to do it.

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

Have Backbone; Disagree and Commit (Amazon Leadership Principle)

Amazon's two-part bar: challenge decisions you disagree with respectfully, even when uncomfortable - then commit fully once the decision is made.

About this theme

What interviewers are evaluating

→Did you actually disagree with someone who had more authority or context, not just a peer who happened to agree later?
→Was your challenge backed by data and reasoning, or just a strongly held opinion?
→Did you challenge respectfully and persistently, or either cave early or burn the relationship?
→When the decision went against you, did you commit fully - or sandbag, slow-roll, or say 'I told you so'?
→Can you separate the two halves cleanly and show both in one story?
→Do you know when to stop disagreeing - did you escalate appropriately and then disagree-and-commit?

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 strongly disagreed with your manager or a senior engineer.
?Describe a time you committed to a decision you had argued against.
?Give an example of when you challenged a technical direction the team had largely settled on.
?Tell me about a time you had to push back on a deadline or scope you thought was wrong.
?Describe a situation where you were overruled - what did you do next?
?Tell me about a time you defended an unpopular technical position.
?Describe a time you had to decide whether to keep fighting a decision or let it go.

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: losing the database argument, then making it work

Prompt: "Describe a time you committed to a decision you had argued against."

Situation: Our team was choosing the datastore for a new high-write event-ingestion service. Our staff engineer wanted to standardize on the company's existing PostgreSQL setup for operational simplicity. Based on our projected write pattern - about 12,000 writes per second at peak with append-only access - I believed a wide-column store was the right call and that Postgres would force painful sharding within a year.
Task: As the engineer who would own the service day to day, I felt obligated to challenge the choice before it was locked, and then to live with whatever was decided.
Action: I built the case rather than just objecting. I ran a load-test benchmark on both options at 1.5x projected peak, documented the Postgres write-amplification and the sharding work it would require at our growth rate, and walked the staff engineer and my manager through the numbers in a doc. I pushed twice over two meetings. The staff engineer weighed it and still chose Postgres, valuing the team's deep operational experience and the on-call burden of a new datastore over my throughput argument. Once that call was made, I committed completely: I designed the schema for the eventual sharding seam up front, set up the partitioning, and built the write-batching layer that made Postgres viable - I did not coast or wait to be proven right.
Result: The service has run on Postgres for over a year, handling peak load because of the batching and partitioning work I committed to after losing the argument. My disagreement was not wasted either - the sharding seam I insisted we design in made a later partition migration a two-day job instead of a quarter. The staff engineer cited the episode when supporting my promotion, specifically calling out that I argued hard and then made his decision succeed.

Why this works

STRONG

Strong: pushing back on a risky launch date, committing after escalation

Prompt: "Tell me about a time you pushed back on a deadline you thought was wrong."

Situation: Product committed to a payment-feature launch in three weeks. Our PCI-relevant code path had no integration test coverage and I estimated we needed at least two more weeks to add it safely. The PM and my skip-level wanted to hit the date for a marketing moment.
Task: I was the engineer who would be on call for this code and who understood the compliance risk, so I felt responsible for challenging the date even though leadership clearly wanted it.
Action: I did not just say 'too risky' - I quantified it. I laid out the specific untested paths, the failure modes that could leak or mishandle card data, and the historical incident rate for changes shipped without integration coverage. I proposed a middle path: hit the marketing date by launching read-only and behind a flag at 5 percent, with the money-movement path gated until tests were in. I escalated once to my skip-level when the PM wanted to overrule me. Leadership heard it and decided to launch the full path on the original date anyway, accepting the risk for business reasons above my level. At that point I stopped arguing and committed - I reprioritized to write the highest-risk integration tests in the time we did have and ran a focused manual test pass to de-risk what I could.
Result: We launched on the date. The targeted tests I wrote after committing caught two real bugs in the refund path before release, and the launch had no payment incidents. I had disagreed as hard as I could with data and an escalation, and once overruled I spent my energy making the decision as safe as possible rather than protecting my position.

Why this works

WEAK

Weak: 'I disagreed and I turned out to be right'

Prompt: "Tell me about a time you disagreed with a decision."

Situation: My team wanted to use a new framework that I did not think was a good idea, but the lead really wanted it.
Task: I felt it was my job to say something because I had more experience with these kinds of migrations.
Action: I told them I thought it was a mistake and explained why a few times, but they went ahead with it anyway. I went along with it since I did not have a choice, but I kind of knew it would not go well. I did my parts but I was not super enthusiastic about it.
Result: It ended up causing a lot of problems later, just like I predicted, and we had to roll some of it back. Eventually people realized I had been right all along about the framework.

Why this is weak

Common pitfalls

×Showing only the disagreement and skipping commitment - or showing only obedient commitment with no real challenge.
×Ending on 'and I was right', which reads as I-told-you-so and signals you would not commit when overruled.
×Disagreeing with a peer who later agreed with you - the principle wants tension against authority or genuine resistance.
×Sandbagging the committed work ('I did my parts but was not enthusiastic') - this fails the commit half outright.
×Challenging with opinion rather than data, so it reads as stubbornness instead of well-reasoned backbone.
×Never knowing when to stop - disagreeing endlessly or refusing to escalate-then-commit looks like poor judgment, not conviction.

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 commit after being overruled?' - give a concrete, energetic action you took to make the rejected decision succeed, not a feeling.
→If asked 'how far did you push?' - describe the number of times and the escalation path, showing you challenged hard but proportionately.
→If asked 'how did you know when to stop?' - explain you stopped once the right owner made an informed decision, even against you.
→If the interviewer probes 'were you right in the end?' - resist gloating; emphasize that you helped the chosen path work regardless of who was right.
→If asked about the relationship - show the disagreement was respectful and the relationship survived or strengthened, not that you won at a cost.

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Critical Feedback

General

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 →