Amazon Leadership Principles Interview

Scope — How Amazon uses its sixteen Leadership Principles in an interview loop: what each principle probes, the classic questions for it, the STAR answer the interviewer is trained to expect, and how the Bar Raiser and the debrief read your stories. See also: googleyness.md — the Google behavioral round, which scores many of the same stories against a different rubric; mock_question_bank.md — twenty-five classic questions with sample answers, for mock practice.

1. How the Loop Uses the Principles

Amazon’s own interview guidance recommends the STAR format, and interviewers are trained to pull a story into that shape with follow-up questions if you do not.

Key point — The LPs are not a culture quiz. Each one is a lens for reading a past decision, and the interviewer is collecting data points: specific actions you took that show, or fail to show, the principle.

2. The Sixteen Principles at a Glance

The last two were added in 2021 and come up mostly for people managers and senior roles. For an entry-level SDE loop, the first fourteen carry nearly all the questions, and Customer Obsession, Ownership, Dive Deep, Deliver Results, Bias for Action, Earn Trust and Have Backbone come up most often.

3. The Answer Pattern

STAR, weighted toward Action and Result

• Lead with the headline if the story is long: “I cut our build time from 20 minutes to 6 — here is how.”
• Numbers are the currency of an Amazon result: latency, error rate, hours saved, users affected, days early. If you do not have an exact figure, give an honest estimate and say it is one.
• “I”, not “we”. The interviewer will ask “what did you do?” until they find out; save them the question.
• One story per question, told for two or three minutes, then stop and let them probe.

The follow-ups to prepare for

Interviewers are trained to dig two or three layers into a story. Prepare these for every story in your bank:

• What exactly did you do, and what did others do?
• What data did you look at? How did you know it worked?
• What alternatives did you consider, and why did you reject them?
• What would you do differently now?
• What did your manager or the other person think?
• What was the hardest part?

4. The Interviewer’s Perspective

• They take notes close to verbatim and later tag each note with the LP it supports. The debrief reads the notes, so a vague answer produces a vague note and no data point.
• They are assigned LPs, so a question about “a time you disagreed” may be scoring Have Backbone or Earn Trust depending on who asks. Answer the question asked, and the LP follows.
• They read every other interviewer’s notes in the debrief. Telling the same story to three interviewers looks like a candidate with one story. Use a different story in each round.
• They ask for another example when the first one does not show the principle. That is not a failure, but it costs time you cannot get back.
• A hypothetical answer scores weakly. “I would…” to a “tell me about a time” question gives them nothing to write down. If you truly have no example, say so, then give the closest real one.
• The Bar Raiser asks whether you raise the bar: would you be better than half the people already in the role? Strong, specific, recent stories are how that question gets answered yes.

What the notes usually show:

5. Classic Questions by Principle

Customer Obsession

• Tell me about a time you went above and beyond for a customer.
• Tell me about a time you had to balance a customer’s request against what you thought was right for them.

What they want to know — who your customer was (for an engineer it may be another team, or the user of your API), how you found out what they needed, and whether you changed course for them.

Strong signal — you gathered evidence of the need (a ticket, a metric, a conversation) and the result is stated in the customer’s terms.

Ownership

• Tell me about a time you took on something outside your responsibilities.
• Tell me about a time you saw a problem nobody owned and fixed it.

What they want to know — whether you act like an owner when nobody is watching, including the boring follow-through after launch.

Strong signal — you noticed it, took it on without being asked, and made sure it stayed fixed.

Invent and Simplify

• Tell me about a time you found a simpler way to do something.
• Tell me about the most innovative thing you have built.

What they want to know — whether you remove complexity rather than add it, and whether the new way was adopted.

Are Right, A Lot

• Tell me about a decision you made with incomplete information.
• Tell me about a time you were wrong.

What they want to know — how you form judgment, whether you look for people who disagree, and how you update when you are wrong.

Learn and Be Curious

• Tell me about something you taught yourself recently.
• Tell me about a time curiosity led you to a better solution.

What they want to know — whether you learn because the work needs it and because you want to, and whether it changed what you built.

Hire and Develop the Best

• Tell me about a time you helped a teammate improve.
• Tell me about a time you gave someone difficult feedback.

What they want to know — at entry level: mentoring an intern or a classmate, onboarding someone, or writing the doc that helped the next person.

Insist on the Highest Standards

• Tell me about a time you were not satisfied with the status quo.
• Tell me about a time you refused to compromise on quality.

What they want to know — whether you hold a bar when it is inconvenient, and whether you fix the cause, not only the symptom.

Think Big

• Tell me about a time you proposed a bigger idea than the task required.
• Tell me about a long-term vision you set for a project.

What they want to know — whether you can see past the immediate ticket and bring others along with the bigger picture.

Bias for Action

• Tell me about a time you made a decision quickly without all the data.
• Tell me about a time you took a calculated risk.

What they want to know — whether you can tell a reversible decision from an irreversible one, and move fast on the first.

Strong signal — you name why the decision was reversible and what you did to limit the downside.

Frugality

• Tell me about a time you accomplished something with limited resources.
• Tell me about a time you saved time or money for the team.

What they want to know — whether constraints make you inventive rather than stuck.

Earn Trust

• Tell me about a time you made a mistake and how you handled it.
• Tell me about a time you received critical feedback.

What they want to know — whether you admit mistakes quickly and openly, and treat others with respect when it is hard.

Strong signal — you raised the mistake yourself, before anyone found it, and fixed the process that allowed it.

Dive Deep

• Tell me about a time you used data to find the root cause of a problem.
• Tell me about the hardest bug you have debugged.

What they want to know — whether you go below the surface metric, and whether you can explain the details when probed.

Strong signal — the interviewer can ask three "why"s and you still have specifics.

Have Backbone; Disagree and Commit

• Tell me about a time you disagreed with your manager or team.
• Tell me about a time you committed to a decision you disagreed with.

What they want to know — whether you speak up with evidence, and whether you commit fully once the decision is made.

Strong signal — you disagreed respectfully, with data, and after the decision went against you, you made it succeed.

Deliver Results

• Tell me about a time you delivered a project under a tight deadline.
• Tell me about a goal you did not meet.

What they want to know — whether you focus on what matters most, get past setbacks, and deliver the result rather than the activity.

Strong signal — the obstacle is real, the trade-off you made is explicit, and the outcome has a number.

Strive to be Earth’s Best Employer

• Tell me about a time you made your team a better place to work.

What they want to know — whether you look after the people around you: inclusion, workload, growth.

Success and Scale Bring Broad Responsibility

• Tell me about a time you considered the wider impact of a decision.

What they want to know — whether you think about effects beyond your project: users, other teams, the community.

6. A Worked Example

Question — “Tell me about a time you used data to find the root cause of a problem.” (Dive Deep)

Situation — During my internship, our team’s nightly data export started failing about one night in five, and the on-call engineer was re-running it by hand.

Task — I was asked to make the job reliable before the end of my internship, six weeks out.

Action — The failures all logged a timeout, so the obvious fix was a longer timeout. Instead, I pulled thirty days of job logs into a spreadsheet and lined them up against the database’s load metrics. Every failure overlapped a weekly reindex job that someone had moved to the same hour. I confirmed it by running the export by hand during a reindex, which reproduced the timeout. I proposed moving the export an hour later instead of raising the timeout, wrote up the evidence for my manager and the reindex job’s owner, and added an alert on export duration so a new overlap would show up before it failed.

Result — The export ran for the remaining five weeks without a failure, which saved the on-call engineer about two hours a week. I learned to treat an obvious fix as a hypothesis and check the data before applying it.

Why it scores: the candidate did not stop at the symptom, the actions are specific and their own, the evidence is shown, the result has numbers, and a guard keeps it fixed (also a data point for Ownership and Insist on the Highest Standards).

7. Building a Story Bank

Eight to ten stories cover the loop, because each good story shows two or three principles. Map them before the interview so you never reuse a story across rounds.

Your Google stories transfer: a Googleyness “disagreement” story is an Amazon Have Backbone story, and a “failure” story is an Earn Trust story. Amazon’s probes go deeper into numbers and your individual actions, so add the metrics before you reuse one.

8. Checklist Before the Loop

• Eight to ten stories, mapped to principles, with no story planned for two rounds.
• Every result has a number; every story has a “what I would do differently”.
• At least one failure, one disagreement, one customer story and one deep-dive story.
• The follow-ups in section 3 rehearsed for each story.
• Stories told in the first person, in two to three minutes each.
• Two questions for the interviewer about how their team works.