Amazon Leadership Principles: Technical STAR Examples for Engineers (2026)

Amazon rejects engineers with clean LeetCode scores every week. The reason is almost always the same: their STAR stories read like a team retrospective, not a demonstration of individual ownership and technical judgment.

The Bar Raiser does not care that your team shipped a feature. They want to know what you decided, what trade-offs you made, and what broke because of a choice you owned. The difference between a "Hire" and a "Strong No Hire" in Amazon debriefs is not coding performance, it is the quality of the behavioral evidence.

This guide gives you real engineering STAR examples for the principles that actually get probed, plus the internal mechanics of how Amazon's debrief scoring works.

Quick Answer

Amazon's 16 Leadership Principles are not background culture. Every interviewer maps your behavioral answers to specific LPs and submits a written score within 48 hours. The Bar Raiser, an interviewer from a different team with veto power, reviews all scores and can block your hire even if every other panel member votes yes.

How Amazon Debrief Scoring Actually Works

Most candidates think of the debrief as a vote. It is not. It is a structured evidence review.

Here is the internal sequence:

1. Each interviewer submits written feedback within 48 hours. They assign a rating: Strong Hire, Hire, Inclined to Hire, Inclined Not to Hire, or Not a Hire. Every rating must be backed by specific behavioral evidence tied to named Leadership Principles.
2. Before the debrief meeting, all participants independently read every other interviewer's written submission.
3. In the debrief, the Bar Raiser facilitates, not a vote count, but a data synthesis. If your Ownership evidence was thin, the facilitator will note the gap. If your Customer Obsession story was strong but nobody probed Dive Deep, that gap surfaces.
4. A single "Strong No Hire" from the Bar Raiser effectively ends the hire.

Working inside engineering hiring pipelines, the pattern that appears consistently: candidates who lose the Bar Raiser's confidence almost never lose it on a coding problem. They lose it because their STAR stories were vague, team-attributed, or missing specific technical trade-offs.

The Bar Raiser is asking one question the entire time: "Is this person better than 50% of our current employees at this level?" Every story you tell is evidence for or against that answer.

The STAR Ratio That Amazon Actually Uses

Standard advice is to split STAR evenly. Amazon does not score it evenly. Here is the actual weight distribution in debrief:

The Action phase is where 80% of rejections are determined. Too many candidates spend two minutes on Situation and forty seconds on Action. The interviewer needs to hear specific decisions: why Redis over Memcached, why you chose to degrade gracefully rather than fail hard, what you argued against in the design review and why.

If your Action section sounds like "I worked with the team to implement a solution," the debrief note will read: "candidate does not demonstrate sufficient depth of personal contribution."

The Full List: All 16 Leadership Principles with Engineering STAR Examples

1. Customer Obsession

What gets probed: A time you made a technically costly or inconvenient decision because it was the right call for users. Amazon is not looking for generic "we care about customers" language. They want to see you deprioritize engineering convenience for user value.

STAR Example:

• Situation: Our internal API gateway was timing out for 3% of requests during peak load, causing silent failures that users experienced as blank screens with no error message.
• Task: I was the on-call SDE that week. I owned the investigation.
• Action: I traced the issue to a synchronous dependency on a slow downstream service. Rather than adding a retry loop, which would have been the faster fix, I pushed back against the PM's timeline to implement an async queue with a user-facing loading state and a retry notification. I wrote the ADR, got sign-off from the tech lead, and shipped it in 72 hours.
• Result: Timeout-related silent failures dropped to 0.1%. User-reported error tickets fell 62% that quarter.

Bar Raiser trap: If you say "we fixed the timeout issue," the next question will be "what specifically did you do?" Have your individual contribution ready to a level of detail that includes which files you changed.

2. Ownership

What gets probed: A time you took responsibility for something outside your direct scope. The Bar Raiser looks for candidates who treat organizational boundaries as suggestions, not hard stops.

STAR Example:

• Situation: During a post-incident review, I noticed that a recurring class of database deadlocks was being closed as "one-off" issues without root cause investigation. This was a different team's service.
• Task: Nobody asked me to investigate. I flagged it in the incident channel and got no response.
• Action: I pulled two weeks of deadlock logs myself, identified a missing index on a high-frequency join, and wrote up a three-page RCA with proposed fix. I presented it to the owning team's tech lead directly and offered to pair on the implementation.
• Result: The fix shipped in the next sprint. Deadlock frequency dropped 94% across the affected service. The incident count for that class of issue went from 7 in the previous quarter to 0 in the following two.

Do not say "we" once in the Action phase. Amazon interviewers are trained to catch it. Every "we built" they hear shifts a "Hire" toward "Inclined Not to Hire."

3. Invent and Simplify

What gets probed: Not just a clever idea, a simplification that solved a complex problem with less infrastructure or less code. Amazon is particularly sensitive to solutions that reduced operational burden, not just added a new abstraction layer.

STAR Example:

• Situation: Our data pipeline had grown to 14 microservices, each with independent configuration management and deployment cycles. Teams were spending 30% of sprint time on pipeline maintenance rather than feature work.
• Task: I was asked to audit the pipeline and recommend a path forward.
• Action: Instead of recommending a new orchestration tool (which was the team's first instinct), I identified that 9 of the 14 services were performing sequential, stateless transforms that could be collapsed into a single Lambda function with a config-driven step definition. I prototyped it, ran a load test against production volumes, and documented the migration path.
• Result: Collapsed 9 services into 1. Deployment time for the pipeline went from 45 minutes to 6 minutes. Maintenance overhead dropped 70%. The team redirected that time to feature delivery.

4. Are Right, A Lot

What gets probed: A high-stakes technical decision you made with incomplete data, and what happened. Amazon is looking for judgment, not luck. They want to see how you reason under uncertainty, not just that you were right.

STAR Example:

• Situation: We had a choice between migrating to a new managed database service (faster to deploy, vendor lock-in risk) or refactoring our existing self-managed PostgreSQL setup (2-month timeline, full control). Leadership wanted the migration done in four weeks.
• Task: I was the technical owner of the decision.
• Action: I documented the three scenarios, on-time migration with lock-in, delayed refactor with full control, and a hybrid escape-hatch approach that used the managed service with a data export contract in the migration agreement. I presented the risk matrix to the EM and VP with cost projections for each. I argued for the hybrid and won the debate.
• Result: Migration completed in 4.5 weeks. Eighteen months later, the vendor changed pricing by 40%. The export contract we negotiated reduced our migration cost to the new service by an estimated $180k compared to other teams that did not build in the escape hatch.

5. Learn and Be Curious

What gets probed: A time you proactively sought knowledge that made you significantly more effective, not a formal training you were assigned to complete.

STAR Example:

• Situation: Our team's distributed tracing coverage was weak. I had never worked with OpenTelemetry beyond a tutorial.
• Task: Nobody asked me to fix this. I noticed we were spending 3-4 hours per incident in manual log correlation.
• Action: I spent two weekends working through the OpenTelemetry documentation and instrumented a single high-traffic service end-to-end as a proof of concept. I documented the implementation pattern and presented it in our team's weekly sync.
• Result: Over the next quarter, three other services adopted the pattern I documented. Mean time to incident resolution dropped from 3.2 hours to 47 minutes for the instrumented services.

6. Hire and Develop the Best

What gets probed: A time you raised the quality of someone around you. Not "I mentored an intern", Amazon wants evidence that you invested in someone's technical capability in a measurable way.

STAR Example:

• Situation: A junior SDE on my team was consistently producing code that passed tests but failed code review for reasons they could not articulate, they understood what to fix but not why.
• Task: I volunteered to do one structured pairing session per week for six weeks.
• Action: I structured each session around a specific engineering concept (query optimization, race conditions, API contract design) and used their actual pull request as the teaching material. I also wrote a two-page "design thinking" doc they could reference during code review.
• Result: Their pull request approval rate went from 40% first-pass to 85% first-pass within two months. They were promoted to SDE II six months later, which their manager attributed in part to the jump in code quality.

7. Insist on the Highest Standards

What gets probed: A time you pushed back on a decision because it did not meet the bar, even when there was pressure to ship.

STAR Example:

• Situation: Three days before a major launch, QA flagged that our error messages were leaking internal service names and stack traces to end users. The PM wanted to ship with a hotfix note for post-launch.
• Task: I disagreed with the go/no-go decision.
• Action: I documented the security and brand implications of exposing internal stack traces to users, estimated the engineering time to implement a proper error serializer at 6 hours, and escalated to the engineering director directly with a written recommendation to delay 24 hours.
• Result: The fix shipped. The director approved the delay. Post-launch, two separate external security researchers flagged that exact error-leakage class as a vulnerability in a competitor's product that launched the same week. We avoided that exposure entirely.

8. Think Big

What gets probed: A time you proposed or influenced something that went beyond your immediate scope.

STAR Example:

• Situation: I was building a rate-limiting layer for one API. During the design review, I noticed that every team in the org had independently built their own rate limiter using different thresholds, different backends, and different failure modes.
• Task: My scope was one API.
• Action: I wrote a two-page technical brief proposing a shared rate-limiting service that all teams could configure via a central policy file. I presented it at the architecture review and got 4 of 6 team leads to co-author a proposal to the VP.
• Result: The shared service was approved for a Q3 initiative. Adoption across 8 teams consolidated what had been 8 separate Redis clusters into 1, reducing infrastructure cost by an estimated $220k annually.

9. Bias for Action

What gets probed: A time you moved fast with incomplete information and it was the right call, with a clear explanation of the risk you accepted.

STAR Example:

• Situation: At 11 PM on a Friday, our monitoring showed a 40% increase in database query time with no clear root cause. On-call rotation had me as secondary. The primary was unreachable.
• Task: Wait for the primary or act.
• Action: I did not wait. I pulled the slow query log, identified a full-table scan on a 200M-row table that had appeared after a schema migration earlier that day, and added a missing index directly on the production database after confirming read impact was safe.
• Result: Query time normalized within 4 minutes. The primary came online 20 minutes later. I documented the full RCA and added the missing index check to our migration deployment checklist.

10. Frugality

What gets probed: A time you achieved a significant outcome with less budget, fewer resources, or less infrastructure than the standard approach required.

STAR Example:

• Situation: My team was given a budget to purchase a third-party ML inference service for a recommendation feature. The annual license was $180k.
• Task: I was skeptical the license was necessary at our scale.
• Action: I benchmarked our actual inference requirements against a self-hosted ONNX runtime running on our existing EC2 instances. I documented the latency comparison (within 8ms of the vendor's hosted service) and cost projection ($12k/year in compute vs. $180k in licensing).
• Result: Leadership approved the self-hosted approach. We delivered the same recommendation performance at 93% lower cost. The $168k savings were reallocated to the team's headcount plan for the following year.

11. Earn Trust

What gets probed: A time you were transparent about a failure or risk, before you were asked. Not a story about being liked. A story about creating the conditions for trust by being honest about something uncomfortable.

STAR Example:

• Situation: I discovered that a data migration I had signed off on three months earlier had silently corrupted a small percentage of records, 0.3%, in a downstream reporting table.
• Task: Nobody else had noticed. I could have fixed it quietly.
• Action: I immediately documented the scope, wrote an incident report, notified the data science team who owned the reporting system, and sent a summary to my EM and the affected team's manager. I proposed a remediation plan and owned the fix timeline.
• Result: The corruption was remediated within a week. The data science team explicitly cited the early, proactive disclosure as the reason they trusted my team for a joint infrastructure project the following quarter.

12. Dive Deep

What gets probed: A time you went several levels below the surface of a problem to find the actual root cause rather than accepting the first plausible explanation.

STAR Example:

• Situation: Our payment service was experiencing intermittent failures, roughly 1 in 10,000 requests. Monitoring showed no pattern. The initial diagnosis from the team was "network flakiness."
• Task: I did not accept that explanation.
• Action: I added microsecond-level trace logging to the payment handler, captured 500 failures, and found that all of them occurred within a 30-second window after a full garbage collection pause in the JVM. The GC pause was causing connection pool timeouts that the retry logic was incorrectly classifying as transient network errors. I tuned the GC configuration, adjusted the connection pool timeout thresholds, and added a metric specifically tracking GC-induced failures.
• Result: That failure class dropped to 0. Overall payment error rate went from 0.01% to under 0.001%.

13. Have Backbone; Disagree and Commit

What gets probed: A time you disagreed strongly with a technical or product decision, made your case clearly, lost the vote, and still executed fully.

STAR Example:

• Situation: The team voted to use a GraphQL API for a new internal service. I believed it added unnecessary complexity for a service that had exactly two consumers with well-defined query patterns.
• Task: I made the case for REST with a clear two-page comparison. The team voted 4 to 1 for GraphQL.
• Action: I disagreed clearly and documented my concerns in the ADR as the minority opinion. Then I led the GraphQL implementation myself, built the schema, wrote the resolver logic, and delivered it two days ahead of schedule.
• Result: Three months later, the team independently decided to migrate to REST because the GraphQL overhead was creating maintenance friction. My original ADR was referenced in the migration proposal. I did not say "I told you so", I led the migration.

14. Deliver Results

What gets probed: A time you hit a hard deadline against significant obstacles. Amazon wants to see that you can identify what matters and cut what does not when under pressure.

STAR Example:

• Situation: Two weeks before a customer commitment deadline, a key third-party integration vendor informed us they were deprecating the API version we were using, effective immediately.
• Task: We had 14 days to migrate or fail the commitment.
• Action: I triaged the integration, identified that only 3 of 11 endpoints were critical to the committed feature, and proposed a phased migration: ship the 3 critical endpoints by deadline, defer the remaining 8 to the next sprint. I got stakeholder sign-off in 4 hours, assigned myself the two highest-risk endpoints, and coordinated the remaining work across two other SDEs.
• Result: Shipped the critical scope 2 days before deadline. Customer commitment was met. The full migration completed in the following sprint with zero additional issues.

15. Strive to Be Earth's Best Employer

What gets probed at L5+: A time you created conditions that made your team more effective, safer, or more equitable. At senior levels, Amazon probes this LP explicitly.

STAR Example:

• Situation: Our on-call rotation was burning out junior engineers, they were getting paged for incidents they had no context on because runbooks were outdated or nonexistent.
• Task: I was not the on-call manager. I owned nothing officially here.
• Action: I proposed a "runbook sprint", one week where on-call engineers documented every playbook they used during incidents. I built the template, seeded it with three examples from my own incidents, and created a Slack bot that surfaced the relevant runbook automatically when a specific alert fired.
• Result: Runbook coverage went from 20% to 91% of active alerts within 6 weeks. After-hours page volume for junior engineers dropped 55%. One engineer told me directly that they stopped dreading the on-call rotation after that quarter.

16. Success and Scale Bring Broad Responsibility

What gets probed at L6+: A time you considered second-order effects of a technical decision on external stakeholders, not just internal teams.

STAR Example:

• Situation: Our team was building a data ingestion pipeline that would collect behavioral signals from users across a mobile app with 4M active users.
• Task: I was the technical lead on privacy design for the pipeline.
• Action: Before any architecture was finalized, I added a privacy threat model review to our design doc process. I identified that three of our planned signals (precise scroll depth, exact tap coordinates, and session recording) were beyond what our privacy policy disclosed. I documented the exposure, proposed anonymized aggregate alternatives for two signals, and recommended removing the third entirely. I presented this to the product and legal teams before the build began.
• Result: The pipeline shipped without the three problematic signals. Six months later, a competitor was fined under state privacy law for collecting functionally identical signals. We had no exposure.

The 3 Most Common LP Rejection Patterns (From Debrief Notes)

Pattern 1: Team Language in the Action Phase Saying "we built," "we decided," or "we resolved" removes your individual signal from the record. Amazon's interviewers are trained to note this specifically. The debrief note reads: "candidate lacks clarity on personal contribution." Fix: use "I" for every decision and action, "we" only for collective goals or outcomes.

Pattern 2: Stretching One Story Across Multiple Principles Trying to use the same project to answer Customer Obsession, Ownership, and Deliver Results in the same loop is a red flag. It signals you have limited range of experience. Prepare 8 to 10 distinct STAR stories mapped to different LPs.

Pattern 3: Missing the Follow-Up Depth Amazon interviewers probe 3 levels deep. If your story is a well-rehearsed surface narrative and you cannot explain what was in the logs, what trade-offs you rejected, or what you would do differently, the interviewer flags you as someone who had "involvement" rather than "ownership." Every story you prepare should have three additional layers of specific technical detail you can surface on demand.

How to Build Your STAR Story Portfolio

You need 8 to 10 distinct stories. Here is the minimum coverage map:

Each story needs to survive 3 levels of follow-up questioning. If you cannot answer "what specifically was in the query plan that showed the bottleneck?" you are not prepared for the Dive Deep probe.

For salary context on the level you are targeting, see the Amazon Software Engineer Salary Guide.

Frequently Asked Questions

How many Leadership Principles does Amazon have in 2026?

Amazon has 16 Leadership Principles as of 2026. The two most recently added, "Strive to Be Earth's Best Employer" and "Success and Scale Bring Broad Responsibility", were introduced in 2021 and are now actively assessed in senior-level interviews (L5 and above).

How many STAR stories do I need to prepare for an Amazon interview?

Prepare 8 to 10 distinct stories. Each should cover a different Leadership Principle. Recycling the same project across multiple LPs is a red flag that signals limited experience range. Every story should be able to survive 3 levels of follow-up questioning.

What is a Bar Raiser at Amazon?

A Bar Raiser is a specially trained interviewer from outside the hiring team. They have veto power over the hire, regardless of what the rest of the panel votes. Their job is to ensure that every new hire raises the overall quality bar, not just fills the headcount. They score every behavioral answer against Amazon's Leadership Principles and their veto is effectively final.

Why do Amazon interviewers keep saying "tell me more" or asking follow-up questions?

Amazon interviewers probe 3 levels deep to verify that your story is authentic and that you personally owned the work. Level 1 is the tactical "what happened." Level 2 is the analytical "why did you make that decision." Level 3 is reflective, "what would you change?" If you have only prepared a surface narrative, you will run out of specifics at level 2.

What is the "We vs. I" problem in Amazon interviews?

Using "we" in your Action phase prevents the interviewer from evaluating your specific contribution. Amazon hires individuals, not teams. Interviewers are explicitly trained to note team-language as a signal of "insufficient personal ownership." Use "I" for every technical decision and action you took personally. Reserve "we" only for the team's collective goal or final outcome.

Does Amazon interview for all 16 Leadership Principles in every loop?

No. A typical interview loop has 5 to 6 interviewers, each assigned to probe 2 to 3 specific LPs. Customer Obsession, Ownership, Dive Deep, and Deliver Results are the most frequently assigned LPs across all loops. At senior levels (L6+), Hire and Develop the Best and Success and Scale Bring Broad Responsibility are almost always included.