Prepare stories, not sixteen separate answers. Eight well-chosen engineering stories, each with your own decision, a number and a lesson, cover every principle. Rehearse each in STAR order for two to three minutes, and expect follow-up questions that go one level deeper than your script.
How Amazon uses the Leadership Principles in interviews
Amazon's interview-loop page says all candidates are evaluated through the lens of the principles and that its interviews focus on behavioral questions about real past experience, not brain teasers. The SDE II preparation page adds the detail engineers need: four 55-minute interviews, competencies assigned to different interviewers, and typically two or three behavioral questions from each interviewer. Multiplied out, that is roughly 8 to 12 principle questions in one day, next to coding and system design. The range is this guide's arithmetic, not a number Amazon publishes.
You cannot know which principles your interviewers were assigned, and the interview-loop page advises treating every interviewer the same way instead of tailoring answers to their role. So prepare a small bank of true stories you can tell from several angles, not one polished answer per principle. Amazon's pages size the loop differently for different audiences, as the table shows; confirm your format with the recruiter.
| Fact | What the page says | Where |
|---|---|---|
| Number of principles | 16, from Customer Obsession to Success and Scale Bring Broad Responsibility | Leadership Principles page |
| Who you meet | Likely two to seven people, possibly including a Bar Raiser | Interview loop page |
| Length of each interview | Around 45 minutes to an hour | Interview loop page |
| Loop size in general | Four to six interviews of 45 to 60 minutes | About Amazon interview guide |
| SDE II loop | Four 55-minute interviews | SDE II interview prep page |
| Behavioral questions | Typically two or three per interviewer | SDE II interview prep page |
| Length of a STAR answer | Typically 2 to 3 minutes | About Amazon interview guide |
| Decision after the loop | Expect to hear within five business days | Interview loop page |
Principles 1–8: sample questions and what to show
The names are exactly as Amazon lists them, in Amazon's order. The other columns are this guide's reading for software engineers, not Amazon's descriptions, and the sample questions are illustrations, not official or leaked ones. Read Amazon's own wording before your interview.
Two of the first eight are easy to misread. Are Right, A Lot is not about never being wrong: Amazon's text describes leaders who seek diverse perspectives and work to disconfirm their beliefs, so include the moment someone challenged you. Hire and Develop the Best applies to engineers who have never managed anyone; a mentoring or code-review story fits.
| Principle | What interviewers probe | Sample question | A strong engineering story shows |
|---|---|---|---|
| Customer Obsession | Whether you start from the user's problem, not the ticket | Tell me about a time you changed a technical plan because of what a customer needed. | A real user or internal customer, the signal you noticed, and a decision that cost you something |
| Ownership | Whether you act beyond your team's boundary and past the release date | Describe a problem outside your area that you fixed anyway. | You picked up an unowned issue, took it to production and handled the follow-up |
| Invent and Simplify | Whether you remove complexity instead of adding it | Tell me about a system you made simpler. | What you deleted or replaced, with before and after in code, steps or pages |
| Are Right, A Lot | Judgment with incomplete data, and whether you look for evidence against yourself | Tell me about a decision you made without the data you wanted. | The options you weighed, who challenged you, and how the outcome tested your call |
| Learn and Be Curious | Whether you learn quickly and on purpose | Tell me about something you had to learn fast in order to ship. | What you did not know, how you learned it, and where you used it next |
| Hire and Develop the Best | Whether you raise other people's level | Tell me about someone you helped grow. | A visible change in a teammate's work: a design they led, a review habit, a promotion case |
| Insist on the Highest Standards | Whether you hold a quality bar when it is inconvenient | Tell me about a time you refused to ship something. | The class of defect you caught, the standard you set, and the mechanism that keeps it |
| Think Big | Whether you see beyond the assigned task | Tell me about an idea of yours that was bigger than your ticket. | A proposal with reach beyond your team, how you sold it, and what exists today |
Principles 9–16: sample questions and what to show
Bias for Action is not permission to be reckless: Amazon's wording rests on many decisions being reversible and on calculated risk, so say why yours was reversible and which guardrail you added. Frugality means accomplishing more with less, not being cheap. Have Backbone; Disagree and Commit has two halves, and a story that ends at the disagreement shows only the first.
The last two are easy to neglect. Strive to be Earth’s Best Employer asks whether you made work safer, fairer or more productive for the people around you; on-call, onboarding or review-culture changes qualify. Success and Scale Bring Broad Responsibility is about secondary effects, which for engineers usually means privacy, accessibility, safety or cost.
| Principle | What interviewers probe | Sample question | A strong engineering story shows |
|---|---|---|---|
| Bias for Action | Speed with calculated risk, and whether you can tell reversible from irreversible | Tell me about a time you acted before you had full information. | Why the decision was reversible, the guardrail you added, and what waiting would have cost |
| Frugality | Whether constraints make you more inventive | Tell me about a time you delivered with less than you asked for. | A limit on people, budget or hardware and the cheaper design it forced |
| Earn Trust | Candor and self-criticism | Tell me about a time you had to admit a mistake or deliver bad news. | What you said, to whom, how soon, and how the working relationship went afterward |
| Dive Deep | Whether you know your details and audit your metrics | Tell me about a time a metric and what people told you disagreed. | The layer you dug down to (query, log, packet), what you found, and the corrected number |
| Have Backbone; Disagree and Commit | Respectful dissent, then full commitment | Tell me about a time you disagreed with a decision and lost. | Your argument with evidence, the decision, and proof that you then executed it fully |
| Deliver Results | Whether you finish despite setbacks | Tell me about a commitment that was at risk and how you landed it. | The obstacle, what you cut or re-planned, and the outcome against the date |
| Strive to be Earth’s Best Employer | Whether you make the team safer, more effective and more inclusive | Tell me about something you did that made your team's working life better. | A change to on-call, onboarding or review culture, and its effect on people |
| Success and Scale Bring Broad Responsibility | Awareness of second-order effects | Tell me about a time you weighed the wider impact of a technical decision. | A privacy, accessibility, safety or cost consequence you raised, and what changed |
A story bank: eight stories that cover all 16 principles
A real engineering story usually demonstrates several principles at once, which is why a bank works better than sixteen scripts. In the table every principle leads at least one story and 15 of the 16 appear twice; only Success and Scale Bring Broad Responsibility rests on a single story, so prepare a second example for it.
Build your own version in a spreadsheet: one row per story, one column per principle, a mark where the story has evidence. An empty column is a gap to fill before the interview; a row with six marks is a story you will be tempted to overuse. Amazon's loop page asks for range, including times you took risks, failed and grew.
| Story | Leads with | Also supports |
|---|---|---|
| An incident you caused and fixed | Ownership · Dive Deep | Earn Trust · Insist on the Highest Standards |
| A system you simplified, with a junior teammate owning one part | Invent and Simplify · Think Big | Hire and Develop the Best · Frugality |
| A design disagreement you lost, then supported | Have Backbone; Disagree and Commit · Earn Trust | Are Right, A Lot |
| A customer problem you chased across team boundaries | Customer Obsession · Bias for Action | Ownership · Dive Deep |
| A launch delivered with less time or budget than planned | Deliver Results · Frugality | Bias for Action · Have Backbone; Disagree and Commit |
| A new domain you learned to unblock a project | Learn and Be Curious · Are Right, A Lot | Invent and Simplify · Deliver Results |
| Mentoring, or raising the code-review bar | Hire and Develop the Best · Insist on the Highest Standards | Strive to be Earth’s Best Employer · Learn and Be Curious |
| A decision with wider impact: privacy, accessibility or on-call load | Success and Scale Bring Broad Responsibility · Strive to be Earth’s Best Employer | Customer Obsession · Think Big |
STAR with numbers: one worked Dive Deep answer
Amazon's loop page calls STAR one way to structure an answer, not the only one, and is specific about the content: the context, your task, the actions you personally took, and the outcome with what you learned. Amazon asks for “I” instead of “we”, for metrics or data where applicable, and for one detailed situation per question. The About Amazon guide says STAR responses typically last two to three minutes.
The answer below is an invented illustration for a Dive Deep question. It has a baseline (99.6%), the anecdote that contradicted it (41 tickets), the layer reached (request logs, then one call without a timeout), the corrected number (97.1%), the result, and a habit that outlived the project. At a little over 200 words it fits inside that guide length. Time your own draft aloud, and if it runs past three minutes, cut Situation first.
Then prepare for follow-ups: why the remaining five tickets differed, why two seconds, who disagreed with changing the dashboard. If you cannot answer one level deeper, the story is not ready. Never invent numbers; an honest “about a third” survives follow-ups better than a precise figure you cannot defend.
Question: "Tell me about a time a metric and what you were hearing did not match."
S I was the backend engineer for the checkout API of a grocery-delivery app. Our
dashboard showed a 99.6% payment success rate, but support had logged 41 tickets
in one week from customers whose payment screen "just kept spinning".
T Nobody owned the gap between the two. My service sat between the app and the
payment provider, so I took it.
A I matched all 41 tickets to request logs. For 36 of them we had no failed payment
on record: the app had given up after 10 seconds, and our success rate was computed
from server responses, so those attempts were never counted. I traced the slow
requests to a fraud-check call that had no timeout and was slow for cards from one
bank. I added a 2-second timeout with a fallback to an asynchronous check, added a
client event for abandoned attempts, and rebuilt the dashboard on client attempts.
R The corrected metric put real success at 97.1%, not 99.6%. Two weeks after the fix
it was 99.3%, and tickets about spinning payments fell from 41 a week to 3.
I now ask of every new metric: where is it measured, and what can it not see?The Bar Raiser and the debrief, in Amazon's words
Amazon's interview-loop page describes the Bar Raiser as someone from another team who is focused on hiring quality. The page does not say you will be told who it is, and guessing does not help. It also explains the typing you will see: interviewers take detailed notes to share with the rest of the team.
An About Amazon article from October 2019 adds detail. It describes Bar Raisers as objective third-party advisers who are nominated by their manager, peers or other Bar Raisers and who train for three months to a year alongside their regular job. The program's stated goal is that every new hire has growth potential and brings skills better than 50% of would-be peers in similar roles. In the debrief the Bar Raiser facilitates a data-driven discussion among the interviewers, and the article says the Bar Raiser and the hiring manager make the hiring decision. It counted more than 3,600 Bar Raisers; treat that as a 2019 figure.
- Any interviewer may be the Bar Raiser and comes from another team, so explain the system and its acronyms in one sentence.
- Interviewers take notes for the debrief, so state your result as a number someone can write down.
Common failures in Leadership Principle answers
Weak answers tend to fail in ways Amazon's own guidance warns about. The loop page asks for real examples instead of generalizations, your individual contribution, and results backed by data. It also says not every story has to be a success, and suggests pausing after an answer to ask whether the interviewer wants more context. Run these checks on a recording of yourself.
- “We” throughout, or no number: say “I” for your decisions and give a baseline and a result.
- A hypothetical: “I would” answers a different question. Use a real past event, even a small one.
- Naming the principle: “this shows my Ownership” adds nothing. Let the actions show it.
- One project for every question: it hides your range.
- Only successes: prepare at least two stories in which something went wrong and you say what you changed.
- A five-minute monologue: stop near two or three minutes and offer more detail.
A one-week practice plan
Day one: read the 16 principles on amazon.jobs and fill in the story matrix. Days two and three: write each story as bullet points with its numbers, not as a script. Days four and five: tell each story aloud to a timer, record it, and listen for “we”, missing results and long setups. Day six: have a friend or an AI assistant ask follow-up questions in random order. Day seven: retell only the two weakest stories.
Keep the facts of each story (dates, baselines, results, the trade-offs) on short review cards, so the numbers stay accurate while the delivery stays unscripted. A spaced-repetition app such as RecallDeck suits that kind of card; it does not replace saying the stories aloud. Prepare a “Why Amazon?” answer too, since the loop page calls it a common question, and keep up coding and system design practice, which the Amazon preparation plan covers.
Quick answers
Frequently asked questions
How many Amazon Leadership Principles are there?
Sixteen, as listed on amazon.jobs on November 14, 2026, from Customer Obsession to Success and Scale Bring Broad Responsibility. Check the official page before your interview in case the list changes.
Is there an official Amazon Leadership Principles PDF?
The principles themselves are published as a web page on amazon.jobs. Amazon's SDE II interview prep page also links a downloadable Leadership Principles worksheet for preparing stories. Prefer those two official pages to third-party PDFs, which may be out of date.
How many Leadership Principle questions will I get in an Amazon loop?
Amazon does not publish a total. Its SDE II prep page says the loop has four 55-minute interviews and that each interviewer typically asks two or three behavioral questions, which multiplies out to roughly 8 to 12. Other roles and levels differ, so ask your recruiter.
Do I need a separate story for every Leadership Principle?
No. A real story usually demonstrates several principles. Six to eight stories mapped in a matrix can cover all sixteen, as long as each principle has at least one story with clear evidence.
Which Amazon Leadership Principles matter most for software engineers?
Amazon does not publish a ranking. Its SDE II page says competencies based on the principles are assigned to different interviewers, and the About Amazon interview guide notes that job posts often hint at which principles matter most for a role. Prepare evidence for all sixteen and read the posting closely.
Source notes
References and review policy
Information checked on November 14, 2026. Section links identify sources for factual claims and technical explanations. Interpretations, practice scenarios and preparation recommendations are RecallDeck’s editorial work.
From reading to recall
Practice the full interview loop.
RecallDeck schedules the concepts you miss and keeps coding, design, and behavioral fundamentals available when the interviewer changes direction.