R11·LP · Part 3 · The people rounds
Amazon: the Leadership Principles loop
Amazon is the largest hirer of experienced engineers in India, and its loop does not work like the others in this book. There is no separate behavioural round to prepare for — every interviewer spends part of their hour on Leadership Principles, writes up what you said, and the decision gets made in a room you are not in. Prepare for this the way you would prepare for a system design round, because it carries about as much weight.
- product
- saas
- service (less often)
- agency (less often)
Everything open, top to bottom.
09On this page
- Which principles actually come up for an SDE-2 or SDE-3?
- The story bank: six events, sixteen principles
- STAR, and the part everyone gets wrong
- Tell me about a time you took ownership of something outside your remit.
- Tell me about a time you disagreed with a senior engineer or your manager.
- Tell me about the most complex problem you have dug into.
- Tell me about a time you were wrong.
- The Bar Raiser, and how to behave when it is your last round
- The rest of the loop
| What happens | What it means for you |
|---|---|
| Every interviewer is assigned two or three Leadership Principles | The same story gets asked for three times in one day, from three angles. It has to survive being retold. |
| They take near-verbatim notes while you talk | A vague sentence becomes a vague note. Specifics are the only thing that survives into the debrief. |
| One interviewer is a Bar Raiser — from another org, not hiring for this team, trained for it | They are measuring you against everyone Amazon has hired, not against this team's opening. They can block a hire on their own. |
| The decision is made in a debrief after the loop, from those notes | You are not there to clarify. What is written is what gets argued over. |
Which principles actually come up for an SDE-2 or SDE-3?
What they are really testingNothing yet — but preparing all sixteen equally is how people run out of time.
There are sixteen. For an individual contributor at your level, six carry most of the loop:
- Ownership — you did something nobody asked you to own, and stayed with it.
- Dive Deep — you went to the bottom of a problem rather than around it. This is the one engineers under-prepare and the one Bar Raisers love.
- Deliver Results — it shipped, and you can say what it moved.
- Have Backbone; Disagree and Commit — you pushed back on someone with more authority, and then committed to whatever was decided.
- Customer Obsession — you changed something because of a user, not because of a ticket.
- Are Right, A Lot — usually asked backwards: tell me when you were wrong.
The others turn up, but rarely as the main question: Invent and Simplify, Learn and Be Curious, Insist on the Highest Standards, Bias for Action, Frugality, Earn Trust, Think Big, Hire and Develop, Best Employer, Success and Scale.
2026: most orgs have stopped running a standalone behavioural round and folded the principles into every technical round instead. Do not wait for the LP round — the coding interviewer will ask one too, usually in the last fifteen minutes.
The story bank: six events, sixteen principles
What they are really testingPreparation. Nobody improvises a specific answer with numbers in it.
You do not need sixteen stories. You need six real events, told at enough depth that they can be cut different ways. For the example profile, these are the six:
Using the same story twice in the same interview. Interviewers compare notes; a candidate with two stories reads as a candidate with two years. Keep a mental note of which event you have already spent.
| Event | Cuts for |
|---|---|
| The four environments on the booking platform — different data, secrets and provider keys, rationalised into one provisioning path, infrastructure cost down twenty percent | Ownership · Dive Deep · Frugality · Deliver Results |
| The live dashboard over bookings, no-shows and reliability metrics — you built the thing that told everyone whether the platform was actually working | Customer Obsession · Insist on the Highest Standards · Invent and Simplify |
| A technical decision you pushed back on and lost, then implemented properly anyway | Have Backbone; Disagree and Commit · Earn Trust |
| A decision of yours that turned out wrong, and what it cost before you caught it | Are Right, A Lot · Learn and Be Curious |
| A client handover at the studio — a codebase someone else had to run after you left | Earn Trust · Insist on the Highest Standards · Hire and Develop |
| Something you shipped under a deadline that was not negotiable, and what you cut to make it | Bias for Action · Deliver Results · Think Big |
Write each one out once, properly, and the loop stops being twenty questions. It becomes six things you know cold, re-aimed.
STAR, and the part everyone gets wrong
What they are really testingWhether your answer has a shape the interviewer can write down.
Situation, Task, Action, Result. The mistake is the proportions: most candidates spend two minutes setting up the situation and thirty seconds on what they did. Amazon is scoring the Action, and the Action has to be yours.
- Situation — two sentences. Enough to know why it mattered.
- Task — one sentence. What was on you specifically.
- Action — sixty to ninety seconds, and every verb is "I". This is the answer.
- Result — a number, and how you know it.
Situation. The booking platform ran across four environments and each one had drifted — different data, different secrets, different provider keys. Deploys took about three hours by hand and broke in ways that only showed up in one of them. Task. I owned the service layer and the deploy, so it was mine to fix. Action. I mapped what actually differed between the four, moved every difference into configuration rather than code, rebuilt provisioning so an environment came up the same way every time, and cut the ones nobody was using. Result. Infrastructure cost dropped about twenty percent, and a deploy went from about three hours to about twenty minutes.
"We migrated the environments." The interviewer cannot write that down as your action. If the team did it, say what you did inside it — the honest version is always more specific than the "we" version, not less.
- What did you personally build versus what did someone else build?
- How did you measure the twenty percent?
- What would you do differently?
- Who disagreed with you, and what did they say?
Tell me about a time you took ownership of something outside your remit.
What they are really testingOwnership. Whether you act like the outcome is yours when nobody has made it your job.
The story wants three beats: it was not yours, you took it, and you stayed with it past the interesting part. That last one is where most answers stop early — Amazon reads "I fixed it and moved on" as enthusiasm, and "I fixed it and then owned the thing it became" as ownership.
Nobody owned reliability across the three client applications — each project had a lead and reliability fell between them. I started with our own alerting because I was tired of hearing about outages from the client, then extended the same setup across the other two, and ended up owning the on-call rotation and the post-incident notes for all three. That was not my role when I started; it is what I do now.
A story where you took something on and handed it away the moment it got boring. Ownership at Amazon explicitly includes the boring part — "leaders never say that is not my job" is the second line of the principle.
- What did you stop doing to make room for it?
- Did you ask permission, or ask forgiveness?
- What broke after you took it on?
Tell me about a time you disagreed with a senior engineer or your manager.
What they are really testingHave Backbone; Disagree and Commit — and the second half is the half people forget.
The principle is two things joined: you argue hard when you think something is wrong, and then you commit fully to whatever the group decides even when it was not your call. An answer that only does the first half reads as difficult. An answer that only does the second half reads as having no opinions.
So the story must end after the decision, not at it. What did you do once you lost?
We were about to put booking confirmation emails inline in the request path. I thought it was wrong — a slow provider would become our latency, and a failed send would fail the booking. I brought numbers from our own logs on provider response times and argued for a queue. The lead decided to ship it inline for the launch because the queue was another week. I disagreed, said so once more clearly, and then built the inline version properly with a timeout and a retry so it would fail safely. It bit us three weeks later exactly the way I expected, and by then the queue was a small change because I had left the seam for it.
Picking a disagreement you won. It is a weaker answer: the principle is about how you behave when the decision goes against you, and a story where you were overruled and still delivered is worth more than one where you were right and got your way.
- How did you raise it — in the room or afterwards?
- What would you have done if it had never bitten you?
- Has anyone ever disagreed with you like that?
Tell me about the most complex problem you have dug into.
What they are really testingDive Deep. Whether you go to the bottom of a thing or stop at the layer you are comfortable in.
This is the one where a Bar Raiser will keep pulling. Expect four or five follow-ups, each one a layer down, until you either hit something you genuinely do not know or they run out of questions. Both endings are fine; pretending is not.
Pick something where you actually went below your own stack. A React bug is not a deep dive. A bug you chased from a symptom in the browser into the runtime, the network, or the database is.
Booking counts on the live dashboard were drifting from what the calendar provider reported, by a few percent, only under load. I could have rounded it away. Instead I traced one booking end to end — the event we recorded, the timestamps we took, and where they came from. The provider timestamps were their clock, ours were ours, and under load our webhook handling fell far enough behind that the windows we were bucketing into no longer lined up. I moved the bucketing to a single clock and the drift went away. The number was small; the reason it existed was not.
"I checked the logs and found the issue." That is the shape of an answer, not an answer. The interviewer wants the chain — what you saw, what you suspected, what you ruled out, and how.
If they push past what you know, say so and say what you would have looked at next. "I never found out why the provider clock skewed — I would have started by comparing their timestamps against a third source" scores better than a confident invention. Bar Raisers are unusually good at spotting the invention.
- Why did that only happen under load?
- What did you rule out first, and why?
- How would you stop it recurring?
- What did you not get to the bottom of?
Tell me about a time you were wrong.
What they are really testingAre Right, A Lot — which is asked backwards, because being wrong well is the evidence.
Two failure modes here, and most candidates hit one of them: the humblebrag ("I was wrong to work too hard on quality") and the disaster with no learning attached. What scores is a real decision, a real cost, and a change in how you decide now.
Say the cost in a number if you have one. Time, money, or an outage — an unquantified mistake reads as one you did not really absorb.
On one of the client applications I chose a document database because the shape of the data looked flexible early on. Two months in, half the features were joins I was doing in application code, and one report took a page of aggregation to write. It was my call and I had made it on the shape of week one rather than the shape of the roadmap. We moved to Postgres, which cost about three weeks. What changed is that I now ask what the reporting will look like before I pick the store, because reporting is where the relational shape shows up whether you planned for it or not.
A mistake that was really someone else's — a bad spec, a manager's deadline, an unreliable vendor. The question is what you got wrong. Choosing a story where you were the decision-maker is most of the answer.
- When did you realise?
- Who did you tell, and how quickly?
- What do you do differently now?
- Have you made the same class of mistake since?
The Bar Raiser, and how to behave when it is your last round
What they are really testingConsistency. They are checking whether the person in the fifth hour is the same one from the first.
- They are not from the team. Enthusiasm about this specific role lands less than usual; what lands is whether you are above the bar generally.
- They will ask the same principle another interviewer asked. The answer must match. Do not improve the story between rounds — a detail that grows across a day is the thing the debrief notices.
- They will push further than anyone else. Four follow-ups deep is normal. Slow down rather than speed up.
- They can block on their own. A team that wants you cannot override them, which is exactly the point of the role.
If you are asked something you already answered: "I think I covered this with [name] earlier, but happy to go through it again —" and then tell it the same way. Recognising the repeat is a good signal; a different version of it is a bad one.
Running out of stories by round four and reusing one you have already spent. Six events, mapped in advance, is the whole defence — that is what the story bank above is for.
The rest of the loop
What they are really testingNothing. Answer in a line each and keep it moving.
- Why Amazon? One reason about scale or ownership, one about the specific org if you know it. Not "it is a great company".
- Where do you want to be in three years? An answer that involves owning more, not managing more, unless you actually want to manage.
- What are you looking for that you do not have? The client-studio-to-product story from R1 works here unchanged.
- Do you have questions? Ask what the team owns end to end, and what the on-call load actually is. Both are answerable and both tell you something.
- Writing. Some orgs will ask you to talk through a document, or mention that the team writes six-pagers. If it comes up, know that Amazon runs on written narratives rather than slides, and that meetings open with everyone reading in silence.
Finished this round?
0 of 27 rounds read in this book