Amazon's leadership principles need story banks, not 16 scripts

The research has traced senior and new-grad candidates through dozens of Amazon loops, and the single biggest prep mistake is writing 16 separate STAR answers — one for each Leadership Principle.

That feels organized. It is almost always a trap.

Amazon publishes all 16 principles on its official Leadership Principles page, and Amazon Jobs explicitly tells candidates they will be evaluated on those principles throughout the loop. Dave Anderson, a former Amazon director and Bar Raiser who writes at Scarlet Ink, is even more blunt in his complete LP interview guide: Amazon recruiters routinely tell him they can spot which candidates have read his post and which have not.

That alone tells you the bar is not memorization. It is judgment under follow-up.

For software engineers, the winning move is a story bank: 6-8 real stories from your work, each tagged to multiple principles, each sturdy enough to survive a Bar Raiser digging into details.

What Amazon is actually testing

I've watched strong senior engineers get rejected at Amazon because their answers were polished in the wrong direction — smooth prose, no specifics. Most weak answers fail for one of these reasons:

1. The candidate says what the team did, not what they did.
2. The story has no numbers, so the impact sounds inflated.
3. The decision has no trade-off, so the judgment looks shallow.
4. The result sounds too perfect, so the answer feels rehearsed.
5. The candidate cannot handle a deeper "why?" or "what did you miss?" follow-up.

Amazon behavioral questions are usually trying to answer a smaller set of things, not 16 separate ones:

• When things were ambiguous, how did you decide?
• When something was broken, did you actually go deep enough to find the real failure mode?
• When the right move was uncomfortable, did you push for it?
• When the outcome mattered, did you deliver or just stay busy?
• When you made a mistake, did you own it and learn from it?

If your answer makes those points obvious, you do not need a dramatic story. Dave Anderson's Three Tales from an Amazon Bar Raiser walks through three real candidates where ordinary projects beat flashy ones because the ordinary candidate could explain the trade-off.

The principles that show up most for SWE candidates

You should know all 16 Leadership Principles at recognition level (Amazon added Strive to be Earth's Best Employer and Success and Scale Bring Broad Responsibility back in 2021, per Anderson's write-up of the two new principles). But for software engineering loops specifically, these are the ones I see come up constantly:

• Customer Obsession: Did you change the plan because a user, customer, or internal partner was getting hurt?
• Ownership: Did you solve the problem even when part of it sat outside your formal scope?
• Dive Deep: Did you go below dashboards and summaries to find the real failure mode?
• Bias for Action: Could you move with incomplete information without being reckless?
• Earn Trust: Could you handle disagreement without becoming defensive?
• Insist on the Highest Standards: Did you refuse to ship something half-correct?
• Have Backbone; Disagree and Commit: Could you push back clearly, then support the final decision?
• Deliver Results: When the deadline or incident pressure was real, did the outcome actually improve?

For senior and staff roles, interviewers probe more on:

• Think Big
• Hire and Develop the Best
• Strive to be Earth's Best Employer
• Success and Scale Bring Broad Responsibility

IGotAnOffer's Amazon behavioral guide confirms the same pattern: across 40+ common questions, the top frequency clusters sit in Ownership, Dive Deep, Customer Obsession, and Deliver Results.

That is the right mental model: not 16 unrelated scripts, but a smaller set of judgment themes that repeat.

Build a story bank, not a script bank

Start with 6-8 stories from your real work. Every round in an Amazon SDE loop, per the IGotAnOffer SDE guide, will land 1-2 behavioral questions — so a story bank of 6-8 covers your entire loop comfortably without you repeating the same story to the same interviewer.

A good set usually covers:

One story should cover multiple principles. That is the whole point. Here's how a single real engineering incident maps across three of them:

Diagram

Copy source

Rendering diagram...

That is much stronger than writing three separate fake stories for three separate principles. It is also exactly what Anderson argues in his behavioral deep dive: the principles are evaluation lenses, not story templates.

The answer shape that works

I teach STAR, but I teach it tighter than most career-advice templates. The IGotAnOffer rubric targets 2-3 minutes per answer. If your STAR answer runs longer than that, interviewers start losing thread and you lose the follow-up budget.

1. Situation

One or two sentences. No autobiography.

Bad: "We were a fast-growing startup with a lot of moving parts and many talented people across the organization..."

Better: "Our checkout p95 latency doubled after a vendor integration, and conversion on mobile dropped during a major promotion week."

2. Task

Say what you owned.

Not "we had to improve performance." Say "I owned the API path and was responsible for getting p95 back under one second before the sale launched."

3. Action

This is where I see most candidates stay too vague. Your action section needs:

• the decision you made
• the trade-off you accepted
• the evidence you used
• the part you personally drove

If you only say "I collaborated with the team," the interviewer has nothing to grade. Exponent's 2026 LP guide calls this "the we-trap," and it is easily the single most common killer of otherwise strong answers.

4. Result

Use numbers where possible:

• latency down from 1.9s to 700ms
• error rate down from 4.2% to 0.3%
• support tickets cut by 40%
• manual review time cut from 2 hours to 20 minutes

If you truly do not have business metrics, use engineering proxies:

• pages reduced
• rollback avoided
• build time improved
• time-to-detect or time-to-recover improved
• repeated incidents eliminated

5. Reflection

This is the Amazon part many candidates underuse.

Add one sentence on what you learned, what you would change, or what follow-on mechanism you put in place. That is how the answer stops sounding memorized and starts sounding like judgment.

The follow-up traps that sink people

Amazon follow-ups are where rehearsed answers usually break. Expect questions like:

• Why was that the right trade-off?
• What data changed your mind?
• What did you miss at first?
• Who disagreed with you?
• What would have happened if you had done nothing?
• How do you know the result was caused by your change?

Prepare your stories for that second layer. interviewing.io's LP guide points out the same thing from aggregated mock-interview data: the single strongest predictor of a behavioral pass is how the candidate answers 3-5 follow-ups deep, not the opening story.

For each story, write down:

1. the metric
2. the trade-off
3. the risk
4. the mistake
5. the next mechanism you added

If you can answer those five things without rambling, the story is probably strong enough.

Six question shapes worth practicing

These question shapes repeat in Amazon loops and map cleanly to the principles above. DesignGurus' LP interview guide lists 60+ variations, but they almost all compress into these six:

• Tell me about a time you changed direction because of customer evidence.
• Tell me about a time you took ownership outside your formal role.
• Tell me about a time you disagreed with a technical decision.
• Tell me about a time you had to move fast with incomplete data.
• Tell me about a time you found a root cause others had missed.
• Tell me about a failure and what you changed because of it.

Notice what is missing: abstract culture talk.

Amazon behavioral questions usually get stronger when they stay operational. Your best material is not "I am passionate and collaborative." It is "here is a real system, here was the pressure, here was my call, here is the evidence."

A 2-hour prep plan that is actually enough

If your loop is close, use this instead of trying to memorize everything.

Hour 1: Build the story bank

• Pick 6 stories from the last 2-3 years.
• Tag each with 2-4 Leadership Principles.
• For each story, write the metric, trade-off, and mistake.

Hour 2: Pressure-test the stories

• Say each answer out loud in 2 minutes.
• Add one likely follow-up question.
• Cut any opening that takes more than 20 seconds to reach the real problem.
• Replace vague verbs like "helped" or "supported" with the actual action you took.

That is enough to make your answers sound real.

If you are also preparing the coding side, pair this with the Amazon company page and a fast pass through Arrays and Hashing Interview Questions so the behavioral prep stays tied to the real SDE loop.

The goal is not to sound polished. The goal is to sound like an engineer who actually made hard calls and can explain them clearly.