Quick Answer
Amazon's behavioral interviews test all 16 Leadership Principles using the STAR method: Situation, Task, Action, Result. Each question asks for a specific past example. You need roughly 8–10 prepared stories that each cover 2–3 principles. The most commonly tested are Customer Obsession, Ownership, Deliver Results, Dive Deep, and Have Backbone; Disagree and Commit. Answers should run 2–3 minutes and end with a measurable outcome.
What are Amazon's 16 Leadership Principles?
Amazon's 16 Leadership Principles are the publicly documented values that guide how every Amazon employee — from intern to VP — is expected to make decisions, hire, and work. They are not abstract company values on a poster; Amazon uses them as the literal scoring rubric in every behavioral interview round.
What is a Leadership Principle (LP)?
A Leadership Principle is one of Amazon's 16 named behavioral standards, each with an official one-paragraph description on Amazon's website, against which interviewers score every candidate's answers.
The list grew from 14 to 16 in 2021 when Amazon added 'Strive to be Earth's Best Employer' and 'Success and Scale Bring Broad Responsibility.' The full current list, in Amazon's official order, is below. Before your interview, read each one on Amazon's own site — the exact wording matters because interviewers use it.
All 16 Amazon Leadership Principles (official order)
- Customer Obsession — start with the customer, work backwards; earn and keep customer trust
- Ownership — act like an owner, not just an employee; never say 'that's not my job'
- Invent and Simplify — seek innovation, eliminate complexity; 'not invented here' is not an excuse
- Are Right, A Lot — exercise strong judgment and good instincts; seek diverse perspectives
- Learn and Be Curious — never stop learning; be curious about new possibilities
- Hire and Develop the Best — raise the performance bar with every hire; develop leaders
- Insist on the Highest Standards — set relentlessly high standards; fix problems permanently
- Think Big — create and communicate a bold vision; think differently
- Bias for Action — speed matters; many decisions are reversible — act, then adjust
- Frugality — accomplish more with less; constraints breed resourcefulness
- Earn Trust — listen attentively, speak candidly, treat others respectfully
- Dive Deep — stay connected to the details; data and anecdote both matter
- Have Backbone; Disagree and Commit — challenge decisions respectfully; then commit fully once decided
- Deliver Results — focus on the right inputs; deliver with the right quality, on time
- Strive to be Earth's Best Employer — lead with empathy; create a safe, productive, diverse environment
- Success and Scale Bring Broad Responsibility — act with humility; the world is watching
Interview tip
Read the official descriptions at aboutamazon.co.uk/who-we-are/leadership-principles before your interview — not a summary. The exact language Amazon uses (e.g. 'work vigorously', 'never say it's not my job', 'obligated to respectfully challenge') tells you precisely what behavior they are looking for.
For a solid foundation in structuring stories around your career timeline — which LPs like Ownership and Deliver Results require — Mockly's guide on the STAR interview framework walks through the method in detail, with worked examples you can adapt.
How does Amazon use the LPs in interviews?
Every Amazon behavioral interview is explicitly mapped to specific LPs — interviewers are assigned which principles to probe, and they score your answers against those principles on a structured rubric. This is not a casual culture-fit conversation; it is a scored assessment.
What the interview structure typically looks like
- Each interviewer is assigned 2–3 LPs to cover — they will ask questions specifically designed to surface evidence for those principles.
- A typical loop has 4–6 interviewers, so across the loop you will be assessed on most or all of the 16 LPs.
- One interviewer often acts as the 'Bar Raiser' — an independent evaluator whose job is to maintain the hiring bar, not to advocate for you.
- Interviewers write detailed notes on your answers immediately after the interview and compare them in a debrief — vague answers are scored lower than specific ones.
- The question format is almost always 'Tell me about a time when…' or 'Give me an example of…' — not hypothetical ('What would you do if…').
Key takeaway
Amazon interviewers are not listening for whether you know what the LPs are. They are listening for whether your past behavior demonstrates them. The story is the evidence.
| What they ask | What they are really testing |
|---|---|
| Tell me about a time you disagreed with your manager. | Have Backbone; Disagree and Commit — did you push back respectfully AND then commit? |
| Describe a project where you had to make a decision with incomplete data. | Bias for Action + Are Right, A Lot — did you act decisively and explain your reasoning? |
| Tell me about a time you caught a mistake others missed. | Dive Deep + Insist on the Highest Standards — do you stay close to the details? |
| Give me an example of a goal you set that no one thought was achievable. | Think Big + Deliver Results — did you aim high and actually deliver? |
| Tell me about a time you improved a process to save cost. | Frugality + Ownership — did you take initiative without being asked? |
Every LP question has a specific behavioral signal the interviewer is hunting for. Know the signal, not just the principle name.
How to structure a STAR answer for Amazon
The STAR method — Situation, Task, Action, Result — is the expected answer format for every Amazon behavioral question. Amazon interviewers are trained to probe each part, so a weak Situation or a missing Result will generate follow-up questions that put you on the back foot.
What is the STAR method?
STAR stands for Situation (the context), Task (your specific responsibility), Action (what you personally did), and Result (the measurable outcome) — a four-part structure for answering behavioral interview questions with a real past example.
| Part | What to cover | Target length | Common mistake |
|---|---|---|---|
| Situation | Set the scene: team size, company stage, what was at stake. One or two sentences. | 15–20 seconds | Too long — candidates spend 90 seconds on context the interviewer doesn't need. |
| Task | Your specific role or responsibility in this situation. Not the team's job — yours. | 10–15 seconds | Saying 'we' instead of 'I' — the interviewer is scoring you, not your team. |
| Action | What you personally decided and did, step by step. This is the longest part. | 60–90 seconds | Staying too abstract — 'I improved communication' tells the interviewer nothing. |
| Result | The outcome, ideally with a number. What changed because of what you did? | 20–30 seconds | Omitting the result, or giving a vague one like 'the project went well.' |
A complete STAR answer runs 2–3 minutes. Action should take roughly half the total time.
Watch Out
Amazon interviewers specifically probe the Action step with follow-ups like 'Why did you choose that approach?' and 'What else did you consider?' If your Action is vague, you will be asked to go deeper — and if you cannot, the interviewer concludes the story is embellished. Prepare two layers of detail for every Action.
Useful English phrases for each STAR part
- SITUATION: 'At the time, I was a senior engineer on a team of eight, responsible for our payment service. We were facing a situation where…'
- SITUATION: 'This was about two years ago, when our team had just taken on ownership of a legacy system that…'
- TASK: 'My specific responsibility was to… / I was the one accountable for…'
- TASK: 'No one had formally asked me to do this, but I could see that…' (strong for Ownership)
- ACTION: 'The first thing I did was… Then I… After that, I decided to… because…'
- ACTION: 'I pushed back on this approach because… I said to my manager: [direct quote is powerful here]'
- ACTION: 'Rather than waiting for approval, I… / Instead of escalating immediately, I first tried to…'
- RESULT: 'As a result, we reduced latency from 800ms to 120ms — a 85% improvement.'
- RESULT: 'The team shipped two weeks ahead of schedule, and the feature had a 94% satisfaction score in the first customer survey.'
- RESULT (when outcome was partial): 'We didn't hit the original target, but we recovered X, and the process change we put in place prevented the same issue from recurring.'
Interview tip
When you give a number in your Result, say it clearly and slowly. Non-native speakers often rush numbers under pressure. 'Eighty-five percent' is more credible than a mumbled '85%.' Mockly's guide on pronouncing numbers and metrics covers exactly this — it matters more than most candidates realise.
The 5 most commonly tested LPs and what to say
All 16 LPs are testable, but five appear in almost every loop regardless of role or level — Customer Obsession, Ownership, Deliver Results, Dive Deep, and Have Backbone; Disagree and Commit. Prepare at least one strong story for each of these before anything else.
1. Customer Obsession — what the interviewer is listening for
- Evidence that you started with the customer's actual need, not your own assumptions or technical preferences.
- A moment where you chose the harder path because it was better for the customer.
- Typical question: 'Tell me about a time you went above and beyond for a customer.'
- Strong opening phrase: 'The customer in this case was [internal team / end user / external client], and what they actually needed was different from what they had asked for…'
2. Ownership — what the interviewer is listening for
- Evidence that you acted beyond your formal job description, without being asked.
- A moment where you took responsibility for a problem that was not technically yours.
- Typical question: 'Tell me about a time you took on something outside your area of responsibility.'
- Strong opening phrase: 'This wasn't formally my problem to solve, but I could see that if no one addressed it, the consequence would be…'
3. Deliver Results — what the interviewer is listening for
- Evidence of a specific, measurable outcome you drove to completion despite obstacles.
- A moment where you adapted the approach without dropping the goal.
- Typical question: 'Tell me about a time you had to deliver a project under significant constraints.'
- Strong opening phrase: 'The deadline was fixed, the team was smaller than planned, and two weeks in we discovered that…'
4. Dive Deep — what the interviewer is listening for
- Evidence that you personally got into the details, rather than relying only on reports or summaries.
- A moment where your hands-on investigation revealed something others had missed.
- Typical question: 'Tell me about a time you used data to challenge an assumption.'
- Strong opening phrase: 'The metrics looked fine at the aggregate level, but when I pulled the raw logs myself, I found that…'
5. Have Backbone; Disagree and Commit — what the interviewer is listening for
- Evidence of both parts: you challenged a decision AND you fully committed once the decision was made.
- The most misunderstood LP — candidates often show only the 'disagree' half and forget to show the 'commit' half.
- Typical question: 'Tell me about a time you disagreed with a decision made by your team or manager.'
- Strong structure: 'I disagreed because [specific reason]. I raised it by saying [what you actually said]. The team decided to go ahead anyway. After that, I [how you committed and made it work].'
Insight
The non-obvious insight on 'Have Backbone; Disagree and Commit': Amazon explicitly wants to see both halves in the same story. Candidates who only show the disagreement come across as difficult. Candidates who only show the commitment come across as passive. The interviewer is looking for the pivot — the moment you stopped arguing and started executing. Name that moment explicitly in your answer.
Full STAR answer: software engineer (Ownership)
This is a complete, speakable answer to 'Tell me about a time you took ownership of a problem outside your area of responsibility.' Read it aloud once — the pacing and transitions are part of what makes it work.
Weak version (what most candidates say)
We had a problem with our deployment pipeline and it was causing delays. I helped the DevOps team fix it. We improved the deployment time significantly and the team was happy.
Strong version (STAR with specific detail)
SITUATION: 'About 18 months ago, I was a senior backend engineer on our checkout team. Our deployment pipeline had been failing intermittently for about three weeks — roughly one in five deploys would fail silently, meaning code appeared to ship but didn't actually reach production.' TASK: 'This was officially the DevOps team's responsibility, not mine. But our team had a feature launch in ten days, and the DevOps team was already at capacity with a migration.' ACTION: 'I decided to investigate myself. I pulled the build logs for the last 30 failed deploys and spotted a pattern: the failures all happened when a specific microservice was deployed after 6pm, which pointed to a resource contention issue during peak traffic. I wrote up my findings in a one-page document, shared it with the DevOps lead, and proposed a specific fix — shifting the deployment window and adding a health check before marking a deploy as successful. I didn't wait for a formal ticket; I opened a draft PR with the health check change and offered to pair with their engineer to implement it.' RESULT: 'The fix went in within two days. In the following four weeks, we had zero silent failures. Our feature launched on time. The DevOps team adopted the health check pattern across three other services.'
Interview tip
Notice what the strong version does that the weak version does not: it names the exact problem (silent failures, one in five deploys), explains why it was outside the candidate's formal responsibility, shows a specific investigative action (pulling 30 logs, spotting a pattern), and gives a precise result (zero failures in four weeks, adopted across three services). Every one of those details is a point on the interviewer's scorecard.
Full STAR answer: product manager (Customer Obsession)
This is a complete, speakable answer to 'Tell me about a time you went above and beyond to understand a customer's needs.' It is written for a PM role but the structure works for any role that touches users or stakeholders.
Weak version
I always try to listen to customers. Once I ran some user interviews and changed our roadmap based on what they said. The product improved and customers were more satisfied.
Strong version (STAR with specific detail)
SITUATION: 'Two years ago I was a PM for a B2B analytics product. Our quarterly NPS had dropped from 42 to 28 over two quarters, but our support ticket volume was flat — so the data wasn't telling us why users were unhappy.' TASK: 'I needed to find the root cause before our next roadmap planning cycle, which was six weeks away. The engineering team was already asking for priorities, and I didn't want to guess.' ACTION: 'Rather than running a standard survey, I personally contacted 15 of our churned accounts — not through our success team, but directly, from my own email. I asked for 20 minutes and offered to share our roadmap in exchange for honest feedback. Twelve agreed to talk. What I heard was consistent: users weren't confused by the product — they were frustrated that our export function didn't support their internal reporting format. It was a one-line feature request that had been sitting in our backlog for eight months, deprioritised because it had low vote counts. I re-evaluated it against actual churn impact, moved it to the top of the next sprint, and personally wrote the acceptance criteria with two of the customers who had described the problem most clearly.' RESULT: 'The export feature shipped in three weeks. Within 60 days, two of the churned accounts reactivated. Our NPS recovered to 38 in the following quarter. More importantly, the process of going directly to churned users became a standard practice on my team.'
Key takeaway
The phrase 'I personally contacted' is doing important work in this answer — it signals Customer Obsession, not just customer awareness. Amazon's official description of this LP says leaders 'work vigorously to earn and keep customer trust.' 'Vigorously' is the word to demonstrate.
English mistakes that cost non-native speakers LP points
These are not grammar errors — Amazon does not care about perfect grammar. These are communication patterns that make your answers sound weaker than your actual experience, and that interviewers specifically notice when scoring LP evidence.
| What you say | What the interviewer hears | What to say instead |
|---|---|---|
| 'We decided to…' / 'Our team did…' | 'I can't tell what this person actually did.' | 'I decided to… / My specific contribution was… / I was the one who…' |
| 'I think I improved the performance.' | 'They're not sure of their own result — was it real?' | 'I reduced the p99 latency from 1.2 seconds to 340 milliseconds, measured over a two-week window.' |
| 'It was a very complicated situation.' | 'Vague. No evidence of Dive Deep.' | 'The complexity came from three specific things: [name them].' |
| 'I tried to communicate better with the team.' | 'No action — what did you actually do?' | 'I set up a weekly 15-minute sync and shared a written summary after every design decision. Within a month, escalations dropped by half.' |
| 'At the end, everything was fine.' | 'No result. Nothing to score.' | 'The outcome was [specific metric], which meant [business impact].' |
| 'I always try to think about the customer.' | 'That's a habit, not a story. Amazon needs a specific example.' | 'In this particular case, I chose to… because the customer needed… even though it meant…' |
Every vague phrase is a missed scoring opportunity. Replace habits ('I always try to') with specific instances ('In this case, I chose to').
Watch Out
The word 'we' is the single most common LP-scoring mistake non-native speakers make. In many engineering cultures, using 'I' feels immodest or even rude. At Amazon, using 'we' when you mean 'I' makes it impossible for the interviewer to score your individual contribution. You are not being arrogant — you are giving the interviewer the evidence they need.
Phrases that sound modest but hurt your score
- 'It was a team effort.' → Fine to say once, but follow it with: 'My specific role was…'
- 'I was just a junior engineer at the time.' → Remove 'just.' Your level doesn't reduce the evidence.
- 'I'm not sure if this is a good example, but…' → Never apologise for your story before you tell it. Start with the situation.
- 'I don't remember the exact numbers.' → If you genuinely don't, give a range: 'roughly 30 to 40 percent.' Vague is worse than approximate.