Interviews

Leadership Principles and the STAR method

Amazon publishes a set of Leadership Principles and uses them in hiring. The list and the company's own wording live on Amazon's Leadership Principles page. Read that page when you want the canonical sentences. This guide does not replace it, and it does not quote it back at you. Principles are titles plus a way of behaving. Reciting a title in an interview is not the same as showing the behavior.

The principles you will see named publicly include Customer Obsession, Ownership, Invent and Simplify, Are Right A Lot, Learn and Be Curious, Hire and Develop the Best, Insist on the Highest Standards, Think Big, Bias for Action, Frugality, Earn Trust, Dive Deep, Have Backbone, Deliver Results, and two newer ones about being a good employer and about the responsibility that comes with scale. Roles differ in which principles a loop emphasizes. A new graduate loop and a senior loop do not sound the same. Do not build a cheat sheet that assumes a fixed set of sixteen questions. Build a small set of true stories that can be aimed at more than one principle, because the question you get will not use the title as a label.

What STAR is for

STAR is a shape for a story: situation, task, action, result. Situation is the context a stranger needs and no more. Task is the specific responsibility you had, not the team's mission statement. Action is what you did, in an order someone could follow. Result is what changed, preferably with a checkable detail. If you do not have a number, a checkable detail can be a decision that shipped, a bug that stopped recurring, or a teammate who took the work over after you wrote the notes down.

The shape exists because unstructured answers wander. They spend three minutes on the situation, because the situation is easy to remember, and twenty seconds on the action, which is the part the interviewer can judge. A useful ratio is roughly one sentence of situation, one of task, most of the answer on action, and a short result. Practice with a timer. Two minutes is enough for one story. Four minutes usually means you are retelling the whole project.

STAR is not a performance of perfection. "Are Right A Lot" includes changing your mind when the evidence changes. A story where you were wrong, noticed, and repaired the damage is often stronger than a story where you were the hero of every act. The debugging guide is the technical version of the same habit: hypothesis, check, one change.

One fictional story, told on purpose

The following story is fiction, written so the shape is visible. Do not memorize it and present it as your life. Use it as a template for a story you actually have. If you do not have a job yet, a class project, a campus organization, or a bug you chased in your own code is a valid setting. Inventing a job is not.

Situation: three students were building a class tool that emailed a weekly study plan. The night before the demo, the mailer worked on their laptops and failed for two classmates. Task: one student owned the mailer. The demo could not move, and the professor was not going to accept a "it works for us."

Action: that student stopped adding features. They asked the two classmates for the exact error text and whether the failure was immediate. Both saw a timeout, and both had imported a class list of a few thousand rows, while the authors had tested with thirty. The student wrote down "input size" before touching code. They reproduced the timeout with a generated list of two thousand fake rows. The slow step was a lookup that scanned the whole list for every row. They replaced that scan with a dictionary keyed by student id, which is the same move as the arrays and hashing page, and they reran the two-thousand-row case. They also sent the classmates a one-line note that the demo build was delayed by an hour and why. They did not rewrite the mailer.

Result: the generated list and the classmates' lists both finished. The demo included the failure and the fix, because hiding it would have wasted the only interesting part. The dictionary change was a few lines. The behavior on display was Dive Deep, Customer Obsession aimed at the classmates who were blocked, and Bias for Action that was still measured. You could aim the same story at Ownership, because nobody assigned the student the incident, or at Earn Trust, because they told the truth about the delay before they had the fix.

Notice what is absent. There is no claim about a company's internal tool. There is no slogan stacked on a slogan. There is a number, a wrong approach, a change, and a second test. That is the standard you want for your own stories. If your story cannot survive the question "what did you personally type, say, or decide," it is still a situation, not an answer.

How to build a small bank

Write six stories from your real experience. For each, record four lines: the setting in one sentence, the choice you made, the alternative you rejected, and the result. The rejected alternative is where Backbone and Frugality and Invent and Simplify usually live. "We used a dictionary instead of a new service" is Frugality and Invent and Simplify if it is true. It is nothing if you only say "I am frugal."

Then tag each story with two principles it can honestly support. Do not tag all sixteen. A story that tries to prove everything proves nothing. You want overlap, not a matrix you will not remember under pressure. Review the tags the morning of an interview and then put the list away. In the room, listen to the question and pick the story whose action matches the verb you were asked about. "Tell me about a time you disagreed" is a Backbone question even if the word Backbone is never said. A story about a successful launch with no disagreement is the wrong drawer.

Prepare at least one story where the result was mixed. Deliver Results does not mean every project was a triumph. It means you can describe what shipped, what did not, and what you did when the date slipped. Interviewers who have heard hundreds of answers can hear a story that has been sanded free of difficulty. Leave one rough edge in. The rough edge should still be something you handled, not a complaint about a teammate's character. Blaming a named person for being careless is a fast way to fail Earn Trust, even if the incident was real.

Work-style questionnaires and live interviews

Some candidates describe a written work-style section in an early screen. The format guide treats that as a reported category, not a guarantee. If you meet one, answer as the person you are on an ordinary Tuesday. Contradicting yourself to sound more agreeable is visible when the same theme returns in different words. A live interviewer will also ask follow-ups a questionnaire cannot. "What did you do next?" is the follow-up that empties a memorized answer. Practice it with a friend who is allowed to interrupt.

For a system design conversation later, the same principles show up as engineering choices. Customer Obsession is naming the user of the design. Frugality is not proposing a cluster for a problem that fits on one machine. Dive Deep is knowing which number in your sketch is a guess. The system design page is the technical companion. You do not need a second personality for it.

Practice drill

Record yourself telling one real story in two minutes. Listen for the moment you say "we" when you mean "I." Change those sentences. Listen for a result that is only an adjective. Replace the adjective with a checkable detail, or admit you did not measure it. Then retell the same story in answer to a different prompt: once as a disagreement, once as a time you simplified something. If one of those retellings is a stretch, drop that tag. A smaller bank of honest stories beats a large bank of costumes.

On the day, pause before you pick the story, and start with the task rather than a biography. The interviewer can ask for context. They cannot invent an action you never describe. The four-week plan puts the first three stories in week two so you are not writing them the night before a loop.