How to answer interview questions about the Amazon leadership principle “Are Right, A Lot”
The fourth Amazon leadership principle is “Are Right, A Lot.” If you’re preparing for an interview there, you should practice answering questions based on this principle.
If you don’t know about the Amazon leadership principles, you should read this article about interviewing at Amazon first.
I usually get questions from my interview coaching clients about what this leadership principle means because it’s a hard one to understand.
How Amazon describes the “Are Right, A Lot” principle
Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.
What does “Are Right, A Lot” mean exactly?
Here’s an excerpt of The Amazon Way by John Rossman, a book you should read if you want to know more about Amazon. He can explain the thinking behind this principle better than I can. This should help you understand what the principle means:
Leaders at Amazon are right—not always, but a lot. They have strong business judgment, and they spread that strong judgment to others through the clarity with which they define their goals and the metrics they use to measure success.
There is a high degree of tolerance for failure at Amazon. But Jeff Bezos cannot tolerate someone making the same mistake over and over. Therefore, leaders at Amazon are expected to be right far more often than they are wrong. And when they are wrong—which of course will happen when a company continually pushes the envelope—they are expected to learn from their mistakes, develop specific insights into the reasons for those mistakes, and share those insights with the rest of the company.
That should have helped a little, but I know the principle still isn’t that easy to understand. I think if you keep reading the meaning will become clearer.
How many examples do I need to prepare for this leadership principle?
Most people say that you should have two examples for each Amazon leadership principle. That’s a good benchmark, but doesn’t really work for this principle because there are so many ideas in it.
You need one story for a conflict question, one for a mistake/failure, and one for a dive deep/data question.
Honestly, mistake/failure questions are pretty popular so if I were going into an interview I would have four examples for that one. You can’t really use the mistake/failures for other questions either because they have such a unique structure and content.
The conflict stories are also “Backbone” stories and the data stories are also “Dive Deep” stories so you can use the same pool of stories to answer for more than just the one principle, which makes it easier.
Three common interview questions for “Are Right, A Lot” and how to answer them
I think of the principle as being about judgement, but “judgement” is a big concept. Because it’s such a big concept, it’s hard to pin down. How do you know if someone has good judgement? There are many behaviors someone might display that show their judgement or lack of judgement. Because there are so many layers to the judgement idea and so many behaviors one might display that show judgement, there is no one single typical question for this principle.
Let’s look at some ways in which an interviewer might ask about this principle. The first way is what I call the mistake/failure questions. These are popular questions.
The mistake/failure questions
“Tell me about a time you made a mistake.”
The interviewer might use different words to ask it, such as “failure” or “error in judgement” or “bad decision” or “regret.” You can use the same example as your answer no matter how the question was asked. Yes, you can use the same answer for the regret question too, just make sure you explain why you feel regret.
How to answer
First, admit you made a mistake.
Yes, it’s okay to admit you made a mistake. Everyone makes them. Don’t say that you’ve never made a mistake. That shows you don’t tell the truth or don’t realize when you make mistakes.
Admitting you made a mistake has to be the first part of your answer. But don’t talk about making a mistake with something that’s business critical. If the job you’re trying to get is Manager of X and, in your example, you talk about how you did a bad job with X yesterday…this is not a good way to answer the question. You should try another topic so that you don’t throw doubt on your skills – you can see how saying you’re not good at or weren’t good at X is a bad idea if you’ll need that in the job. Or you can pick an example from earlier in your career so you can show how different you are now because you learned. Ideally, you want to choose a story that talks about a skill a bit more removed from your potential duties at Amazon, or something that happened a long time ago.
Quantify your mistake, if possible.
Talk about how much revenue was lost or time was lost due to your error.
How did you fix your mistake? You can’t always fix things - it may be too late. But if you can talk about how you fixed it at the time, that is a good thing to include
Talk about what you learned from your mistake.
The “learning” section is absolutely necessary.
Link your learnings to a recent success.
You learned from your mistake and then you applied this new improved knowledge to your future projects. Give an example of where you had a successful outcome directly as a result of this new knowledge.
How not to answer
Don’t be overly hard on yourself. Yes, admit you made a mistake. But don’t talk about how you can’t believe you did this and you’re so sorry and you know how stupid it was, etc. Everyone makes mistakes and it’s necessary to be calm and straightforward when talking about them.
Don’t say you’ve never made a mistake. Don’t say that you’ve never made a mistake because this shows that you’re dishonest or don’t realize when you make mistakes. Dishonesty and lack of self-awareness are ways you fail this question.
Don’t say that your biggest failure is something very small like that you forgot to turn in your benefits forms, etc. This is a common thing that people do when they’re not used to being open about their failures. And don’t do the reverse psychology tactic where you say, “My biggest failure is that I work too hard.” If you have an experienced interviewer they will be secretly rolling their eyes at you for this.
Sample answers for the “Are Right, A Lot” mistake or failure questions
Answer given by a Big Data Consultant
I worked for a company’s big data practice as a Senior Big Data Consultant for enterprise. One of our clients, X Communications, the second largest U.S. cable operator, wanted to build two hundred nodes using Hortonworks Hadoop clusters. This was an important client for us. I worked with the client’s Big Data Manager on an analysis and determined the level of effort to be sixty days with four Hadoop admin resources to complete the build.
Unfortunately, I missed the project deadline because I failed to manage the scope creep. The project extended an extra sixty days. It cost us one extra month of billing four Hadoop admin resources worth a hundred thousand dollars.
During the project, the business requirements changed repeatedly, requiring support for HBASE, Kafka, Sqoop, and Ranger, which significantly increased the overall scope of the project. I flagged this scope creep in our weekly status meetings, came up with updated level of effort estimation of another sixty days, and presented it. I also created an updated project plan and explained the deviation from the original sixty days to the client’s big data manager. I offered the option of including the new requirements in a subsequent project, but I couldn’t persuade him.
From this failure, I learned that I need to be more vocal and have a stronger backbone. Going forward, I committed myself to engaging with the client manager and stakeholders in brainstorming sessions at the requirements phase to avoid scope creep. Also, I learned I should propose agile methodology/scrum framework for implementing this kind of project, even when the client was unfamiliar or even resistant.
Soon after, I managed a similar project with another client. When the client was vague on requirements, I told them about my experience with the Charter project and what it had cost us. Because of my experience and approach, the new client listened to me and decided to go with the agile model, which helped us to tightly manage the scope. We were able to deliver that project on time and we generated five hundred thousand dollars in revenue, largely because we managed scope and delivered on time.
The Data Consultant’s answer is good because it demonstrates what he learned and he is very specific about that. The best part of his answer is how he emphasizes how he turned his experience from a past failure to future success. This might be a risky answer though because dealing with scope creep is absolutely essential in his job, and he hasn’t done well with handling it.
Answer given by a Senior Technical Account Manager
This was when I was on my AT&T project. One of the applications was generating a lot of temporary files and was not cleaning it up. We had logged a bug with the application team. However, in the meantime, I had taken up a task to clean up the files hourly. I developed the script quickly as it was simple. Got it peer reviewed and put it in PROD. Everything was working fine. The following weekend we had a code deployment. We implemented a new tool for deployment. The deployment completed and we released the application for testing.
After some time, we got complaints that the testing team was seeing errors and no one was able to get to the application. I tried myself and I was not. Upon checking I found out that the ear file I deployed was missing. I knew I had deployed it and checked before releasing. So, I could not understand what happened. I checked with my coworkers and no one had done anything. So, I quickly redeployed, checked, and released for testing. I also kept working in the background to find the root cause. In some time, the issue resurfaced and I saw the same behavior. The files were missing. Then I realized maybe some process is removing the files. Also, I noticed a pattern that the complaints came at the top of the hour. So, it struck me that it may be from my script. I checked the script logs and found out that it was the case. I quickly removed the script. Then upon analysis I found that the new tool that we had used had created a symlink in the path of the application. This caused the find command to fail and the xargs that was piped to it and running rm picked up the wrong files and created them.
I conveyed this to my manager. I also gave him all of the technical details. I fixed the script and manually tested it a few times and put it back. This was very embarrassing for me as I had wasted 2 hours of downtime
The mistake I made was not to have a check for when the find command fails. I did not build error handling on that. So, this incident made a large impact on my future scripts. Now I make my scripts donkey proof at each step. It adds a few lines in the code and some extra executions, but I rather be safe than sorry.
Her answer is good because she does admit the mistake and say how she learned from it, but it would be better if she mentioned the mistake earlier. She doesn’t get to it until the last paragraph so the earlier part of the story is full of technical details with not much space given to analyzing her behavior and mistake.
The interpersonal conflict questions
I think of these as questions dealing with your interpersonal skills. Often they will involve conflicts. How you act in the middle of a conflict is a good indicator of how you relate to people. These questions are often similar or identical to the ones you’ll get asked in the Have Backbone principle questions.
How to answer
In answering this question you want to show you’re (1) a nice person but (2) you can be firm if your opinions are challenged and you can get your program/idea implemented if it’s the best choice. A good answer will show both (1) and (2). Unfortunately, a lot of people focus only on (2), showing how they met their goal, but not showing how they were easy to work with. In fact people frequently show that they were actually difficult to work with (they usually don’t know they’re doing this).
Is being nice really necessary? Do interpersonal relationships really matter? Isn’t being good at your job more important than being likable? Well, Amazon fosters a culture of assertiveness (some call it “sharp elbows”). In a culture like this it can be hard to meet your goals while also maintaining good relationships, but if you destroy your relationships you will probably ultimately not be able to achieve your goals because your goals often involve working with other people. This is really the reason you need to show you can “get along with” others, because someone who can’t maintain relationships will ultimately not be successful at Amazon because no one will want to help them. There are exceptions, of course, but for most people being good at interpersonal relationships is a real plus at work.
A good way to show that you’re nice is to show that you can be calm and have rational discussions if you’re challenged. Talk about how you had a discussion with the person you disagreed with and showed them data (calmly) about your idea. Say something that shows you respected the person you were talking to.
Besides showing you’re nice, you also have to show that you’re capable of achieving your goal. You don’t want to be so nice that you agree with the other person just to be nice. If you have an opinion on something but someone doesn’t agree, do you agree with them to end the conflict? Some people (many people) do. Or do you discuss the issue until you can convince them you are right (if you are)?
There are ways to convince people that your idea is correct that are also respectful. For instance, you can show that you can use data to prove that your opinion is the right one. Showing data is not hostile or confrontational and is always a good way to make your point.
Sample answers for the “Are Right, A Lot” conflict questions
Question: “Tell me about a time you disagreed with a colleague. What is the process you used to work it out?”
Answer given by a Director of Software Development
"I recently had a disagreement with my team about whether a specific functionality should be rolled out in production. The early testing we did showed a potential negative impact on website performance that could result in a drop in user engagement and usage of a $5B USD product. Emotions were high and the opinions were strong.
The first thing that I did was to draw a line of sight for my team about how this functionality was critical to the long-term strategy of the company and the potential upside if we got it right. Then I agreed with my team about key business metrics that we would monitor in production. This included full text access and FTAs/session. If we didn’t see a meaningful impact then we would know that the new functionality is safe and would not impact our business negatively.
We agreed to roll this out in an A/B test fashion first to 5% of the traffic and then slowly ramping up to 50%. We would run this for a few weeks and go to 100% when we’d achieved statistical significance. At any given time if we saw a problem we could ramp down to 0%.
I got an agreement from my team on this approach and everyone was reasonably happy to try out this way. We are currently at 75% and hopeful that we will be 100% within 2 weeks.
This answer is average. The conflict is with a team, not one person, so it doesn’t convey any actual conflict or “drama.” She says “Emotions were high” but that is a vague statement, not a description of the disagreement. What were some specifics of the disagreement?
A better story would be a conflict with one person. She would talk about what that person thought and what she thought, what the other person said and what she said in response. She would talk about how she showed the other person data in order to convince them that her idea was better. I know you normally wouldn’t talk about those kind of small details – what you each said – but in these conflict questions you should do that.
The judgement or data questions
I think of these questions as being about how you make decisions (how do you collect data, do you have good judgement, do you have good intuition, do you have experience to guide you?).
How to answer
Just describe what process you used. Be specific. Did you throw darts at the wall to choose what to do? Probably not. What did you do instead? How do you usually solve problems or make decisions? This isn’t a trick question.
Don’t skim over the actual research process. Say where you got information, even if you think this information is too basic or boring. Don’t just say that you “got the information from the database.” What information? What database?
They want to know if you have good intuition, and how you put that intuition to work. Intuition is partly using your past experience to make decisions, so you can talk about that experience and how it informed this decision.
They also want to know how you make decisions. What is your general process? Talk about that.
Sample answers for the “Are Right, A Lot” judgement or data questions
Question: “Give me an example of making an important decision in the absence of good data. What was the situation and how did you arrive at your decision? Did the decision turn out to be the correct one?”
Answer given by a Consultant: Give me an example of when you had to make an important decision in the absence of good data. What was the situation and how did you arrive at your decision? Did the decision turn out to be the correct one? Why or why not?
I was working in the Private Equity Group at X. The practice conducts commercial due diligence for private equity, which means that we pressure test the target company’s market growth, competitive dynamics, and profit upset before the firm acquires it. The due diligence timeline is usually short, between 1-8 weeks. I worked on a project investigating a trustee services provider in AU and NZ. I had about 3 days to form a recommendation on whether the NZ market represented a major opportunity for this target.
Based on my past experience, this question translated into 4 points of data needs. I typically go through a consistent approach to data gathering. After step 1 of the data gathering, I already knew there were significant data gaps in the securitization segment as well as the market share data for the managed funds segments.
The securitization segment was only $30B. It would not change the final answer. I was happy to make a business decision to not pursue it further. But I needed to figure out the market share piece so I called the experts regarding market share of the managed funds segment. I also gathered reports on the largest funds in NZ and went through their product disclosure statements. I also arranged expert calls with the largest funds to understand whether their choice is likely to change in the future.
Based on the outcome of my research, we formed the view that the NZ market was not exciting. The client was very pleased with our work as it answered their most strategic questions and presented data they had never seen before.
There are more details this person could have added. What are all types of data needs? What is the typical approach to data gathering? What is more background on why she was doing those steps?
Other possible interview questions for “Are Right, A Lot”
Other possible interview questions for this principle
Describe a situation where you thought you were right, but your peers or supervisor didn’t agree with you. How did you convince them you were right? How did you react? What was the outcome?
Tell me about a time that you strongly disagreed with your manager on something you deemed to be very important to the business. What was it about and how did you handle it?
Tell me about a time where someone openly challenged you. How did you handle this feedback?
Give me an example of when you took an unpopular stance in a meeting with peers and your leader and you were the outlier. What was it, why did you feel strongly about it, and what did you do?
When do you decide to go along with the group decision even if you disagree? Give me an example of a time you chose to acquiesce to the group even when you disagreed. Would you make the same decision now?
Tell me about a decision for which data and analysis weren’t enough to provide the right course and you had to rely on your judgment and instincts. Give me two to three examples.
Tell me about a time you made a difficult decision and how you knew it was the right solution (how you evaluated the options, if you received input, what data you reviewed, etc.)
Give me an example of when you had to make an important decision in the absence of good data because there just wasn’t any. What was the situation and how did you arrive at your decision? Did the decision turn out to be the correct one? Why or why not?
Tell me about a time you had to fix something but had no data or direction.
Tell me about a time when you were faced with a challenge where the best way forward or strategy to adopt was not “clear cut” (i.e., there were a number of possible solutions). How did you decide the best way forward?
