https://www.scarletink.com/interviewing-at-amazon-leadership-principles/
Disclaimer: I’m not representing Amazon in any way with my posts, opinions written here are strictly my own.
This post is a part of a series. This post summarizes the 16 Amazon leadership principles, and the related behavioral interviews. I also have a post on the Amazon technical / functional interviews, and a post on the overall Amazon interview and hiring process.
Update: 9/19/2021 - I've received numerous contacts from new Amazon hires saying that this article helped them pass their interview loops. Amazon recruiters regularly send a link to this article to potential candidates. I am careful to keep it up to date. Please feel free to reply to any of my newsletters to contact me, or email me at dave@scarletink.com
Update: 7/1/2021 - Amazon announced today that they created two new Leadership Principles. This brings the 14 leadership principles up to 16 leadership principles. The new principles document non-project related behaviors we expect from our leaders. I've updated this article to walk through these new principles.
As a bar raiser at Amazon (a little googling will answer what that is if you’re not aware), I’ve gotten the opportunity to interview a lot of people. I’ve interviewed both very senior and very junior folks. Bar raisers do interview across all job families, and I’ve interviewed people for some pretty crazy positions. However, most of my interviews are for technical positions. Jobs like technical program managers, software development managers, quality engineers/managers, and of course the highest volume: software development engineers.
There are plenty of web resources regarding how to pass the functional (job skills) part of interviews. In fact, when I have friends and relatives interviewing, I send them to the internet to figure out what types of questions to prepare for rather than spend my time explaining. This type of preparing is pretty straight forward. You need to be good at your job, and make certain that the functional knowledge about your job is pretty fresh in your head. Perhaps how Hashtables work, or a bit about K-means clustering.
On the other hand, there isn’t much on the internet about the other side of the interview process. When we at Amazon interview candidates, we’re looking for a combination of those functional skills (coding, design, program management, 3D modeling.. you name it), and leadership skills. This applies to every potential new hire at Amazon, from experienced vice presidents to brand new college graduates. We literally assign specific Amazon leadership principles to each interviewer in the process. Those interviewers attempt to get a picture of how likely you are to be the type of leader we’re looking for.
This article was written for the specific purpose of preparing you (a little bit) for that half of the interview. It’s my version of giving sample questions. I don’t know what you’ll be asked, but I know what we’re looking for. If you can be what we’re looking for, we’d love to have you.
A brief pause for a personal note
I'm going to take a brief moment to welcome everyone who has signed up for my email list. I'd like to especially thank the hundreds of people who have signed up as paid members.
This support gives me the opportunity to spend my time writing and sharing with others what I've learned about working at Amazon, interviewing successfully, and being an empathic leader.
If you haven't signed up yet (for FREE!), please consider doing so! I'm writing new free and paid articles weekly.
If you have any comments or questions, please feel free to reply to my newsletter email!
Amazon Leadership Culture
There are quite a few articles out there about what Amazon’s leadership is like, how our leaders act, and what it’s like to work at Amazon. There are mentions of continual innovation, cut-throat competition, and fast paced projects.
As an Amazonian, what I always tell candidates is that there is not much about working at Amazon which is consistent across groups. We don’t do much the “Amazon way”, because very little is centralized. We have the leadership principles which guide how we act. Otherwise, every group acts like a little startup. They establish their own processes and best practices. They build an organization and way of doing things uniquely their own, while still following our leadership principles.
Considering how little we have centralized, we use the bar raiser group as a type of glue across organizations. We select bar raisers from the pool of experienced folk at Amazon, not just those who can interview well, but more importantly — those who deeply understand our leadership principles. As bar raisers, we then try to hire people who can understand and act on our principles. Finally, we set them loose into the chaos which is Amazon, with an assumption and belief that hiring people who follow our leadership principles will lead to long term success.
Understanding the Leadership Principles
When I have friends or relatives (or friends of friends, or friends of friends of relatives) ask how to prepare for an interview, I always suggest they read the description of the Amazon Leadership Principles, and think hard about each of them. More than any company I’ve worked with or heard about, we use those principles on a daily basis.
We obviously hire based on the principles. We give both positive and negative feedback which reference the principles. We are encouraged to be aware of our own successes and failures in relation to the leadership principles. I know I’ve certainly referenced a leadership principle or two while talking about parenting techniques.
I’ve read many thousands of interview transcripts, and it’s often glaringly obvious which candidates have really read and grokked what the leadership principles mean, and those who either neglected to prepare for their interview, or simply didn’t understand.
Note for the below sections. The quotes I’m putting in are actual snippets of interviews I’ve had, with close to literal quotes. Yes, they’re extreme examples. I’m using a blunt instrument to make certain you know what I’m talking about.
Another quick note before getting into specifics. We interviewers are spending our time talking to you — the candidate — in hopes that you’ll be hired. It’s a big investment of our time, we don’t want you to fail. When we say something like “Well, that’s a good start, what else?”, it’s very rare that the right answer is “Um.. nope, that’s it”. Please listen carefully to what your interviewer is saying. Again, we’re here to help :)
Customer Obsession
Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.
Always one of the favorites to include in interview loops. I suspect as a principle it strikes so many candidates as obvious that they don’t realize what we’re really getting at. Every decision of consequence at Amazon involves the customer. Not just how they’ll react, but what is actually best for them.
What factors would you consider when deciding which offer should win the buy-box on the retail website?
“Maximize profit”
What else would you consider?
“Volume of sales, conversion rate, margin, etc, but it all comes back to profit.”
When interviewing research scientists for example (per the above), I’ve had some repeatedly insist that the right thing to do is to use algorithms to maximize profit. Even when I give a hint such as “What unintended consequence might happen if you only optimized for profit?”, they often miss the customer experience ramifications.
The thing we’re looking for is that you consider and care about the customer. We’ve regularly made decisions at Amazon which lowered profit/sales, because it was the right thing to do for customers. We all understand that the company performs better if our customers (and our employees) believe it’s acting in our best interest. We believe that’s the right thing to do, we make those decisions all the time, and we reward people for it. We need to make sure new hires will do the same thing.
For that feature, who was the customer?
“The product management team gave us requirements.”
But who was the end customer?
“Well, the marketing team I suppose, because they wanted marketing slots. Oh! And the sales group too.”
But who was the customer?
“I don’t understand”
It’s somewhat shocking how often people buried in large companies don’t mentally identify their customer as the final external customer. Their customer is their boss, sales, marketing, etc. They are so focused on doing what they’re told, so focused on building what they’re asked, without taking a big step back to understand who uses their product.
“I wrote the contact-us form for customer questions, but then I was watching the questions coming in (out of curiosity), and I saw so many of the questions had easy answers. I added a simple FAQ at the top of the contact form — after asking the product lead if she minded. It reduced usage of my form by a lot, which I’d call a win.”
We don’t need you to exhibit our leadership principles at your current job (we understand that other companies are different), but we do expect you to be able to demonstrate customer obsession in your answers. Preferably you’ll know who your customer is, their needs, what they really want from you (outside of your specific tasks), and think about solving their needs, not just tasks.
Ownership
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job”.
This leadership principle is core core to how Amazon operates internally. You can be confident that you’ll be asked questions to assess if you can act and think as an owner. This leadership principle is core to defining how our groups and company is organized. Slight digression to help you understand our model.
At Amazon, almost every organization / team / person can identify with something(s) they own. For example, I currently own the technology for Amazon Kids. By definition, that means all technology decisions related to the product end up in my court. As an owner, that means that I am responsible when something goes wrong, responsible when decisions are made, and I act in all ways as an “owner” of the product.
One of the managers in my group is the technology owner of the Amazon Kids Android application. This is still within my group, but he’s expected to act as an owner, be responsible when things go right/wrong, and so on. You’ll notice there are now two owners of the application. Of course I fully expect the engineers on the team to feel the same way.
And finally, if someone from AWS S3 comes to me and says they found a problem in my Android product, I’m going to be thrilled that they care enough. I’ll invite them to my office, see what they found, and discuss how we might fix it. Because we’re all owners and we all care, no one should ever say “That’s not my job”.
I’ve pushed for better HR policies. I’ve spent hours chasing down the owner for some random feature on the website to ask them to fix something. I fully expect everyone I work with (and hire) should demonstrate the same attitude.
When that happened and your whole application went down for a day, how’d you get it back up in the end?
“Well, we have an ops team which runs the website, so they eventually figured it out.”
Did your developers help them figure out what had broken?
“No.. that’s not our job.”
I’d like to mention again, we don’t expect your company to use the leadership principles. We don’t expect you to have acted the way we’d expect someone at Amazon to act. However, lets take a step back. You’re in an interview, and you know we care that people act like owners. What would you do as an owner in that case? Regardless of how you want to handle it in the interview, you need to make it clear to us that you know what the Amazonian thing to do would be.
“I was their QA and they shouldn’t trust me too far with the code because I barely know what I’m doing *laugh* but when they had a few bad weeks and were getting behind on the bug queues, I felt I had to help. I started spending a few hours a day fixing bugs instead of testing. They were pretty simple bugs, but I felt it was a better use of my time, rather than finding bugs no one had time to fix. I just did my best to document things really carefully to make sure my help was a net benefit.”
I remember once someone suggesting that we shouldn’t write to candidates explaining our leadership principles, because they’d be able to prepare and fool us. My response was that an interview candidate who understood what we were looking for so much that they were able to trick us, was exactly the type of candidate we’d love to have at Amazon.
Invent and Simplify
Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here”. As we do new things, we accept that we may be misunderstood for long periods of time.
Amazon is all about innovation. We are regularly doing things people have never done before. New scale, new products, new platforms. One of the most frustrating responses from anyone who has an open question is “I can’t think of another solution”, because there is always another solution. It’s just possible we’ll need to invent one.
The other half of this principle is the idea of simplification. The KISS principle is enshrined in our principles, because we all firmly believe that the simplest solution is the one you can maintain, the one you can iterate on, the cheapest one to build, and so on.
Minimal viable/lovable product is a concept firmly entrenched in how we do things, because so much about our ability to innovate, pivot, change our mind, build new things, is about doing things as simply as possible.
Ah, so you use wishlists. If you were in charge, how would you improve the wishlists feature on Amazon?
“Oh, I’d fix the drop down to sort the lists in most recently used order.”
Ok good, what else?
<Long pause> “Hm.. no, that’s about it.”
We can never be done with possible answers. We all have the capacity for infinite ideas. We need people with a capacity for infinite ideas, because frequently the first 7 ideas we had won’t work, and we’re going to need an 8th. We need people with the capability to look at other teams in Amazon who had similar problems, solutions in the industry, solutions used in other industries, books on the topic, etc. We need the question of “What else?” to be met by such a long stream of answers that it would take us forever to try them all.
When you realized the project review meeting wasn’t useful, how did you fix it?
“I canceled the whole thing. I realized the status we covered was already in our ticketing system, and I’d rather everyone spend that hour working. When in doubt, I always remove processes rather than fix them.”
Experienced software engineers know that the best engineers often remove code when solving problems rather than adding code. Removal is always a better option, when it comes to code, systems, and processes. Simplicity allows for faster and cheaper innovation, and that’s why they’re married together in this principle.
Are Right, A Lot
Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.
It’s certainly not about being faultless. I’ve heard people quip that being good at this principle is the difference between being right 55% of the time instead of 50%. While we’re obviously listening for someone to be intelligent while we interview them, that’s not the core of this principle.
We give our leaders (in other words, everyone) a scary/amazing amount of authority to independently get things done. “Get forgiveness instead of permission” is a popular quote, because we need people to just move. In return, we need them to both have good judgment/instincts, as well as question their own decisions and be open to counter opinions.
When she disagreed with your design, how did you know yours was right?
“She was very junior, she didn’t have as much experience.”
Sure, but how did you know she was wrong?
“My instincts are really good.”
We like people with good instincts. But we absolutely require and love people to be open to being wrong. Right and wrong are a matter of knowing what you are trying to accomplish, what the options are, and how to compare the merit of the options. Right and wrong are never a matter of who is more senior or who talks the loudest. We need our leaders to recognize that every perspective and opinion needs to be valued. And someone disagreeing with you is wonderful. It gives you a chance to reexamine your viewpoint.
Learn and Be Curious
Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.
Amazon has grown in incredible ways. What used to be considered a high volume service is now a laughably small one. The large organizations of years ago are literally 20x the size they used to be, or more. From those who have been at Amazon longer, you’ll hear quotes like “When I was first hired, this group was at 40 people! Now it’s at 700!”
“So for the team considering me, what language is that service written in?”
I believe it’s Java.
“Well I only know C++, is there a C++ team I could work for?”
We’ve all decided that what worked yesterday is not going to work today. Your code will need to be replaced, the design will change, the customers will demand more. Our services written before in Perl moved to C, and many of our C services moved to Java, and our Java services will continue to be re-written in whatever works best next. Everything changes, and so we need to as well. We place a large emphasis on everyone being open to learning new things, inventing new things, opening new doors, and being interested and inquisitive.
Tell me something interesting you’ve learned recently.
“Rust! Have you ever programmed in Rust before? It’s so interesting. So here’s the differences between Rust and ..”
We don’t need you to be obsessed with the latest language or newest tools or the hot new technologies in your field. We certainly don’t need you to know the language we’re programming in today. What we do need is for you to be open and interested in learning new things. Our leaders need to be open to new things, because that’s always the path forward.