Lesson 1 of 4
Amazon's Leadership Principles
"Good intentions don't work. Mechanisms do." — a phrase you will hear repeated inside Amazon until it becomes a reflex
Most companies have values. They print them on a wall, mention them at orientation, and then run interviews that have almost nothing to do with them. Amazon is the exception that reshaped the whole industry. At Amazon the values are the interview. They are the promotion rubric. They are the language people use in meetings to disagree with a vice president. They are called the Leadership Principles, and if you interview for an engineering role there, every behavioral answer you give will be scored against them — explicitly, in writing, by people trained to find the seam in your story.
This is the flagship chapter of Part VI for a reason. No other behavioral framework in tech is as codified, as widely imitated, or as ruthlessly applied as Amazon's. Learn to answer well against the Leadership Principles and you have effectively trained for the hardest, most structured behavioral bar in the industry — which makes every other company's round feel gentler by comparison.
By the end of this chapter you'll know how the Amazon loop is wired, what each interviewer is actually assigned to extract, who the Bar Raiser is and why they can veto you, and how to build a story bank that maps cleanly onto the principles that matter most for engineers. You'll also see two fully worked model answers, tagged line by line with the principles they demonstrate.
When every interviewer in the loop is grading your stories against a fixed list of Leadership Principles — and one of them is empowered to say no all by themselves — how do you answer so that a specific principle lights up, backed by data, on the first pass?
How the Amazon loop is actually wired
At most companies the behavioral questions feel improvised — whatever the interviewer thought of on the way to the room. At Amazon they are engineered. Before your loop, the LPs are divided up among your interviewers. One person is assigned to dig into Ownership and Dive Deep. Another owns Customer Obsession and Deliver Results. Another gets Have Backbone, Disagree and Commit and Bias for Action. This is deliberate coverage: by the end of the day, the panel has probed a wide spread of principles, and no single principle rests on one person's read.
Each interviewer arrives with prepared questions, and — this is the part candidates underestimate — they take near-verbatim notes while you talk. Amazon runs on the written word. Your interviewer isn't jotting a vibe; they're capturing quotes so the debrief can be an evidence review, not a popularity contest. That single fact changes how you should answer: specificity and data survive the write-up; adjectives and vibes evaporate.
Where this came from The Leadership Principles grew out of Amazon's early culture and were formalized as the company scaled past the point where Jeff Bezos could set the tone in every room. They started as a shorter list and have expanded over the years — the last two, about being Earth's best employer and about scale bringing responsibility, were added in 2021. The point was never a poster. The LPs are a mechanism: a shared, teachable language so that a hiring bar set in Seattle means the same thing in a team in Dublin or Hyderabad. When Amazonians say "that's not customer-obsessed," they are quoting a spec, not venting.
The Bar Raiser
Somewhere in your loop is an interviewer from outside the hiring team, specially trained and certified, called the Bar Raiser. Their job is not to fill the role — it's to protect the long-term hiring bar of the whole company. They are the guardian of the principles themselves. Crucially, the Bar Raiser has an effective veto: the hiring manager cannot simply overrule them to push a candidate through. If the Bar Raiser isn't convinced, you don't get the offer.
You usually can't tell which interviewer is the Bar Raiser. Assume every conversation is with someone who can end the process, and answer accordingly.
The follow-up machine
Amazon interviewers are trained to keep pulling on a thread until they hit either the person or the seam. The signature move is the drill-down: "and what did you do?" … "why that approach and not another?" … "how did you know it worked — what was the number?" … "what would you do differently?" A rehearsed paragraph gets you through the first sentence. The next four questions are where the interview actually happens.
This is why "we" is fatal at Amazon specifically. When the whole loop is looking for your judgment and your action, a story told entirely in the collective voice reads as a story you may have merely stood near.
The 16 Leadership Principles
Here is the full set, each with its plain meaning and the kind of story that demonstrates it well.
| Leadership Principle | What it really means | The story that shows it |
|---|---|---|
| Customer Obsession | Start from the customer and work backward; earn trust, don't just chase competitors. | A time you pushed back on an internally convenient choice because it hurt users. |
| Ownership | Act on behalf of the whole company, not your team; never say "not my job"; think long-term. | You fixed or owned something outside your lane because the outcome mattered. |
| Invent and Simplify | Find new solutions and remove complexity; not invented here is no excuse. | You replaced a tangled process/system with something dramatically simpler. |
| Are Right, A Lot | Strong judgment; seek diverse views and disconfirm your own beliefs. | You made a hard call with incomplete data — and were right, and can say why. |
| Learn and Be Curious | Always improving; curious about new possibilities. | You taught yourself something outside your comfort zone to solve a problem. |
| Hire and Develop the Best | Raise the bar with every hire; coach and grow others. | You mentored someone into a real level-up, or improved how your team hires. |
| Insist on the Highest Standards | Relentlessly high bar; many think it's unreasonably high. | You refused to ship something "good enough" and it mattered. |
| Think Big | Bold direction that inspires results; small thinking is self-fulfilling. | You proposed something bigger than the ticket in front of you. |
| Bias for Action | Speed matters; many decisions are reversible and don't need study. | You moved decisively under uncertainty instead of waiting for perfect data. |
| Frugality | Do more with less; constraints breed resourcefulness. | You delivered impact without headcount, budget, or new infrastructure. |
| Earn Trust | Listen, speak candidly, treat others respectfully; be self-critical. | You were candid about your own mistake and kept a relationship intact. |
| Dive Deep | Operate at all levels, audit frequently, distrust the anecdote over the data. | A debugging or root-cause story where you went deeper than anyone else would. |
| Have Backbone; Disagree and Commit | Challenge respectfully even when it's uncomfortable; then commit fully. | You disagreed with a senior decision, argued it, then either won or committed. |
| Deliver Results | Focus on the right inputs and deliver with quality, on time. | A shipped outcome with a hard deadline and a number attached. |
| Strive to be Earth's Best Employer | Create a safer, more productive, more empathetic work environment. | You made your team's day-to-day meaningfully better or healthier. |
| Success and Scale Bring Broad Responsibility | Act with the humility that your decisions affect the wider world. | You considered second-order impact — security, privacy, users at large. |
Sixteen is a lot to hold. The good news for engineers is that a handful carry most of the weight in a technical loop. Go deep on these.
The principles that decide engineering loops
Customer Obsession
This is the one Amazon treats as the origin of all the others, and interviewers test whether it's real for you or a slogan. It does not mean "the customer is always right" or "do whatever sales wants." It means you reason backward from the user's actual need, even when that's inconvenient internally. A strong story shows you had a choice between the easy path for your team and the right path for the customer — and you chose the customer, with evidence that it helped them.
Ownership
The most probed principle for engineers, and the most misunderstood. Ownership is not "I worked really hard." It's acting like the outcome is yours even when the task isn't assigned to you, and thinking past the quick fix to the durable one. The tell of a strong Ownership story is that you stepped toward something you could have justifiably ignored — a broken thing in someone else's code, a gap no one had claimed — and you carried it to a real resolution.
Dive Deep
Amazon distrusts hand-waving. Dive Deep is the antidote: the willingness to go down into the logs, the metrics, the raw data, past the comfortable summary. For engineers this is the debugging principle — the incident where everyone accepted the surface explanation and you didn't. Strong stories name the exact evidence you dug into and the moment the real cause surfaced.
Bias for Action
Speed is a value at Amazon, tempered by a specific insight: most decisions are reversible (they call these "two-way doors"), so you shouldn't study them to death. A strong Bias for Action story shows you moved decisively with imperfect information, and — this is the mature part — that you knew why it was safe to move fast (reversible, low blast radius, easy to roll back).
Have Backbone; Disagree and Commit
Two halves, and weak candidates only tell the first. The backbone half: you respectfully challenged a decision you believed was wrong, even against someone senior, with reasoning and data. The commit half: once the decision was made — your way or not — you got fully behind it without sabotage or "I told you so." Interviewers love a story where you lost the argument and committed wholeheartedly anyway; it proves the principle is real and not just stubbornness.
Deliver Results
The principle that anchors almost every answer, because Amazon wants the number. It's not enough that you tried hard or that the project was interesting. What shipped? By when? What moved, and by how much? Every strong story in an Amazon loop lands on a quantified Result.
Invent and Simplify, and Earn Trust
Invent and Simplify rewards the engineer who deletes complexity, not just the one who adds features — the rewrite that halved the moving parts, the process you eliminated. Earn Trust is the connective tissue of the whole loop: candor about your own mistakes, treating disagreement with respect, being self-critical without being self-flagellating. Interviewers read low Earn Trust in candidates who blame teammates, hide failures, or can't name a single thing they'd do differently.
Analogy Think of the LPs as a set of colored filters and your career as a pile of photographs. A single strong experience — say, the on-call incident you owned end to end — looks different through each filter. Through the Ownership filter it's "I took it on when it wasn't mine." Through Dive Deep it's "I found the real cause in the logs." Through Deliver Results it's "outage down 90%." Same photo, three principles. You don't need sixteen stories. You need six or seven rich ones you can hold up to different light.
Mapping your story bank to the principles
Here is the practical move. Don't build one story per principle — you'll end up with sixteen thin, memorized-sounding anecdotes. Instead, build a small bank of deep, real stories and tag each with the two or three principles it demonstrates most strongly. One good incident story can legitimately cover Ownership, Dive Deep, and Deliver Results at once. One good disagreement can cover Have Backbone and Earn Trust.
| Your story | Primary LP | Also demonstrates |
|---|---|---|
| The production incident you owned end to end | Ownership | Dive Deep, Deliver Results |
| The rewrite/refactor you argued for and won | Invent and Simplify | Have Backbone, Insist on Highest Standards |
| The deadline you hit by cutting the right scope | Deliver Results | Bias for Action, Customer Obsession |
| The disagreement with a senior engineer | Have Backbone | Earn Trust, Are Right A Lot |
| The teammate you mentored into a real level-up | Hire and Develop the Best | Earn Trust |
| The convenient choice you rejected for users | Customer Obsession | Insist on Highest Standards |
Aim for six to eight stories that, between them, cover the heavy-hitters twice over. Then in the room, when the assigned interviewer opens their principle, you reach for the story tagged to it — and let the follow-ups pull the rest of the color out.
The two things Amazon demands more than anyone
A quantified Result. Amazon's culture runs on metrics, and the loop inherits that. "It got a lot faster" is a non-answer. "P99 latency dropped from 900ms to 180ms and support tickets fell 60% the next month" is an answer. If you don't know the exact number, give the honest best estimate and say how you'd measure it — that itself signals Dive Deep.
Heavy first-person Action. Because interviewers are assigned to extract your judgment, the Action section of your STAR story should be dense with "I" — I decided, I proposed, I built, I escalated — while still crediting the team for the parts that were theirs. The ratio matters. If a stranger read your transcript, they should be able to list five specific things you personally did.
Model answer 1 — "Tell me about a time you took ownership of a problem outside your responsibility." Tagged: Ownership (primary), Dive Deep, Deliver Results, Earn Trust.
Situation. "At my previous company, our checkout service started throwing intermittent 500s — about 2% of transactions — during evening peak. It was owned by a different team, and their on-call had marked it 'monitoring, no clear cause' for three days. I owned the payments integration one layer down, so it wasn't my page, but our error dashboards were catching the fallout and customers were abandoning carts."
Task. "It wasn't assigned to me, and I could have kept flagging it upstream. But the customer impact was real and no one was driving it to closure, so I decided to own getting to root cause."
Action. "I pulled the last week of request logs and correlated the 500s against deploy times and traffic — no match. So I went deeper: I traced individual failed requests through our distributed tracing and noticed every failure held a database connection for exactly 30 seconds before dying. That pointed at a connection-pool exhaustion, not a code bug. I dug into the pool config and found the checkout service had a max pool of 20 connections but was opening a new one per retry without releasing on timeout — so under peak load the pool starved. I wrote up the finding with the traces attached, took it to the owning team's lead, and — because it was their service — I proposed the fix rather than shipping it over their heads: release connections in a finally block and raise the pool ceiling. I paired with their on-call to deploy it behind a flag that evening and watched the dashboards with them."
Result. "The 500 rate went from 2% to under 0.05% that night. We recovered an estimated $40K a week in abandoned checkouts based on the conversion delta. The owning team adopted the connection-pool audit as a standing check in their runbook. And because I brought it to them instead of around them, their lead started looping me in early on cross-service issues after that."
Why it scores: Ownership is unmistakable (not my page, I drove it anyway). Dive Deep is concrete (traces, the 30-second tell, the exact misconfig). Deliver Results is quantified ($40K/week, 2% → 0.05%). Earn Trust is deliberate (proposed the fix, didn't ship over the team). Notice the "I" density — and that the credit for the deploy is shared honestly.
Model answer 2 — "Tell me about a time you disagreed with a decision and had to commit." Tagged: Have Backbone; Disagree and Commit (primary), Earn Trust, Deliver Results.
Situation. "My team was picking the storage layer for a new notifications service. Our principal engineer wanted to reuse the company's existing relational database because it was familiar and already operated. I believed the write pattern — millions of small, append-only, short-lived events — was a poor fit for a relational store and would cost us in operational pain."
Task. "I was the most junior person in that design review by several years. I could have deferred to seniority. But I thought the decision was wrong in a way that would be expensive to reverse, so I decided to make the case properly."
Action. "I didn't just voice an opinion — I built a small load test over a weekend simulating our projected write volume against both the relational option and a log-structured key-value store. I brought the numbers to the next review: the relational option's write latency degraded sharply past a few thousand writes per second and would have needed sharding within a year; the KV store held flat. I laid it out respectfully, acknowledged the operational familiarity argument was real, and asked the principal directly what would change his mind. He pushed back on the maintenance cost of a new datastore — a fair point I hadn't weighted enough. In the end, the group still chose the relational database for the first version, prioritizing time-to-market and operability over my projection."
Result. "I disagreed, and I lost. So I committed — fully. I owned building the schema and the indexing strategy to squeeze the most out of the relational option, and I added the write-rate monitoring that would tell us early if my prediction came true. About eight months later the write volume did cross the threshold, the monitoring I'd added flagged it before it became an incident, and we migrated to the KV store on our own timeline with zero customer impact. The principal referenced that as a model of 'disagree and commit' in my next review. The lesson I kept: backbone is bringing data, not volume — and committing after you lose is what makes people trust your backbone next time."
Why it scores: both halves are present — genuine, evidenced disagreement (a weekend load test, not just an opinion) and wholehearted commitment after losing. Earn Trust shows in conceding the point he'd underweighted and in committing without resentment. Deliver Results lands twice: the monitoring caught the issue early, and the eventual migration was clean.
Common Mistakes
- All "we," no "I." Fatal at Amazon specifically, because interviewers are assigned to extract your actions. Fix: audit your Action section — can a stranger list five things you did?
- No number in the Result. "It improved" tells the debrief nothing. Fix: attach a metric, even an honest estimate, and say how you'd verify it.
- Telling half of Disagree and Commit. Candidates narrate the fight and forget the commit — or worse, commit resentfully. Fix: explicitly show you got fully behind the decision, even one you lost.
- A rehearsed paragraph with nothing underneath. The follow-up machine exhausts memorized answers in two questions. Fix: pick real stories you can drill into five levels deep.
- Confusing Bias for Action with recklessness. Moving fast is only a virtue when you can articulate why it was safe. Fix: name the reversibility ("two-way door, easy rollback").
- Blaming another team or person. Reads as low Earn Trust and low Ownership at once. Fix: own your part first; describe others' contributions neutrally.
- Picking a low-stakes story. A trivial situation caps how high you can score no matter how well you tell it. Fix: choose stories with real ambiguity, real stakes, real consequences.
Self-audit Take your single best work story and grade it against three principles. For Ownership: was it actually yours, or were you handed it? For Dive Deep: can you name the exact piece of evidence that cracked it open? For Deliver Results: what is the number? If any of the three answers is fuzzy, that's not a delivery problem — it's a story-selection problem. Find a sharper story before you polish this one.
Hands-on Build your LP map. Take the six to eight strongest moments from your story bank and, for each, fill this line: [one-line story] → primary LP → two secondary LPs → the one metric. Then check coverage against the engineering heavy-hitters — Customer Obsession, Ownership, Dive Deep, Bias for Action, Have Backbone/Disagree and Commit, Deliver Results, Invent and Simplify, Earn Trust. Every one of those should be the primary or secondary tag on at least two of your stories. Any principle with zero coverage is a hole an assigned interviewer will find — go mine one more story to fill it. Finish by writing the Action section of your single best story entirely in the first person and counting the specific "I did X" actions. If it's fewer than five, rewrite until it isn't.
Summary
- At Amazon the values are the interview: 16 Leadership Principles, divided among your interviewers, with a certified Bar Raiser who guards the bar and can veto the hire.
- Interviewers take near-verbatim notes and grade your stories in writing, so specificity and data survive the debrief and vibes don't.
- A handful of principles decide engineering loops — Customer Obsession, Ownership, Dive Deep, Bias for Action, Have Backbone/Disagree and Commit, Deliver Results, Invent and Simplify, Earn Trust — and each has a distinct "story that shows it."
- Don't build sixteen thin anecdotes; build six to eight deep stories and tag each with the two or three LPs it demonstrates. One incident can cover Ownership, Dive Deep, and Deliver Results at once.
- Amazon demands two things harder than anyone: a quantified Result and heavy first-person Action — expect the "and what did you do?" follow-up machine to test both.
Next we'll leave Amazon's explicit rubric and look at how Google evaluates the same human qualities through "Googleyness" and general cognitive ability — a looser, committee-driven system that rewards a different flavor of the same preparation.
Editorial reflection It's easy to read the Leadership Principles cynically — a corporate catechism you memorize to pass a gate. But strip the branding and look at what they actually reward: owning problems that aren't yours, going deep instead of hand-waving, telling the truth about your mistakes, disagreeing with courage and then committing with grace. Those aren't Amazon virtues. They're just the qualities that make someone worth building software with, written down and taken seriously. You can prepare for the rubric. The better move is to become the kind of engineer the rubric was trying to describe.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.