Amazon added its 16th Leadership Principle, “Strive to be Earth’s Best Employer,” in 2021. Most candidates still prep for 14. I’ve seen this exact gap cause a confused pause in a Bar Raiser round when someone was asked about a specific commitment to employee wellbeing. Not a dealbreaker, but an avoidable stumble.
The current list has 16. Read all 16 before your loop.
Why the principles work the way they do
Amazon’s interview framework is not a personality test. It’s a calibration system. Each interviewer in your loop is assigned a subset of principles before the day starts. Their job is to gather evidence for or against your ability to operate the way Amazon operates. The criteria were codified specifically because Amazon scaled too fast to rely on “cultural fit” as a vibes-based judgment call. They needed something interviewers could be trained on and that generated consistent decisions across thousands of loops per year.
This is worth understanding because it changes how you think about preparation. You’re not trying to seem like a good person. You’re trying to demonstrate, through specific past behaviors, that you make decisions the way Amazon makes decisions. The principles are a behavioral model. Your stories are evidence.
The six principles that carry the most weight in engineering loops
I’m going to focus on engineering roles because that’s where most of the detailed post-loop feedback I’ve read comes from. If you’re interviewing for product, marketing, or ops, the distribution shifts somewhat, but Customer Obsession and Ownership remain constants.
For engineering:
- Dive Deep is tested in technical rounds through system design questions where shallow answers are insufficient. “Use a load balancer” is not a Dive Deep answer. Explaining how you’d tune connection pool sizes based on observed query latency distributions is.
- Ownership is where most mid-senior engineers get dinged. The stories that work are cross-scope: you saw a problem that wasn’t technically yours, and you acted on it anyway.
- Bias for Action gets probed through questions about how you make decisions with incomplete information. The answer Amazon wants isn’t “I always gather all the data first.”
- Deliver Results requires numbers. Ranges with honest caveats beat made-up round numbers every time.
- Customer Obsession in engineering contexts usually surfaces through product tradeoff questions. “Which technical choice better serves the end user?” is the underlying question in many coding and system design conversations.
- Earn Trust gets probed through conflict stories. How did you handle a peer who disagreed with your technical decision? What did you do when your manager was wrong?
The story bank method, explained without ceremony
Write down 8-10 real stories from your last 3-5 years. Actual events, not composites. For each one: what was the situation in one sentence, what specifically did you do (not “we”), what was the measurable outcome. Then tag each story with the principles it demonstrates.
A good story covers 2-4 principles. If a story only covers one, and it’s a minor one, it’s probably not worth keeping in the bank. If a story covers four and you can tell it in under 4 minutes, that’s a high-value story.
Practice telling each story out loud to someone who will interrupt you with follow-ups. Not to test your memory of the story but to test whether the story survives scrutiny. A Bar Raiser will ask “what would you have done differently?” and “why didn’t you escalate earlier?” Your answer to those questions matters as much as the story itself.
Craqly’s mock interview product has Amazon LP-specific question sets that include follow-up probing after your initial answer. I think the follow-up probing is underrated in most prep tools. Most candidates can deliver a polished first answer. Fewer can handle “so what specifically would you do differently?” without losing the thread of the story.
How to handle the “tell me about a failure” questions
These are not traps. Amazon actually does expect candidates to have failed at things. The failure questions test self-awareness and the Learn and Be Curious principle more than they test for competence. A candidate who claims they can’t think of a significant failure is a red flag, not a positive signal.
The failure story formula that works: specific event, your specific role in causing or failing to prevent it, what you learned, what you did differently afterward. The “what you did differently” part is what turns a failure story into a positive signal. If you learned something real and changed your behavior, that’s evidence of the kind of self-correction Amazon values.
Don’t make the failure too small (“I once missed a deadline by a day”) and don’t make it so large that it sounds like you caused a production outage that affected millions of customers without consequences. Somewhere in between is the right calibration.
One honest caveat
I don’t have data on how LP preparation affects loop pass rates in a controlled way. The feedback that exists is anecdotal, drawn from Blind threads, candidate blog posts, and direct conversations. What I can say is that the pattern I see in successful candidates is consistent: they have specific stories, they tell them concisely, and they’ve practiced the follow-up questions enough that they don’t visibly stall when probed. Whether that’s causation or correlation with generally stronger candidates, I genuinely don’t know.
Amazon loops do have a real false-negative rate. Some good engineers don’t get offers. That’s not a flaw in your prep; sometimes the stories you have don’t map cleanly to the loop’s coverage, or the Bar Raiser’s judgment call goes against you on a close call. Go in prepared and then don’t catastrophize if it doesn’t work out the first time.