Amazon Leadership Principles Interview Guide | Sample Questions

tl;dr

This is how candidates typically prep for an Amazon Leadership Principles (LP) interview—it might sound like common knowledge. To prep for the LPs, you need to:

• Start by looking at Amazon’s interview questions
• Study all of Amazon’s LPs
• Use the STAR format to create your answers
• Prepare stories ~2 minutes in length
• In an interview, guess which LP you’re being assessed on

🚨 But none of that is true. 

After personally coaching 50+ Amazon candidates, analyzing dozens of LP interviews, and interviewing half a dozen Bar Raisers, including Ethan Evans (former Amazon VP who helped create the updated LPs), there is clearly a more effective strategy to prep for the LP interview. (It’s not recommended, but if you’re deadset on jumping straight to LP questions, start with our database of 170+ LP questions.)

Here is the cheatsheet of our findings (and what you can expect to get out of this guide):

✅ This guide is for candidates at and above the senior level in technical roles. However, others will also find value in it. 

Background 

The Amazon LP interview is the hardest behavioral screen in tech. 

You could throw Netflix, Apple, and maybe a few others into the conversation, but for the sheer force of standardization across all interviewers, Amazon is the champ. Another company might have a one-off behavioral round that’s more difficult. Yet if you compare 100 behavioral rounds between Amazon and any of the most popular tech companies, the final decision won’t be close. 

Amazon’s values: The Leadership Principles

Notice how Amazon’s values don’t look like your typical company values. They contain more specificity and paradox. 

Thanks to accelerateco for the picture. 

The outliers in Amazon's values might sound weird (e.g. “Have Backbone; Disagree and Commit” and “Are Right, A Lot); compared to other companies, these values are more specific. Logically, the LP interview is value-based and calls for a more specific kind of prep. 

What is the LP interview?

The Leadership Principles interview is Amazon’s version of a behavioral and culture fit assessment. 

Technically, there is no such thing as an “LP round.” Instead, Amazon assesses you on the LPs throughout the entire interview loop. In other words, expect a few LP questions in every Amazon round (regardless of the round’s topic). Additionally, some rounds (specifically at the onsite interview stage) will concentrate solely on LPs. 

Why the Leadership Principles make tough interviews

Out of all the FAANG companies, Amazon has the second-most thorough interview training (beat only by Facebook). The level of standardization across Amazon interviewers is extremely high for a behavioral round, which is inherently subjective. Still, their standardized process has removed more subjectivity from this round than any other company. 

At other FAANG companies, like Google, behavioral rounds can feel casual—often just checking for red flags. By contrast, Amazon interviewers systematically probe the Leadership Principles, creating a more rigorous experience.

6 common LP Myths

Myth 1: Have Backbone; Disagree and Commit is about forcing people to do things your way

This might be the most misunderstood LP, maybe because it’s the only LP that contains three steps: 

1. If you disagree, speak up. 
2. If the other person doesn’t accept what you say, be willing to fight for what you believe and back it up with data. 
3. Once the decision is made, whether or not it’s what you wanted, get behind the decision and try to make it successful. 

Myth 2: Learn and be Curious is only about what you’ve learned as an individual 

The truth is, it’s about what you’ve taught others. Reframe: “If you leave that position, what do you leave behind for that team (or org or company)?” It’s not about simply learning a new programming language. It’s about learning a new programming language, then coaching up a coworker or creating documentation for it. 

Myth 3: Hire and Develop the Best only applies to hiring managers

Point of fact, this LP is about developing skills in other people. Even people you didn’t hire. For example, you can demonstrate a signal for this LP by developing a mentoring or training plan. 

Myth 4: Think Big is about bigger numbers and significant lofty thoughts

“Think Big” doesn’t mean think big—it means think creatively. In other words, make decisions not just based on what you're told but on what you figure out.

Myth 5: Are Right, A Lot means others are expected to obey their leader blindly 

If you are a leader, you don’t deserve less pushback because of your position of authority; if you’re a leader, you need to do the work to be right a lot.

Myth 6: Frugality means you should say no to all expenses

What this LP is really about is spending money carefully. Especially when it comes to software development, don't reinvent the wheel. Don’t build something entirely new if you can be resourceful; use building blocks that have already been built. 

How to prep: 4-step framework

1. Focus on your top 3 projects
2. Bucket your projects
3. Use the cheat sheet 
4. Watch out for dealbreakers, red flags, and risks

1. Focus on your top 3 projects

Think for a moment about the most important work you’ve done, and the biggest decisions you have ever made in a work setting. The decisions with the highest stakes. The most impact. Ask yourself: “What are the top three things I have done in my career?” 

For every full LP round, your optimal solution is to highlight the 3 best projects you’ve been involved in. Like a politician who, regardless of the interview they’re in, finds a way to speak about the fact that they are going to fix the economy. The trick is to do that without being too scripted and without forcing a story where it doesn’t belong. 

2. Bucket your projects

Now, assign each of your top three projects to a bucket. (You need at least one project for each bucket, though two is better. And a single project can be assigned to multiple buckets.) 

Buckets

Bucket #1: Productivity

Definition: This project is exceptional because of the things you got done for the business and those customers you’re obsessed with. Your most significant achievements probably fit into this category. 

Bucket #2: Failure

Definition: This is where you made mistakes, and, more importantly, learned lessons. Times you received negative feedback go here. 

Bucket #3: Conflict

Definition: These projects involved disagreements or conflicts, regardless of which side “won.”

Get to know your projects

Talk through your past projects (brain dump, talk out loud and record it, do mock interviews) until you consistently check each box under each bucket. Not in your initial answer, but over the course of a 5–10 minute conversation. 

Bucket #1: Productivity 

☐ What was the technology problem you were trying to solve? What type of problem was it (scale, resiliency, etc.)?
☐ What was the customer (or business) problem you were trying to solve?
☐ Did this problem have real stakes? How was it complex?
☐ What did you do about the problem? What data did you dig up to test your hypotheses?
☐ What was the greatest challenge you faced in finding your solution? Why was it hard? Was there a “primal” constraint? (Usually limited resources or time.) Did you have conflicting or limited information?
☐ What was your solution? What were the overengineered solutions you could have chosen but didn’t?
☐ What was the outcome? And what was the impact of that outcome?

Bucket #2: Failure

☐ What was the mistake?
☐ Were you upfront about admitting you made a mistake? 
☐ Did this mistake have real consequences? (Reputational risk, losing an important customer, etc.)
☐ Was this mistake recent? (In the past couple of years, ideally.)
☐ What was your initial reaction to the mistake? (It’s okay if your initial reaction isn’t something to be proud of; this way, you can demonstrate growth.) What was your response after you got your bearings?
☐ Did you hold yourself accountable for your part?
☐ Did you communicate what you were accountable for? (If necessary, did you make leadership aware?)
☐ What would you do differently next time (if necessary)? 
☐ What did you do to ensure this wouldn’t happen again?

Bucket #3: Conflict

☐ What was the conflict? 
☐ Did you demonstrate an understanding of the other side? 
☐ What did you do to mitigate the potential concerns you foresaw the other side would have? 
☐ Did you collect objective evidence to back up your case?
☐ How did you try to solve the conflict?
☐ Were you convinced? Why or why not? 
☐ Did you escalate? If yes, did you do enough on your own before you escalated? 
☐ What was the outcome? How did you communicate the outcome with the other side (and, if necessary, with leadership)?
☐ What did you learn from this experience?

The key to conflict stories 

Amazonians don’t care if you win or lose. They care that you tried, got some data, made a good case (or at least prepared to), and came to a resolution so you could keep being productive. Show them you worked to understand the other side’s point of view, and that you tried to mitigate friction so you could work together. You can do that without going into a meeting and arguing with that person. 

“Escalation” is not a bad word at Amazon. Amazonians don’t shy away from it. Escalations can happen back and forth, and it’s seen as acceptable—even welcomed. As long as you’ve done what’s in your power (and still didn’t reach a solution), they believe the best next step is an escalation. Escalate early and often, as long as you’ve done your due diligence. 

3. Use the cheat sheet 

Strategies for your approach: 

• Forget about matching your stories to specific LPs or specific questions; focus instead on showcasing your biggest projects and getting to know them inside and out.
• Boil your projects down to one-liners so you can practice giving the bottom line up front. It won’t be a complete answer, but it’s the best possible start to one. 
• If your projects lack scale, get creative to convey their complexities (number of dependencies, working on a novel problem, risking your reputation, etc.)
• Amazon has a bias towards system resiliencies because those are the failure points a customer sees. Tell the hiring team about times you improved the resiliency of a system, for example, by decreasing the number of 5xx errors. (They also like to hear about scalability, performance, and security. But nothing does it for them like resiliency.)
• Amazon prefers mechanisms over best intentions. A mechanism is a repeatable process that you put in place to help ensure a good outcome. For example, if you add a new safety check to your regular deployment checklist after a particularly bad customer-impacting outage. That’s better than the best intention of "After that outage, we all tried harder to make sure we didn't do X again.”
• Rearchitecting an entire system at Amazon’s scale is a huge risk (and several years of work); instead of telling those stories, think of times you were resourceful and used preexisting building blocks. 
• Proactively mention taking on job responsibilities that weren’t officially under your role.
• When you talk about conflicts, they need to be recent, and they need to have real stakes. Counterintuitively, even if you only anticipated an argument (but didn’t have one) in a previous role, that can still count. Ideally, for more senior candidates, have examples of conflicts where a) they convinced you, b) you convinced them, c) you argue up the org chart, and d) you argue down or across the org chart.
• Give extra time to the trickiest challenges you faced in previous projects. How hard was it to figure out what to do? If it was hard, you want to play this up. If it was hard to develop a hypothesis or involved a lot of experimentation, focus on those challenges and how difficult they were.

Tactics for every answer: 

• Unless you are absolutely certain of what you were asked, clarify what they’d like you to discuss before diving in. For example, “You want me to talk about conflicting priorities?” 
• Don’t unleash entire rehearsed answers on an initial question. Most questions can be answered in about 15–30 seconds. 
• Focus 80% of your words on your specific, individual contribution.
• Mention impact. Three ways to demonstrate impact:
  • A dollar amount of revenue generated (or supported) or cost savings.
  • A metric such as “increased retention by Y%.”
  • An anecdote, such as “This was key to win (or maintain) an important customer.”
• Mention a keyword from their question in your answer's first couple of words. For example, if they ask about conflict, begin with, “The conflict was with a Principal Engineer about an internal dependency.”
• If there was any doubt you understood their question, at the end of your answer, ask (in varying forms): “Did I answer your question?”
• As you answer, remember that L4s execute with guidance and support. L5s Execute mostly independently. L6 candidates influence their team (and a bit outside of it), and L7 candidates are cross-functional specialists who influence the org. Your answers should reflect the expectations of the level you’re applying to. 

The differences between the levels 

If your projects don’t convey the right amount of scope and complexity, you will get downleveled or rejected. The difference in scope between the levels:

• L4 and L5 = responsible for their own work
• L6 = influencing their team and a little bit outside of it
• L7 = influencing across teams (their org)

4. Avoid dealbreakers, red flags, and risks

Dealbreakers: These candidates fail instantly. 

1. You’re a candidate who clearly didn’t prepare for the LPs. 
2. You got a negative score on “Earn Trust or Have Backbone; Disagree and Commit.” This can blow your chances even if you did well on all other LPs. Candidates who can’t tell any stories about disagreements are just as much of a dealbreaker as being a jerk. 

Red flags: Not as bad as a dealbreaker, but results in a significant loss of points. 

1. Giving too much detail in your initial answer.
2. You don’t actually answer the question they asked. (Usually, this means you gave an obviously canned response. Or you misunderstood the question.)
3. Focusing too much on what everyone else did (as opposed to what you did).
4. No metrics or impact are mentioned in your answer. 
5. Saying, “I don’t have an example for that,” for more than 1–2 questions in one round.
6. Focusing on the unimportant details of a conflict. Trying to prove who was right, most commonly. Or burying the lede and not clearly stating what the conflict was. 
7. Only disagreeing across or down the org chart (for L7s and up).
8. Too low of stakes for your disagreements. 

Risks: When committed in bunches, these are as deflating as a red flag. 

1. Overreliance on the STAR framework. Just as this former Amazon Principal Engineer says, STAR is a sub-optimal format for designing answers. The more effective use case for STAR is to use it as a filter after your stories are made. 
2. Attempting to guess which LP a question is asking about.
3. Mentioning revenue or cost savings under $1,000,000.
4. Speaking about a highly manual process and not proactively sharing why you didn’t automate it. The most likely follow-up question is, “Why wouldn’t you automate that?”
5. Discussing a project you completed in 1 sprint, because that implies the project wasn’t complex enough or didn’t have enough scope. 
6. Talking about a project from over 3–4 years ago. Amazonians have a bias for recency. 
7. Only having conflicts down or across the org chart (for L6 candidates).
8. A project where you deliver on a tight timeline and deliver with super high quality can sound suspicious. You usually can’t do both at the same time.
9. Rearchitecting an entire system. 

Last notes on how not to practice 

Do not write your story down for a “Deliver Results question,” practice that same story, and then recite it word-for-word in an interview. This is one of the chief causes of spectacular failures in this interview. 

Do not get overly attached to your answers; don’t treat them like a “script.” Being “too scripted” is a peeve of most interviewers and puts you at the mercy of tricky questions. There might not be a faster way to lose credibility than to unleash an unwieldy answer to the wrong question. 

LP questions you can practice with

Hopefully, by now, you see that the real success lies not in matching your projects to LPs or questions, but in showcasing your top projects and knowing your projects inside and out. With that solid foundation, you’re ready to practice with specific questions. Here is a list of 10 common LP questions. If you want more, study our database of 100+ Amazon LP questions.

1. Tell me about a time you disagreed with someone and how you resolved it.
2. Tell me about the most challenging technical problem you’ve worked on.
3. Tell me about a time when you had to use data to make a decision.
4. Tell me about a time when you had to make a quick call on something important. What’d you do? 
5. Tell me about a time you got a piece of critical or negative feedback.
6. Tell me about a time you came up with a simple solution for a complex problem. 
7. Tell me about a time when you solved pain points for customers.
8. Tell me about a time you made a mistake. 
9. Tell me about a time when you made short-term sacrifices for long-term gains.
10. Describe a challenging project you worked on and what made it difficult.

Outro

Forget about what they’re assessing you on and simply focus on answering their questions. Highlight your most impactful work. Bucket your projects. Practice holistically checking the boxes they look for. Avoid the dealbreakers, red flags, and risks; implement the cheat sheet. 

Paradoxically for an interview guide, we are telling you that at the LP interview, you actually need to throw away all your prep and just have a conversation. Hear the question, clarify the question, and answer the question. And if you practiced the way we outlined in this guide, your brain will do the rest automatically.