interviewing.io

The Amazon Leadership Principles Interview Guide for Software Engineers

How to not suck at Amazon Leadership Principles

Table of Contents

  1. Creating the Amazon Leadership Principles guide
    1. How to use the Amazon Leadership Principles guide
      1. Part 1: The Theory of Amazon Leadership Principles
        1. Leadership Principles (LPs), and how they relate to the Amazon behavioral interview
        2. Reframing the Amazon Leadership Principles interview
        3. High-level strategy to frame your Leadership Principles approach
      2. Part 2: What to expect, what to avoid, and what to do during an Amazon Leadership Principles interview
        1. What to expect
        2. What to avoid
        3. What to do
        4. How to practice for Leadership Principles
      3. Amazon Leadership Principles interview question examples

        Creating the Amazon Leadership Principles guide

        The Amazon Leadership Principles interview is intimidating—but it doesn't have to be! We created this guide to demystify the interview process, provide you with the knowledge you'll need to practice effectively, and simplify the 16 Leadership Principles to help you succeed. Let us teach you the best way to practice, so you can crush the real thing.

        About interviewing.io

        interviewing.io is a mock interview practice platform. In our lifetime we've hosted close to 100K mock interviews, conducted primarily by senior engineers from FAANG.

        We have the recordings from these mock interviews, as well as post-interview feedback and outcomes, which lets us perform some cool and useful analysis!

        Best of all, interviewing.io lets you book anonymous mock interviews with senior engineers from companies like Amazon, Apple, Facebook, Google, and many more.
        YouTube: Watch “How interviewing.io Helps Engineers Land Jobs”
        Though most of the interviews we've hosted have focused on algorithms/data structures or systems design, about a year ago, we started offering other types of practice as well, including Amazon-specific behavioral interviews, and we've hosted close to 500 Amazon behavioral interviews to date.

        How to use the Amazon Leadership Principles guide

        We intentionally structured this guide as two separate parts. Part 1 explores questions, discusses high-level strategies, and gives you an overview of the whole case. In Part 2, you will learn what actions to take, and we'll provide you with a detailed plan so you'll know exactly what to do to excel during the interview. Where you start reading depends on what you want.If you're interviewing at Amazon tomorrow, don't panic—just jump to Part 2 : What to expect, what to avoid, and what to do during an Amazon Leadership Principles interview. Otherwise, begin with Part 1 to gain the foundational knowledge that will help you practice most effectively.

        What Amazon Likes

        • Direct Challenges
        • Showing customer obsession (all the time)
        • Big losses
        • No answer (more so than a bad answer)
        • Stories that go in a perfect full circle
        VS

        What Amazon Dislikes

        • Conflict rabbit holes
        • Not enough impact and metrics
        • Not enough focus on individual contribution
        • Saying LPs out loud
        • Misunderstanding have backbone; Disagree and commit
        And to learn more about the behavioral interview process and ensure our conclusions were on track, we spoke with ten former Amazon engineers (who also happen to be interviewers at interviewing.io). All of the quotes from engineers in this guide come from those conversations.

        With that being said, our insight does have some limitations. It's worth noting, for example, that the majority of interviews we looked at for this project were with L6/SDE III candidates, so our data set is skewed toward senior engineers. (For reference, an L6/SDE III at Amazon is roughly equivalent to an L5/Sr. SWE at Google.)
        PART 1:

        The Theory of Amazon Leadership Principles

        Leadership Principles (LPs), and how they relate to the Amazon behavioral interview

        In a nutshell, Leadership Principles (LPs) are the 16 values Amazon cares the most about. Here are the 16 LPs:

        Amazon's Leadership Principles

        Amazon's interview process involves a) behavioral rounds, and b) technical rounds with a few behavioral questions thrown in. The behavioral questions will all focus on your work history. Importantly, Amazon will decide whether or not to hire you and how much responsibility to give you based partly on how well you demonstrate their Leadership Principles when you discuss your work history.

        What Amazon assesses is consistent between interviewers. Each interviewer will be assigned 1-3 LPs to look for when interviewing you. They're searching for signal on whether you: meet the bar, raise the bar, or are below the bar (for their assigned LPs).

        But how Amazon conducts the behavioral round varies widely. Our research has shown that if you were to observe sessions of 10 different LP interviewers, you would discover that each interviewer has their own way of determining a candidate's fit. One interviewer might ask more questions on fewer topics, while another interviewer may do the opposite. Complicating matters, upon observing the same behavior, different interviewers will likely perceive different signals. Notably, there is no consensus on what makes a good answer good.
        "There is no clear rubric for what type of answer ‘meets or raises the bar.' The evaluation is subjective, and it relies on the interviewer's interpretation of the problem and solution."interviewing.io interviewer from Amazon
        Although you might find this degree of uncertainty intimidating, we'll show you how you can actually use this uncertainty to your advantage and score additional points during your interview.

        Reframing the Amazon Leadership Principles interview

        Many candidates treat their interview like a standardized test. But doing so is a serious and costly mistake.

        A standardized test is unimpressionable, fixed, and objective. Information only flows one way, any modification of structure or content is rejected, and correct answers aren't debatable. But, as we showed above, the individualized approach of Amazon's interviewers makes it clear: Amazon's behavioral round is not a standardized test—it's a game.

        A game is malleable, dynamic, and subjective. In other words, the behavioral interview is a lot like Calvinball. In Calvinball, “While the objective of the game is to win, there is no real way to determine what winning is” (source). That means that you can change the rules. You can mold the field of play to fit your strengths. You're limited solely by your imagination.

        These types of games are influenced by cognitive biases, configurable to your advantage, and filled with judgment calls. But, more than anything else, the biggest difference between a standardized test and a game is that the latter involves your counterpart (the interviewer) making up the rules as they go along—just like you.
        "25% of SDEs who pass the technical bar are disqualified due to behavioral concerns."interviewing.io interviewer from Amazon

        Why preparation matters

        Many engineers wrongly assume that they don't need to prepare for a behavioral interview. They believe they can wing it by simply talking about their past experience because they assume it's something they're already intimately familiar with. However, winging it won't cut it in Amazon's behavioral interview—it's a particularly common failure pattern we see on our platform.

        Amazon is known for its competitive workplace culture, and most Amazonians seem to get satisfaction from making a behavioral round intense, much more so than most interviewers at other companies. Unprepared candidates are prone to get rattled by the somewhat confrontational, challenging style of these interviewers, causing their performance to suffer as a result.

        To avoid that same fate and actually excel in the interview, you'll need to learn about what Amazon cares about (the LPs) and discover how to respond to their tricky questions without getting flustered. Do that, and you'll increase your odds of both getting hired and receiving a higher level of responsibility.
        "I wish more candidates would prepare well in advance for our behavioral questions. I wish they knew the questions' patterns and were prepared to speak about their experience in an effective way."interviewing.io interviewer from Amazon

        High-level strategy to frame your Leadership Principles approach

        In this section, we'll teach you a strategy that will increase your odds of success while lowering your stress. We think it's important to explain why you should use this strategy and how we analyzed and bucketed these LPs to maximize your hit rate.

        The status quo on how to show signal for Leadership Principles

        When it comes to preparing for Amazon's interview, one popular strategy is to guess which LP a question is asking about before answering the question. Unfortunately, there are 16 different LPs to keep track of, so your odds of guessing correctly are low; your interviewer may ask tricky, confusing, or challenging questions that are designed to push back, probe, or catch you off guard; and you can't predict if the interviewer will even detect signal of the LP you're trying to convey.

        There has to be a simpler way to crack this, and we think we've found it.

        What all 16 Leadership Principles share: customer obsession

        If we can determine what concepts these LPs have in common, then you can simply show signal for a bucket of LPs instead of attempting to laser focus your answer on one LP. This will make it easier for you to prepare for the interview and also increase your odds of success.

        We spent a lot of time analyzing the 16 LPs, identifying their shared themes and placing them into buckets. Searching for the most efficient and effective way to group the LPs, we discovered that every LP has one common denominator: customer obsession. This is Amazon's favorite value. It's their north star. Without customer obsession, Amazon wouldn't be Amazon.

        But if all 16 LPs can be reduced down to one concept, then what's the point of following the status quo and guessing which LP a question is asking about? Because, technically, wouldn't the answer be customer obsession every time?

        Yes, and that's our point. Though it may be tempting to do otherwise, you should ignore the urge to guess which specific LP lies beneath a question. It's more likely to hurt than it is to help.

        Instead, broadcast the idea that you are obsessed with delighting customers. Signal this idea early and often; make this your new default system. In such a generalized interview format with so much subjectivity, you want to cover as wide of a surface area as possible. Demonstrating customer obsession is the closest thing we've found to a cheat code.
        PART 2:

        What to expect, what to avoid, and what to do during an Amazon Leadership Principles interview

        Now that we've explained why you should condense the LPs into a single bucket (customer obsession), it's time to learn everything you need to know in order to craft your own ideal answers.

        What to expect when answering questions about Amazon Leadership Principles

        Interviewers directly challenging candidates

        Here's an excerpt from a tech lead interview at Amazon. Let's take a look at how it flows.
        QUESTION:
        "How do you make sure you're focused on the right deliverables when you have several competing priorities?"
        1ST FOLLOW-UP QUESTION:
        "Can you tell me about a time when you did not manage priorities and something fell through the cracks?"
        2ND FOLLOW-UP QUESTION:
        "What could you have done better?"
        3RD FOLLOW-UP QUESTION:
        "I don't think you answered the question. I think you're answering a more generic question. I'm asking you to tell me about a time when your process for competing priorities didn't work."
        The topic of the initial Question is ambiguous: there's no known optimal solution for managing priorities. The 1st Follow-up Question is about failure. Essentially, so far the interviewer has said, “Hey, give me your philosophy on a subject for which there's no consensus,” followed by “Okay, now tell me how that philosophy of yours is imperfect.” That's a direct challenge.

        The 2nd Follow-up Question is also about failure. And the 3rd Follow-up Question is another direct challenge. In fact, you might never see a stronger direct challenge than the 3rd Follow-up Question.

        This is classic Amazon. Ambiguity and failure can be intimidating enough on their own, but Amazon doesn't stop there. They turn up the heat to test your ability to handle pressure.

        What to avoid when answering Amazon interview questions

        In addition to learning what to expect in an interview, it's important to identify common mistakes that candidates make so you can avoid them in your own interview. Here, we will focus on the mistakes themselves.

        Most Common Mistakes in Terms of Content

        40%30%25%5%40%Not enough impact or metrics30%Falling down rabbit holeswhen asked about conflict25%Not focusing on individual contribution5%Saying LPs out loud
        In addition to learning what to expect in an interview, it's important to identify common mistakes that candidates make so you can avoid them in your own interview. Here, we will focus on the mistakes themselves.
        MISTAKE #1

        Not enough impact or metrics

        The most common critical feedback given by interviewers is either: “It would have been better if you described more impact,” or “It would have been better if you mentioned more metrics.”

        Amazon likes business and scale. An answer without impact means Amazon can't get a read on your business acumen. An answer without metrics gives Amazon no way to determine scale.

        One reason candidates don't mention impact or metrics is because they think they can only use impact or metrics that are accurate with 100% certainty. Lastly, one additional reason people fail to include impact or metrics is because they simply aren't sure how to find them. (If you want to learn how to find impact and metrics right now, then jump to Step 1 of How to Practice for LP.)

        MISTAKE #2

        Falling down rabbit holes when asked about conflict

        Candidates frequently get tripped up when asked questions about conflict. We can't tell you how to avoid every possible pitfall, but we can tell you how to avoid the most common one: Trying to prove that you were right.

        Two things that interviewers absolutely do not want to hear when you're speaking about conflict:

        Why your X approach was better than your colleague's Y approach.

        The minute details of your X approach and of your colleague's Y approach.

        This is where many people get stuck. It doesn't matter who had the better technical approach. Don't try to justify to the interviewer that you were right and your colleague was wrong. Avoid this trap.
        You may have spent a lot of time thinking about this, but that doesn't mean you need to share a lot about it. Once again, your goal is not to prove that you were correct. Therefore, you shouldn't speak at length about why a proxy server was the best solution or explain the usability drawbacks of changing the hosting environment. Less is more in this case. If they want more detail, they'll ask about it in their follow-up questions.Some of the other common ways people fail during questions about conflict: rambling for five minutes before describing the actual conflict, talking about a conflict from 10 years ago, focusing on the intensity of the conflict instead of what happened during the conflict, and speaking about a conflict where the topic seems trivial for someone at their level.
        MISTAKE #3

        Not focusing on individual contribution

        "When talking about your projects, most of your words should be about ‘I' not ‘We.' Your answer should mainly be about your individual contribution."interviewing.io interviewer from Amazon
        According to our research, the third most common reason engineers fail interviews is a lack of focus on their individual contributions when discussing their work history. Typical feedback from interviewers looked like this: “I got an understanding of what the project was about and what work was involved in general, but I couldn't really get a sense of what you did.”

        Again, Amazonian and non-Amazonian interviewers both deduct points when a candidate fails to focus on their individual contribution. But some speculate that Amazonians dock more points than other companies when someone misses the mark here. Don't get caught up in an in-depth walk-through of how the technology works or the specific structure of the business units or the intricacies of what everybody else was doing. Say “I”!
        MISTAKE #4

        Saying Leadership Principles out loud

        If you're the candidate, don't recite LPs out loud. It sounds clunky and unnatural.

        Not Ok

        • Saying “customer obsession”
        • Saying “deliver results”
        VS

        Ok

        • Saying “delighting users is important”
        • Saying “get stuff done”
        Takeaway: you can riff, but don't “copy and paste.”
        We've focused so far on the most common reasons candidates lose points in an Amazon behavioral interview, but now let's take a look at strategies you can use to make a positive impact.

        What to do

        Beat the drum with customer obsession—the most important Leadership Principle

        As we mentioned earlier, all of the LPs have one common denominator: customer obsession. It's never a bad time to demonstrate customer obsession; to borrow a quote from Wedding Crashers: “It's like pizza, baby—it's good no matter what!

        To make your answers stronger, you can show signal for customer obsession in places where it doesn't seem to apply. Take this question, for example: “Tell me about a time you had a disagreement with a colleague or a manager. What was the situation? How did you resolve it?”

        ANSWER AWithout customer obsession framing

        • I had to organize and refactor the codebase. And I thought object-oriented programming was the best approach. But one of my teammates did not buy in. I tried to explain the benefits but did not sway him. I wanted to get the work done, so I ended up going ahead with the approach he proposed. At the end of the day, delivering the feature was more important than proving my point to stick with the object-oriented approach. I made peace with my teammate and went ahead with his approach.
        VS

        ANSWER AWith customer obsession framing

        • I had to reorganize the codebase and refactor the codebase. And I thought object-oriented programming was the best approach. But my teammate didn't buy in. For the sake of pushing something to prod quicker, we ended up going with his approach. But looking back on it, I wish I would have fought more for the object-oriented approach, and the reason is because user experience is really important to me. If we had the codebase nicely structured with object-oriented design and patterns and hierarchy, it'd make it way easier to maintain and more robust and less buggy. So later on we could develop cool new features for customers and push them out quicker.
        Data collected from a representative sample of Amazon behavioral interviews showed us what to do and what to avoid during an interview.

        No answer is often better than a bad answer

        It's all right to say: “I don't have an answer for that,” or “I can't think of an example for this question.” In fact, interviewers don't expect you to have an answer for every single question they ask. Unless it's a question your interviewer thinks is insanely common, you're not going to lose points for passing on one question. Obviously, you don't want to dodge four questions in a row. But, overall, no answer is better than a bad answer.
        "It's better to share no example than a bar-lowering example. For instance, if the interviewer asks you to share a time you ‘Insisted on the Highest Standards,' and you talk about code formatting one source file, that is almost definitely a negative mark against you. It would be better to share nothing at all."interviewing.io interviewer from Amazon

        The most misunderstood Amazon leadership principle

        Have backbone; disagree and commit is not about making people do it your way. This is the most misunderstood LP. It's easy to over-focus on the competitive traits Amazon likes; determined to show they're a good fit for Amazon, candidates seem to spin their past work history to make it seem like they're ultra-competitive.

        If it's impossible to do it your way, are you able to go ahead with someone else's plan? Or do you block? If it's impossible to do it your way, accommodating a conflicting idea after you've clearly asserted your point is perfectly reasonable. To showcase this in an interview, you might describe how you told your colleague:
        "Hey, I don't agree. And I don't agree for these reasons. I think it's not going to work. However, for the sake of getting the work done, I'm on board. And down the road, if things aren't going as planned, then we can circle back and revisit this discussion."

        Follow four rules when speaking about conflict

        RULE #1Clearly articulate the conflict in the first few seconds of your answer.Don't make your interviewer wait. After you share the conflict, pause briefly to let it sink in.
        EXAMPLE:"In my current role, a conflict occurred over choosing how to integrate a third-party software. The conflict was: my manager and I couldn't agree on an approach."
        RULE #2Make sure the topic of a conflict is relevant to your level.A topic relevant to a junior engineer is something like choosing variable names. For senior engineers, it'd be about something more significant such as deciding how to design the architecture or choosing one database over another.RULE #3Choose actual conflicts, not potential conflicts.A conflict is a disagreement drawn out over time. If there wasn't much discussion about it or time didn't pass while it persisted, then it probably wasn't a conflict. If this is the case, it was more of a “potential conflict that got resolved quickly.” If it wasn't a conflict, then don't position it as one.

        Example of a potential conflict that got resolved quickly

        • “They said X. I said Y. And then they said, ‘Oh, you're right. Actually, Y is better.' And then we did Y.”
        VS

        Example of an actual conflict

        • “They said X. I said Y. And then time passed. They still said X and I still said Y. So, I did research on X and Y. More time passes. I showed this research to get buy-in from some Important People. Then I showed my research to the People Who Said X. More time passes. The People Who Said X weren't convinced until Z happened. Then the People Who Said X got on board and said Y.”
        RULE #4Focus on what happened and stick to the facts.Define the conflict, describe how the conflict was resolved, share the steps you took to resolve it, and state the outcome.
        EXAMPLE:"One conflict I had with my manager was about integrating a third-party API. They thought this service would improve performance. My research showed it improved performance marginally but complicated maintenance significantly. After gaining support from the team lead, I walked my manager through the data flows. They weren't convinced; however, they were more open to the idea. At the urging of myself and the team lead, the manager took it to one of their stakeholders who agreed that the long-term maintenance costs were too high to justify using this service. This led to us not integrating the third-party service that had been proposed."

        Share experiences where you took a big loss

        Part of the definition of earn trust says that Amazon wants leaders who are “vocally self-critical, even when doing so is awkward or embarrassing,” so don't be afraid of telling Amazon how you've struck out swinging for the fences. You're encouraged to highlight the benefit that getting this “win” would have brought to your team. And, to give you an idea of the big scale losses they want to hear about, you can talk about failures which resulted in a losing a contract, losing future business, or losing a lot of money.

        At the end of an interview, the questions the candidate asks the interviewer are an opportunity to show signal

        Great candidates demonstrate signal in places most candidates might overlook, such as the questions they ask the interviewer when wrapping up.
        Question from the candidate:"Let's say you have a user who used to use the Alexa services when they were a new user, but now they don't use the Alexa services anymore. How do you collect the data to understand what went wrong, so you can improve user experience? Most users are going to ignore surveys, so how do you learn about stuff like what features they didn't like?"
        By framing it around user experience, this question broadcasts customer obsession. It's crucial to take advantage of every opportunity to broadcast signal, so don't ignore the importance of asking questions in a strategic way.

        How to practice for a Leadership Principles interview

        How most candidates practice for Leadership Principles

        An average candidate will go online, get a list of questions, immediately start typing answers to the questions, and maybe get some feedback from friends.

        The primary error here is implementing a solution before understanding the problem. Another error here is the lack of a robust QA process between the initial answer you type out and the answers you say in an interview. What are the chances you got it right the first time? What are the odds that your original answer left a bunch of data unsaid? And what if the data you're leaving behind is better than what you wrote down on your first draft?

        Another mistake is that friends often go easy on you and frequently lack the knowledge or skill to give you actionable feedback. When learning from friends, the best case scenario is you learn less than you should, and the worst case is you learn the wrong stuff entirely.

        Six steps to prepare for Amazon Leadership Principles so you can beat the game

        1. Extract the raw data
        2. Frame the data
        3. Iterate
        4. Refine the stuff that works
        5. Go from good to great
        6. adopt the Amazon mindset

        1
        Extract the raw data

        Approach the raw data extraction like a brain dumpA brain dump is “a complete transfer of accessible knowledge about a particular subject from your brain to some other storage medium, such as paper or your computer's hard drive” (Source). Don't worry yet about the quality of what you extract, and don't focus too much on how it all sounds. Your goal is just to get everything written/typed out.
        Prepare for follow-up questions.For more than 40 years the STAR framework has remained the de facto standard method for structuring answers to behavioral questions. STAR doesn't protect you from an ornery engineer drilling down for 15 minutes on some obscure detail about a project you did two years ago. So, how do you prepare for follow-up questions? Grill yourself until you've extracted enough data. You can either spend a reasonable amount of time grilling yourself before the interview, or you can spend an unreasonable amount of time getting grilled during the interview.
        "Interviewers may spend 10-15 minutes on a single point, asking multiple follow-up questions and going deep into the point."interviewing.io interviewer from Amazon

        Self Reflection

        For each project you've worked on in the past few years, ask yourself these questions:
        What business problem was this project supposed to solve?
        What were the greatest technical challenges? (Usually the more interesting ones are the ones you didn't expect)
        What approach did you take?
        What are the drawbacks to the approach you chose?
        What alternative approaches did you consider?
        How did you compare the approaches?
        What tradeoffs did you consider?
        How did you profile them?
        How did you compare scalability for each?
        What was your vision for how each technology would evolve over time?
        What were the functional challenges?
        Did you have to do something faster than usual?
        Or with less resources than usual? How new was the subject matter to you?
        How many other teams or stakeholders did you work with on this?
        How much pre-established process was there in place for your role?
        What were the interpersonal challenges?
        What did you learn?
        Discover some gems.Grilling yourself will give you a ton of data. But most of that data won't be impressive to an outsider. Much of it might be muck. But that's OK! Within the muck there will be some gems, pieces of well-crafted language. After you've uncovered these gems, search them for any signal for customer obsession. Gems don't need to have that signal. However, a gem with any of these signals is inherently a more valuable gem because it's tailor-made for Amazon.

        Example Gems

        For each project you've worked on in the past few years, ask yourself these questions:
        I found a security vulnerability in our cloud infrastructure which saved the company 3 million dollars in annual customer support costs.
        The main project I worked on for the last two years was a bot detection project to stop fraud. As a part of my research, I spoke with the 10+ teams (including some Staff-level engineers) who had attempted to solve this problem but failed. I noticed they all did the same thing - they made an assumption that hackers aren't always evolving. These other teams were implementing 1 idea every 6 months or 1 idea per year. My team (myself and a data scientist) was able to implement 5 ideas per week. So, in some sense we were moving more than 125X faster than the other engineers who had previously worked on this problem. We ended up solving the problem, getting some patents, and saving the company a bunch of money.
        This is something that I learned the first time I built my own user authentication from scratch. Any way you authenticate users there's always going to be security risks.
        I made a software application that controls a very fancy refrigerator. I wrote 5-10k lines of code for this project. The most challenging part was linking up three different aspects (which were all over the stack) to talk to each other. Low level hardware interfacing, which was all wrapped up. And then there's the back end logic that controls the data ingest and data logging and data processing. Lastly there's the front end which is a graphical application with live plots and switch and dials and stuff.
        Find a bunch of metrics and impact.You don't need to be 100% certain about the numbers; that's unreasonable. When it comes to your work history, especially for companies you no longer work for, your best guess is good enough.

        Metrics and Impact

        If you want to find metrics and impact for anything you've built, you can ask yourself questions such as:
        How large was its dataset or how many rows of data were analyzed to make it?
        How many devices/users did it launch to or will it launch to?
        How many engineering hours did it save? How many non-engineering hours did it save? How often (how many times per year) will these hours be saved? What is the cost of those yearly hours?
        How much money is processed by it?
        How much more accurate or effective was it than a given benchmark?
        How much was efficiency or productivity increased by it?
        What did users or colleagues say about it?

        2
        Frame the data

        What is the process to turn your raw data into something polished for an interview?You have your raw data. Next you have to figure out how you want to frame the data, then you apply the data to the frame you chose, then you see what story the data is telling, and then you see if someone else can understand the story. To begin, let's observe a perfect answer that you can emulate. This will become your frame.
        Example of a perfect answer to an LP question (i.e., your frame)We listened to hundreds of interview responses to find this perfect LP answer. First, we are going to demonstrate why it is such an effective answer. Then we encourage you to listen to the answer in its entirety.
        A great answer goes in a perfect, full circle.The candidate's answer starts with a key statement of the problem, and it ends with a summary of how he solved the problem. When you craft stories that go in a perfect, full circle (from problem to solution), your impact is baked into the answer.
        Speak in a way that both an expert and an idiot can understand.Albert Einstein said: “You don't really understand something unless you can explain it to your grandmother.” When you examine the answer, notice how simple his word choice is. Every word in the sentence is necessary, yet there are no words you have to google to understand.
        Focus on individual contribution.Most of his answer focuses on the actions he took (i.e., his “individual contribution”). Because of this, he avoids getting bogged down by minutiae, such as: technical jargon, details on how these teams and business units work, the specifics of the approach they took in this architecture, or explaining how this particular technology functions.
        Hear the perfect LP answer for yourself (don't mind the sharks 😉 )

        3
        Iterate

        Now that you have your frame, you can build answers atop the frame to see how they fit. Doing this will help you find out what works and what doesn't.
        Talk through your answers.The best way to practice is with an experienced interviewer who has domain expertise. If that's not available to you, then you'll want to use our example questions, record some answers, and analyze your own responses. Overall, this isn't a bad choice, but it isn't as helpful as practicing with an expert because feedback from yourself is limited by blind spots.
        Use gems, metrics, and impact as much as possible.It's impossible to overdo it with these three skills. There's nowhere in an answer that they can't be used effectively. Get comfortable using them. Experiment. Find what works for you.
        Clearly answer the question and demonstrate your passion for delighting customers.As we proved earlier, there's little to no value in guessing the underlying LP or attempting to aim your answer at one specific LP. Instead, practice answering each question clearly and broadcasting your obsession with making customers happy.
        Make 80% of your answer about individual contribution.Focus on making “I” statements (as in, “actions that I took”). This leaves 20% of your answer to cover “everything else.” Some examples of “everything else” are: a) “We” (or “actions we took”), b) “How stuff works in this company (or team or organization),” and c) “little things worth mentioning.”

        Amazon Leadership Principles interview question examples

        Most Amazon behavioral questions fall into one of 5 buckets. In this question bank we will define the 5 buckets and give you a few example questions in each bucket.

        Bucket #1: Technical problem solving

        If you ignore the “spin” some of these questions have on them (complexity, simplicity, novelty, etc.), these questions are straightforward; this bucket is about how you solve technical problems.
        Tell me about your project which was the toughest in terms of technical challenges.
        Give me an example of a complex problem you solved with a simple solution. What made the problem complex? How do you know your solution addressed the problem?
        Give me an example of a time you proposed a novel approach to a problem. What was the problem and why did it require a novel approach? Was your approach successful?

        Bucket #2: Learning (and failure)

        These questions ask you about times you learned lessons. Sometimes lessons are learned through research you did or curiosities you followed. Sometimes lessons are learned from mistakes you made (you can define failure as “knowledge gained through first-hand experience.”)
        How do you approach learning new technologies?
        Give me an example of a significant professional failure. What led you to making the wrong decision? What did you learn from this situation?
        We all have things about ourselves we'd like to improve on at work. Give me an example of something that you've worked on to improve your overall work effectiveness. What resources did you identify to help you develop? What was the impact?
        Tell me about a time when you were wrong.

        Bucket #3: Getting stuff (for the business) done

        These questions are about your ability to achieve desired outcomes for the business.
        Tell me about a time when you went above and beyond for a customer. Why did you do it? How did the customer respond? What was the outcome?
        Tell me about a time when you took on something significant outside your area of responsibility. Why was it important? What was the outcome?
        ​​Tell me about a time when you had to deliver something at a very tight timeline.

        Bucket #4: Interpersonal conflict

        This is the most discussed bucket of Amazon questions. It's about conflicts with other people.
        Tell me about a time when you had a disagreement with a colleague or manager.What was the situation and how did you resolve that?
        Tell me about a time where you disagreed with a coworker or PM or manager because you believed the decision they wanted to make was wrong for the customer.
        Tell me about a time when you strongly disagreed with your manager or peer on something you considered very important to the business.

        Bucket #5: Ambiguity

        “Ambiguity” questions are easy to identify because the question will present two opposing or conflicting ideas.
        Give me an example of when you had to make an important decision and had to decide between moving forward or gathering more information.What did you do? What was the outcome? What information is necessary for you to have before acting?
        Give me an example of a calculated risk that you have taken where speed was critical.What was the situation and how did you handle it ? What steps did you take to mitigate the risk?
        Tell me a time you made a hard decision to sacrifice the short term gain for a longer term goal.

        4
        Refine the stuff that works

        Now that you have practiced giving answers with some framing, you should have a better idea of what works. At this point, you can refine the story your data is telling. This means (partially or fully) scripting out your answers. How much to script depends on your preferences; some people prefer room for improvisation while others would rather know exactly what they're going to say.

        Once you have a basic outline of the key points to hit, or the answer scripted out in full, you can measure what story your data is telling. To achieve this, consider how much signal for customer obsession is found in your answers.

        Finally, it's time to benchmark how effective you are at conveying your story to someone else.

        5
        Go from good to great

        Get actionable feedback from actual Amazon interviewers.Admittedly, we're biased, and we think you should use the interviewers on interviewing.io 🙃 Mock interviewing with experts will take you from good to great because it accurately simulates the environment of an interview. It's just like the real interview but without negative consequences; think of it as a proxy server for your job search. You get what you need (actionable feedback) from a reliable source (an Amazon interviewer) and there's no risk involved (you can't get rejected).

        6
        Adopt the Amazon mindset

        Embrace the fire.In the spirit of competition, Amazon turns up the heat to see how you react to the flame. Expect direct challenges. When it happens, stay cool. Don't forget: it's not a standardized test; it's a game. And in order to beat the game, there's one thing that we want to make sure we're on the same page about…
        All credit for this video goes to the legend Bruce Lee, and also to AMC who shot the original footage.
        NEW WEBINAR
        Ready to practice with an Amazon engineer?

        Book mock interviews with engineers from Google, Facebook, Amazon, or other top companies. Get detailed feedback on exactly what you need to work on. Everything is fully anonymous.