Amazon 16 Leadership Principles: Complete List & Engineering STAR Questions (2026)

Bottom Line: Amazon rejects engineers with perfect LeetCode scores every single week. They do not fail because of algorithms; they get rejected during the Bar Raiser debrief because their behavioral STAR stories sound like team retrospectives rather than demonstrations of individual technical ownership.

In almost every panel debrief I have run, the tie-breaker between two candidates never came down to LeetCode speed: candidates who get marked "Strong No Hire" almost never fail on coding syntax. They fail because their behavioral evidence is vague, team-attributed, or falls apart when the Bar Raiser probes two layers beneath the surface.

Amazon evaluates candidates against 16 distinct Leadership Principles (LPs). Every interviewer on your 5-person loop is assigned two or three specific principles, and their written evaluation dictates whether you get an offer, get downleveled, or get blocked.

Here is the complete operational playbook: all 16 Leadership Principles decoded for software engineers, the exact questions asked, high-scoring STAR scripts, and the internal debrief mechanics used to grade your performance.

Complete Master List: All 16 Amazon Leadership Principles

Before stepping into your loop, understand which principles map to which engineering competencies. Use this verified directory:

Behind Closed Doors: How the Bar Raiser Debrief Works

The Amazon debrief is not a casual vote. It is an evidence-based calibration session governed by strict internal rubrics.

1. The Scorecard Rubric and 48-Hour Feedback Lock

Here is the exact scorecard rubric interviewers fill out within 15 minutes of hanging up: they must submit detailed behavioral observation notes and an independent hiring recommendation into the internal recruiting portal before they are allowed to see what any other interviewer wrote.

The four official ratings are:

• Strong Hire (SH)
• Hire (H)
• Inclined Not to Hire (INH)
• Strong No Hire (SNH)

If an interviewer submits a "Hire" on coding but a "Strong No Hire" on behavioral evidence, that conflict immediately triggers a targeted deep-dive during debrief.

2. The Bar Raiser's True Role

The Bar Raiser is an interviewer from an unrelated division (for instance, an AWS database engineer interviewing a Prime Video candidate) whose performance is evaluated on hire quality.

Their mandate is explicit: Is this candidate better than at least 50% of current Amazon engineers at this level?

The Bar Raiser holds veto authority. Even if the hiring manager is desperate to fill the seat, a Bar Raiser can veto the offer if your behavioral examples show a pattern of low ownership, inability to dive deep, or reluctance to earn trust.

3. Leveling Calibrations (L4 vs. L5 vs. L6 vs. L7)

During debriefs where a candidate passes the hiring bar, the conversation shifts to leveling:

• L4 (SDE I/II): Evaluated on tactical execution, unit test coverage, and resolving well-scoped engineering tickets.
• L5 (SDE II/Senior): Evaluated on end-to-end service design, cross-service dependencies, unblocking junior teammates, and handling production on-call.
• L6 (Senior/Lead): Evaluated on multi-team architectural standards, driving organizational best practices, and mentoring engineers to promotion.
• L7 (Principal Engineer): Evaluated on multi-year technical strategy, company-wide operational resiliency, resolving cross-VP technical disputes, and driving industry-defining technology choices.

If your STAR examples only demonstrate L4-level scope (fixing local bugs) when interviewing for an L5 position, the debrief panel will downlevel your packet.

The 10-60-20 STAR Formula for Software Engineers

Most online career blogs tell candidates to split the STAR method into equal 25% quadrants. In an Amazon technical interview, that advice will get you rejected.

If you spend 2 minutes describing the company background and 45 seconds on your action, the interviewer will cut you off. Use the calibrated 10-60-20 rule:

The "I vs. We" Rule

Amazon hires individual contributors, not abstract team units.

When candidates say: "We decided to migrate our cache to Redis and then we re-indexed our Postgres database," the interviewer writes in their scorecard: "Candidate lacks clear personal ownership; unclear what code they wrote versus observed."

Always say: "I conducted the profiling analysis, identified the lock contention in Postgres, and wrote the migration script to move our session store to Redis."

All 16 Leadership Principles: Real Engineering STAR Scripts

Here are production-grade engineering STAR answers designed to pass Bar Raiser scrutiny.

1. Customer Obsession

The Trap: Giving a generic answer about "caring about users." Amazon wants to hear you sacrifice engineering convenience or push back on product timelines to protect customer experience.

• Situation: During peak Q4 traffic, our checkout service experienced a 3.2% error rate due to connection timeouts in a downstream third-party tax calculation API.
• Task: As primary on-call, I needed to restore zero-error checkout completion without exposing users to failed payment loops.
• Action: I rejected the quick fix of increasing the HTTP client timeout, which would have held open server worker threads and cascaded into total gateway failure. Instead, I designed an asynchronous fallback mechanism: I implemented a regional tax-estimation lookup table with Redis caching, allowing transactions to complete in under 80ms while triggering an asynchronous background reconciliation job to settle exact tax differentials within 10 minutes.
• Result: Checkout failure rates dropped from 3.2% to 0.02%. Over $420,000 in at-risk cart volume was preserved during the 48-hour vendor outage.

2. Ownership

The Trap: Talking about a project assigned to you on your Jira sprint board. Ownership means stepping across team boundaries without permission because the system required intervention.

• Situation: While debugging latency on my team's user authentication service, I discovered that an upstream identity service owned by a separate division was generating 14 redundant database queries per token validation.
• Task: The upstream service was outside my team's jurisdiction, and their backlog was backlogged for six months.
• Action: Rather than filing an ignored ticket, I cloned their repository, profiled the query execution plans in an isolated staging environment, and identified an N+1 query issue in their ORM layer. I wrote a batch query refactor, added regression integration tests, and scheduled a 30-minute code review with their principal engineer to walk through the diff.
• Result: After deploying my patch, database CPU utilization on their service dropped by 44%, and our end-to-end token verification latency decreased by 65ms across 12 million daily authentications.

3. Invent and Simplify

The Trap: Presenting an overly complex system with 10 microservices to show off architecture. Amazon rewards stripping away complexity and deleting code.

• Situation: Our ETL pipeline had accumulated 11 distinct microservices with separate message brokers to process, validate, and enrich ingested event streams, requiring 15 hours of manual on-call triage weekly.
• Task: I was tasked with redesigning the ingestion pipeline to support a 3x traffic increase without expanding our infrastructure footprint.
• Action: I analyzed the data flow and proved that 8 of the intermediate transformations were stateless row mappings. Instead of adding a complex streaming orchestration layer, I collapsed those 8 services into a single modular event processor running as a containerized worker, replacing three Kafka topics with an in-memory ring buffer.
• Result: We deleted over 14,000 lines of boilerplate infrastructure code, reduced end-to-end pipeline latency from 18 seconds to 1.4 seconds, and cut annual AWS compute spend by $115,000.

4. Are Right, A Lot

The Trap: Claiming you are always right. Amazon wants to see deep technical conviction based on first principles, even when the consensus is against you, paired with strong self-correction.

• Situation: Our engineering organization was preparing to migrate our primary transactional datastore from relational Postgres to a NoSQL document database because the team believed our write volume was outgrowing relational limits.
• Task: I was the sole senior engineer arguing that a NoSQL migration would introduce catastrophic data consistency bugs in our multi-currency accounting ledger.
• Action: I spent three days benchmarking our actual production write profile. I demonstrated that 80% of our write locks were caused by inefficient index bloat and un-sharded audit logs, not fundamental Postgres engine limitations. I built a working prototype demonstrating horizontal table partitioning with Citus, proving we could scale writes by 10x while maintaining strict ACID transactional integrity.
• Result: The VP of Engineering halted the NoSQL migration, saving an estimated 9 months of migration engineering. Two years later, the partitioned Postgres architecture continues to handle 4x our initial peak volume with zero ledger discrepancies.

5. Learn and Be Curious

The Trap: Talking about taking an online certification course. Amazon wants to see self-directed technical research that you operationalized to solve a real production problem.

• Situation: Our mobile application backend was struggling with battery drain and excessive payload sizes caused by legacy REST endpoints returning bloated JSON payloads over cellular networks.
• Task: Nobody on the team had production experience with binary serialization protocols or gRPC over HTTP/2.
• Action: Over two weeks, I built a prototype comparing Protocol Buffers, FlatBuffers, and JSON across varying network packet loss rates. I documented the serialization latency, CPU utilization overhead, and bandwidth consumption in a comprehensive whitepaper. I then presented a live demonstration to our platform team showing a 70% reduction in payload transit times.
• Result: I led the incremental rollout of Protobuf across our mobile gateway. Average API payload size dropped by 64%, and mobile app network error rates in low-connectivity markets decreased by 28%.

6. Hire and Develop the Best

The Trap: Saying "I helped answer questions for an intern." Amazon evaluates how you raise the technical baseline of everyone around you.

• Situation: Two mid-level engineers on my team were struggling to clear design review hurdles, frequently getting their architectural proposals rejected due to unaddressed distributed system failure modes.
• Task: I wanted to systematically improve their systems design capabilities rather than simply correcting their designs in reviews.
• Action: I established a weekly "Failure Mode Architecture" workshop. We analyzed past production post-mortems, dissected split-brain scenarios, and practiced modeling backpressure and circuit breakers. I created an internal Design Document Checklist that formalized our team's operational requirements for observability, rollback plans, and data migration safety.
• Result: Within 6 months, both engineers authored and defended major architectural proposals that cleared the organization-wide principal review on the first pass. Both engineers were promoted to Senior SDE (L5) within the following year.

7. Insist on the Highest Standards

The Trap: Being a perfectionist who misses deadlines. Highest standards means refusing to ship code with hidden risks, even under intense delivery pressure.

• Situation: We were 48 hours away from a highly publicized enterprise customer launch when I noticed that our integration tests passed, but our load test logs revealed race conditions in inventory reservations occurring in 0.05% of concurrent requests.
• Task: The product manager urged me to sign off on the launch and patch the race condition in a post-launch maintenance cycle.
• Action: I refused to approve the production release. I explained that under expected launch-day concurrency, a 0.05% race condition would result in hundreds of oversold physical items, creating catastrophic customer service escalations. I drafted a mitigation plan, worked through the night to implement distributed Redis locks with optimistic concurrency controls, and re-ran the full 10,000-user concurrency suite.
• Result: The launch was delayed by exactly 18 hours, but we processed 180,000 orders during the initial 24-hour window with zero inventory allocation errors.

8. Think Big

The Trap: Presenting an incremental optimization as "big." Think Big requires looking at multi-year horizon architectures that change business trajectory.

• Situation: Our internal video transcoding team was spending $60,000 monthly running on-demand EC2 GPU instances that sat idle at 15% average utilization between batch rendering jobs.
• Task: My initial mandate was to optimize the cron scheduling script to turn off instances at night.
• Action: I stepped back and proposed a completely serverless transcoding architecture utilizing AWS Fargate with spot compute and event-driven SQS scaling. I engaged with three other media divisions within the company that were operating their own siloed transcoding farms, presenting a consolidated multi-tenant platform proposal to our Vice President.
• Result: The unified media platform consolidated four disparate engineering teams onto one shared infrastructure. We reduced overall corporate compute spend by $1.8 million annually while increasing maximum transcoding throughput capacity by 400%.

9. Bias for Action

The Trap: Acting recklessly without understanding risk. Amazon categorizes decisions into Two-Way Doors (reversible) and One-Way Doors (irreversible). Show fast execution on two-way doors.

• Situation: On a Friday afternoon, our primary search indexing pipeline halted due to an unhandled schema change in incoming product metadata, stopping new inventory from surfacing on the storefront.
• Task: The technical lead who authored the ingestion parser was offline on vacation, and standard protocol was to wait for an emergency triage meeting.
• Action: Recognizing this was a reversible Two-Way Door decision, I verified that rolling back the parser deployment would re-enable 98% of valid inventory while queueing the malformed 2% in a Dead Letter Queue (DLQ). I executed the rollback within 8 minutes of detection, set up an alert on the DLQ, and wrote a hotfix script to sanitize the new metadata schema.
• Result: Storefront inventory availability was restored within 10 minutes, preventing an estimated $80,000 in lost revenue. I completed the permanent parser patch and deployed it safely on Monday morning.

10. Frugality

The Trap: Cutting corners on security or testing to save money. Frugality is about resourcefulness and doing more with less infrastructure.

• Situation: As our service scaled to 50 million daily active users, our observability bill for third-party Application Performance Monitoring (APM) and log ingestion surged to over $85,000 per month.
• Task: Management gave our team an objective to cut monitoring costs by 40% without losing visibility during production outages.
• Action: I audited our telemetry traffic and discovered that 75% of our ingested logs were routine HTTP 200 health check confirmations and debug-level trace logs from batch workers. I configured dynamic tail-based sampling: our collectors preserved 100% of error traces (HTTP 4xx and 5xx) and high-latency requests while sampling healthy requests down to 1%.
• Result: Ingested telemetry volume dropped by 68%. Our monthly APM invoice plummeted from $85,000 to $26,000 (saving over $700,000 annually), while our mean time to isolate production anomalies remained unchanged at under 4 minutes.

11. Earn Trust

The Trap: Telling a story where you look like a hero who made no mistakes. Earn Trust requires showing how you take accountability when things go wrong and rebuild credibility through radical transparency.

• Situation: I approved and merged a pull request containing an unindexed database migration that locked our user database table for 14 minutes during peak European business hours, causing widespread service degradation.
• Task: I needed to take ownership of the incident, lead the remediation, and rebuild trust with our infrastructure partners.
• Action: In the post-incident review (Correction of Error document), I did not deflect blame onto the author of the pull request or our automated test suite. I wrote the full post-mortem detailing how my review process failed to simulate schema migrations against table locks at production scale. I implemented automated DDL lock detection in our CI/CD pipeline to block non-concurrent index operations automatically.
• Result: The post-mortem was praised by the Director of Engineering as an example of blameless, high-accountability engineering. The automated CI/CD guardrail prevented three similar table lock incidents over the following six months across the broader department.

12. Dive Deep

The Trap: Stopping at surface metrics like "CPU was high." Dive Deep requires drilling down to thread dumps, memory allocations, kernel parameters, and network packets.

• Situation: Our distributed cache cluster was exhibiting intermittent 200ms latency spikes once every 45 minutes, but CPU and memory utilization remained below 30%.
• Task: Two senior engineers had investigated and dismissed the spikes as inevitable cloud network jitter. I refused to accept that conclusion.
• Action: I attached an eBPF profiler to our production nodes to inspect kernel syscall timings and network socket queues. I traced the latency spikes to an automated background memory defragmentation routine within the Linux kernel (Transparent Huge Pages) that was stalling thread execution for up to 180ms during memory allocation sweeps.
• Result: I disabled Transparent Huge Pages on our cache instances and adjusted kernel virtual memory compaction settings. The periodic 200ms latency spikes disappeared entirely, stabilizing our p99 latency to a consistent 1.8ms.

13. Have Backbone; Disagree and Commit

The Trap: Backing down easily, or conversely, refusing to support a decision after you lost the argument. You must show fierce, data-backed defense of your position, followed by complete operational support once the team decides.

• Situation: My engineering manager and product lead wanted to adopt a proprietary managed third-party orchestration engine for our new workflow automation product to meet an aggressive quarterly launch date.
• Task: I believed that committing to this closed-source vendor introduced massive security compliance risks and astronomical per-execution licensing costs as volume scaled.
• Action: I spent three days creating a detailed technical comparison document outlining vendor lock-in risks, cost-per-execution projections at 5x scale, and an alternative open-source Temporal architecture. I presented my case firmly during two architecture review sessions. Despite my data, leadership decided to proceed with the third-party vendor to guarantee the launch date. Once the decision was finalized, I committed 100%: I took ownership of the vendor SDK integration, wrote our resilience circuit breakers, and delivered the integration a week ahead of schedule.
• Result: The launch succeeded on time. When vendor costs indeed spiked six months later, leadership leveraged my original architectural documentation to migrate seamlessly to Temporal without starting from scratch.

14. Deliver Results

The Trap: Explaining that you worked really hard even though the project failed. Deliver Results is about overcoming unforeseen roadblocks to deliver business outcomes on schedule.

• Situation: Three weeks before our mandated compliance deadline for SOC 2 certification, our primary data encryption library was flagged with a critical zero-day vulnerability, requiring a complete cryptographic migration across 24 distinct microservices.
• Task: We could not postpone the audit without invalidating several multi-million-dollar enterprise contracts.
• Action: I audited our service dependency graph and realized that manual updates across 24 separate services would take 6 weeks. I built an automated AST (Abstract Syntax Tree) codemod script that automatically refactored the deprecated cryptographic calls, updated import references, and bumped dependency versions across all 24 repositories. I organized a 48-hour testing swarm to validate every staging deployment.
• Result: All 24 services were safely patched and deployed to production 4 days before the auditor's review. We achieved clean SOC 2 certification with zero audit exceptions.

15. Strive to Be Earth's Best Employer (Added 2021)

The Trap: Treating this as HR fluff. For engineers, this principle is about engineering sustainability, reducing alert fatigue, and eliminating toxic on-call conditions.

• Situation: On-call engineers on our team were receiving an average of 42 non-actionable alert pages per week, causing severe sleep deprivation, developer burnout, and team turnover.
• Task: I decided to eliminate operational toil and make our on-call rotation sustainable.
• Action: I initiated an "Alert Hygiene" project. I analyzed 60 days of PagerDuty incident logs and categorized alerts by root cause. I silenced 18 redundant threshold alerts, converted 14 informational pages into batched Slack notifications, and authored automated self-healing scripts for the 6 most common transient disk-space and cache-restart issues.
• Result: Weekly on-call alert pages dropped from 42 to 3 per engineer. Team morale rebounded, and our unforced engineering attrition dropped to 0% over the subsequent 18 months.

16. Success and Scale Bring Broad Responsibility (Added 2021)

The Trap: Focusing purely on internal software speed. At scale, every architectural choice has downstream consequences for customer data privacy, ecosystem resilience, and security blast radius.

• Situation: Our data engineering team was designing a behavioral analytics pipeline intended to capture detailed user interaction telemetry across our global marketplace platforms.
• Task: As lead architect on the data review committee, I needed to evaluate the broader implications of this data capture.
• Action: I flagged that while capturing raw IP addresses, user agents, and granular location coordinates was technically legal under our terms of service, it created a massive privacy vulnerability in the event of an internal credential compromise. I authored an architectural standard requiring client-side truncation of IP addresses, differential privacy noise injection on geospatial coordinates, and automated 30-day cryptographic shredding of all raw session metadata.
• Result: The privacy-first architecture was adopted across the entire consumer division. A year later, when regional privacy regulations were tightened, our platforms complied automatically with zero emergency engineering refactoring.

How to Handle Bar Raiser Follow-Up Probes

When an Amazon interviewer asks: "Tell me more about that," they are testing whether your story is real or rehearsed. They will drill three levels deep:

Script for Level 1: Defending Individual Contribution

"To be precise: while my two colleagues focused on frontend UI components, I personally owned the backend distributed locking mechanism. I wrote the Redis Lua scripts to guarantee atomicity, authored the unit tests, and managed the canary deployment in production."

Script for Level 2: Explaining Architectural Trade-Offs

"We actively evaluated Apache Kafka versus AWS SQS for this pipeline. We chose SQS because our throughput requirements were under 5,000 messages per second, and adopting Kafka would have added significant operational management overhead that our small three-person team was not equipped to support."

Script for Level 3: Reflecting on Mistakes and Hindsight

"If I were architecting this system today, I would not use JSON serialization over the wire. Under peak load, CPU time spent on JSON parsing accounted for 22% of our server overhead. I should have implemented Protocol Buffers from Day 1, which we ended up having to migrate to six months later."

Related Interview & Career Guides

Continue preparing for top-tier engineering loops and leveling evaluations:

• Complete STAR Interview Questions & Engineering Framework
• Amazon Software Engineer Salary & Compensation Bands (2026)
• Amazon Interview Response Times: The 2-and-5 Day Rule Decoded
• How to Push Back Against L6 to L5 Downleveling at FAANG
• LeetCode Study Plan & Technical Interview Roadmap
• How to Negotiate Your Tech Offer With a Competing Counteroffer

Frequently Asked Questions

How many Leadership Principles does Amazon have in 2026?

Amazon has 16 Leadership Principles in 2026. In July 2021, Amazon added two new principles: "Strive to be Earth's Best Employer" and "Success and Scale Bring Broad Responsibility." Both are actively assessed, especially for Senior (L5), Staff (L6), and Principal (L7) engineering candidates.

How many STAR stories should I prepare for an Amazon engineering loop?

Prepare 8 to 10 distinct technical STAR stories. Never recycle the same project to answer multiple Leadership Principles across interviewers; the panel cross-references their notes during debrief. Each story must survive three levels of deep follow-up probes.

What is a Bar Raiser at Amazon and can they veto a hire?

A Bar Raiser is an interviewer from a different organization outside the hiring team who acts as an objective evaluator. Their role is to ensure the candidate is better than at least 50% of current Amazon employees at that level. The Bar Raiser holds effective veto power; a "Strong No Hire" from them blocks the hire even if the hiring manager is inclined.

How does Amazon debrief scoring work after the interview loop?

Every interviewer must submit written feedback and an independent rating (Strong Hire, Inclined, Not Inclined, or Strong No Hire) within 24 to 48 hours before seeing peer notes. During the debrief meeting, the Bar Raiser synthesizes behavioral evidence across all assigned Leadership Principles to reach a consensus decision.

What is the 10-60-20 STAR formula for Amazon interviews?

The 10-60-20 formula dictates your time allocation: 10% on Situation (30 seconds of context), 10% on Task (30 seconds on personal responsibility), 60% on Action (2 to 3 minutes detailing your individual technical decisions and trade-offs), and 20% on Result (1 minute of quantified engineering impact).

Why do Amazon interviewers penalize saying "we" instead of "I"?

Amazon evaluates individual ownership, not team accomplishments. Interviewers are explicitly trained to flag team-centric language like "we built" or "we resolved" as a lack of personal contribution. In the Action phase, every technical choice, design review debate, and pull request must use "I."

How is an L7 Principal Engineer evaluated differently than an L4 or L5 SDE?

While L4 and L5 engineers are evaluated on single-system delivery, code quality, and service reliability, Principal Engineers (L7) are evaluated on cross-organizational influence, multi-year architectural roadmaps, operational blast-radius reduction, and setting technical standards across dozens of teams.

What happens if an Amazon interviewer cuts you off during your STAR answer?

If an interviewer interrupts you, it is an operational signal that you are spending too much time on background context (Situation) and they are pulling you into the Action phase. Acknowledge the interruption smoothly, pivot directly to what you personally designed or executed, and state the quantified result.