Behavioral interviews are graded as rigorously as the coding rounds — and most engineers walk in having prepared for neither. At Amazon, a Bar Raiser sits in specifically to probe your stories against the Leadership Principles, taking written notes on whether you actually owned outcomes or just rode along. A strong coding round can be undone by a behavioral round where you ramble, stay vague, and never say what you did. This is the structure I used to prepare, and the one I look for when I'm on the other side of the table.
STAR, and where people go wrong
STAR is four parts:
- Situation — the context: the team, the stakes, the constraint.
- Task — what you specifically owned.
- Action — what you did, step by step.
- Result — the outcome, with a number.
The structure is not the hard part. The hard part is the proportions. A weak answer is 80% Situation ("so we had this legacy service, and it was built in 2019, and the team had grown, and there were three other teams depending on it…") and almost no Action. The interviewer is grading the Action and the Result. Spend your time there.
The second failure is the missing Result. "So we fixed it and things got better" is not a result. "We cut p99 latency from 800 ms to 120 ms and the support tickets for timeouts dropped to near zero" is. If you cannot quantify it, the story sounds invented.
The third is "we" the whole way through. The interviewer cannot give you credit for what the team did. Say "I" when it was you, and be honest about the boundary.
Four worked examples
Here are full STAR answers to the four themes that cover most behavioral questions. Notice the proportions — short Situation, detailed Action, quantified Result.
"Tell me about a conflict with a coworker" (Have Backbone)
S: A senior engineer on an adjacent team wanted us to adopt their shared library for our new service; it would have saved them maintenance but added a hard dependency on a system with a spotty on-call record.
T: I owned the service's reliability target — three nines — and had to decide whether to take the dependency.
A: Rather than argue in the meeting, I pulled their last six months of incident data and modeled what their outages would do to our error budget. It would have spent two-thirds of it. I wrote that up, shared it with the engineer directly before escalating, and proposed a middle path: we'd vendor the one module we actually needed and contribute fixes upstream, so they got the maintenance help without us inheriting their availability.
R: They agreed. We shipped on our reliability target, and the vendored module is still in use. The relationship stayed good because I led with their data, not my opinion.
"Tell me about a time you failed" (Earn Trust / Dive Deep)
S: I owned a migration of our billing pipeline to a new datastore. I'd tested it thoroughly in staging.
T: Cut over the production pipeline over a weekend with zero customer-visible impact.
A: I missed that staging had a fraction of production's write concurrency. The cutover hit a hot-partition limit I'd never seen in tests, and a subset of events backed up. I caught it within minutes from the dashboards I'd set up, paused the migration, and failed back to the old pipeline — no data was lost because I'd kept dual-writes on. Afterward I dug into why I missed it, added a load test that replays a day of production traffic, and made "matches production concurrency" a checklist item for any migration.
R: The retry shipped two weeks later with no issues. The bigger result: the production-replay load test caught two more concurrency bugs on later projects before they reached customers.
"Tell me about a time you led without authority" (Ownership)
S: Our team's flaky integration tests were quietly costing everyone an hour a day in reruns, but no single person owned them.
T: Nobody assigned this to me; I decided it was worth fixing.
A: I spent two days instrumenting the test suite to find the actual flaky tests — it was 6 of about 400 causing 90% of the failures. I fixed four myself, paired with the owners on the other two, and added a quarantine mechanism so a newly-flaky test couldn't block the whole pipeline. Then I shared the before/after with the team so the norm stuck.
R: Pipeline pass rate went from about 70% to 98%, and we got back roughly an engineer-hour per person per day. The quarantine pattern was adopted by two other teams.
"Tell me about a time you dealt with ambiguity" (Bias for Action)
S: Leadership asked for a "rough number" on whether a feature was worth building, with no PM and no data instrumented.
T: Give a defensible go/no-go recommendation in a week.
A: Instead of waiting for perfect data, I shipped a tiny instrumented version to 1% of traffic to measure real usage, pulled a back-of-the-envelope revenue model from comparable features, and wrote up the assumptions explicitly so they could be challenged. I gave a recommendation with a confidence range rather than a false-precision single number.
R: We greenlit it; the 1% test predicted the full rollout within about 15%. The lesson I carry: when data is missing, the fastest way to reduce ambiguity is to ship something small and measure, not to argue from intuition.
Build a story bank, not a script
You cannot prepare an answer per question — there are too many. Prepare five to seven stories with real depth, and map each to the themes it can serve. The failure story above also works for "a time you took a risk," "a time you disagreed with your own earlier decision," and "how you handle being wrong." One strong story, three or four questions.
For each story, write down: the one-line Situation, your specific Task, three or four Action beats, and the quantified Result. Then tag it with the one or two themes (or Amazon Leadership Principles) it demonstrates best. Practice them out loud — the goal is to know the beats cold, not to memorize sentences, so you sound like a person, not a recording.
The checklist before you walk in
- Short Situation, detailed Action, quantified Result — in that proportion.
- First person. "I" when it was you.
- A real number in every Result.
- Five to seven stories, each mapped to multiple themes.
- For Amazon: each story tagged to a Leadership Principle, and the Bar Raiser's notes in mind — they want evidence, not adjectives.
Get the structure right and the behavioral round stops being the coin flip most people treat it as.
Related reading: 10 common coding interview mistakes · The system design interview framework · Preparing for AI-assisted FAANG interviews
Written by Amit Singh — Senior SDE at Amazon, Claude Certified Architect, and founder of AlgoEngineer. We run mock behavioral interviews with real Bar-Raiser-style feedback in our courses.