Amazon interviews are hard. I know this having coached engineers through dozens of them, and having talked to people who’ve sat on both sides of the loop at SDE II through Principal level. The thing that trips most candidates isn’t coding. It’s the behavioral side, and specifically the part where they know Amazon has Leadership Principles but haven’t actually thought through what Amazon is testing for with each one.
This post is the prep guide I wish existed when I was helping a friend through an L5 SDE loop at Amazon’s Seattle HQ in 2023. He made it to the Bar Raiser round and got dinged on “Ownership.” He knew the principle. He just didn’t have a story that demonstrated it at the right scope.
The loop structure first, because it changes how you prepare
A typical Amazon engineering loop is 4 to 5 rounds, each 45-60 minutes. Before the loop, there’s usually a recruiter screen and a technical phone screen or online assessment. The loop itself includes coding rounds, a system design round (for L5 and above), and at least one round dedicated to behavioral questions. One interviewer in the loop is the Bar Raiser, an interviewer from outside your hiring team who has veto power over the hire.
The Bar Raiser is not an adversary. They’re meant to protect hiring quality by removing the in-team bias that naturally accumulates when a team badly needs headcount. But their questions tend to go deeper, and they’re more likely to probe inconsistencies in your stories. If your Loop Day is four hours of conversation and you’re mentally tired by round four, the Bar Raiser round is not the time to get sloppy.
Each interviewer is assigned specific Leadership Principles to evaluate. This means the same principle may come up in multiple rounds, but from different angles. Customer Obsession might be probed in round two with a product tradeoff question, and again in round four with a “tell me about a time a customer was unhappy” prompt. You need stories that hold up across multiple framings, not a single rehearsed answer.
Which principles actually get tested the most
Amazon publishes all 16, but based on the loops I’ve seen and the postmortems I’ve read on Blind and various engineering blogs, six show up with high frequency across nearly every role:
- Customer Obsession – shows up in product, technical, and behavioral rounds
- Ownership – one of the most frequently cited reasons for rejection when it goes wrong
- Dive Deep – almost certain in system design and technical rounds
- Bias for Action – tested through speed-vs-correctness tradeoff scenarios
- Deliver Results – straightforward but requires quantified outcomes
- Earn Trust – comes up when interviewers probe for how you handle conflict or pushback
The remaining 10 principles can and do appear, but if you’ve built strong stories for the six above, you’ve covered the highest-probability material. I’d rather a candidate have three rock-solid Ownership stories than a shallow story for each of the 16.
The STAR format, and where candidates use it wrong
Amazon’s interviewers are trained to listen for STAR: Situation, Task, Action, Result. This is widely known and widely misapplied. The most common failure modes:
Too much Situation. Candidates spend three minutes setting context and run out of time before they get to what they actually did. Amazon cares about your action, not the background. Keep Situation to 30-45 seconds maximum.
Vague Actions. “I worked with the team to resolve the issue” is useless. “I wrote the incident postmortem, identified the root cause as a race condition in our queue consumer, and personally implemented the fix over the next 36 hours” is a story. Specificity is how you demonstrate competence, not just good values.
Missing numbers in Results. “The system improved significantly” doesn’t land. “Latency dropped from 340ms to 87ms at p99, and the on-call load dropped by 60% in the following quarter” lands. If you genuinely can’t remember exact numbers, give a range and acknowledge the approximation. That’s more credible than a made-up round number.
Building a story bank that actually holds up
The prep approach that works: identify 8 to 10 real career stories from the last 3-5 years. For each story, write down the core facts: what happened, what you specifically did, what the measurable outcome was. Then map each story to the Leadership Principles it can demonstrate. A good story usually covers 2-4 principles. A weak story covers only one, or covers one well and stretches badly to cover a second.
Test your stories with a practice partner before the loop. Not to memorize them word-for-word, but to hear yourself say them out loud. Most people discover in the first practice run that their “great story” takes 8 minutes to tell. That’s a problem. Amazon interviewers will cut you off, and getting cut off mid-story rarely leaves a good impression.
Craqly’s mock interview feature includes Amazon-specific behavioral simulations where the AI probes follow-up questions the way a Bar Raiser would. Several candidates I’ve spoken with found the follow-up probing more valuable than the initial question practice, because that’s where the weak spots in a story surface.
Two things people get wrong about Ownership
Ownership is the principle that trips up the most mid-senior candidates. Here’s why: people tell stories about owning their own work, which is expected but not interesting. Ownership at Amazon means acting beyond your formal scope when something is going wrong, even when it’s not your responsibility.
The story Amazon wants to hear is one where you saw a problem that technically belonged to another team, made a judgment call that waiting would cause harm, and took action without being asked. This is different from “I took initiative on my assigned project.” It requires a story where you chose to be accountable for something you could plausibly have ignored.
If you don’t have a story like that, think harder. Most engineers at L4 and above have encountered a cross-team incident, a customer escalation outside their scope, or a deployment decision that needed someone to step up. Find the one where you stepped up.
A realistic note on rejection
Amazon’s loop produces a lot of “strong no hire” decisions from people who were genuinely competent. The process optimizes for finding candidates who fit a specific kind of accountability culture, and a lot of great engineers don’t fit it or don’t want to. If you go through a loop and don’t get an offer, it’s worth reading the feedback carefully before assuming the stories were just told wrong. Sometimes the honest answer is that the culture genuinely isn’t a fit, which is useful information even if it stings.
The best prep I’ve seen? Candidates who’ve interviewed at Google or Meta and then prepped specifically for Amazon’s behavioral lens. They usually have the technical chops. They just need to translate their experience into Amazon’s language.