12 min read

Everything you need to know about Amazon SDE interviews in 2022

This guide has everything that you need to ace the Software Developer Engineer (SDE) interviews at Amazon. It will help you succeed on the coding portion and the Leadership Principles (LP) questions.
A pile of Amazon boxes, arranged to look like a person walking
An Amazon software engineer taking a break from work

This guide has everything that you need to ace the Software Developer Engineer (SDE) interviews at Amazon. It will help you succeed on the coding portion and the Leadership Principles (LP) questions.

Amazon's interview process is different from the process at other top companies. Other companies emphasize the coding screens. Some don't ask behavioral questions at all, while others ask one question to uncover candidates that are obviously not a culture fit. If you are comfortable answering classic behavioral interview questions, then other companies' behavioral screens will not surprise you.

Amazon places equal emphasis between their behavioral screen and their coding screen. Their behavioral questions are focused on concrete examples of how your experience reflects Amazon's Leadership Principles (LPs). During each of your coding interviews, you will be asked both a coding question and LP questions. If you do not explicitly prepare for Amazon's behavioral screens, you will likely fail the interview.

Below, we have all the information that you need to prepare for the coding and LP questions!

Applying to Amazon

How to get your foot in the door

There are two basic ways that the Amazon process can begin. Either a recruiter will contact you, or you will apply through their online portal, amazon.jobs.

Regardless of whether you are contacted by a recruiter, or you reach out to Amazon yourself, you will submit an application through the online portal. You will also use the online portal to track your application status.

During the application process, you will need to provide some information about yourself, and additionally upload a resume. If you do not have a resume, you can apply using your LinkedIn account.

After you apply, the recruiter will reach out to answer any questions that you have, and to set up your coding screen. After your coding screen, they will inform you of the results of the screen. If you passed, they will schedule your full interview loop.

The coding screen

Before you are scheduled for an onsite

Different candidates have had different coding screen experiences. This makes sense, since teams can customize the specifics of the interview process to what suits them.

Some candidates did a simple live coding exercise with a senior member of the team they are interviewing for. Candidates for coding jobs say that they were asked to implement a simple in-memory data structure like a least-recently-used cache or a linked list. One candidate for a frontend role reported that they were asked to implement a bare-bones HTML, CSS, and JavaScript site without a framework.

When you are scheduling the coding screen, discuss with your recruiter whether you should prepare to answer Leadership Principle questions. If so, read the "Answering Leadership Principle questions" section below for some advice on how to pass this portion of the screen. These are typically saved for the onsite interview, but it doesn't hurt to check!

Candidates were sometimes asked to implement a take-home exam before their interviews, but this does not seem to be common. The output of this exercise was discussed in the interviews.

Amazon will update the result of your phone screen within 5 days. The recruiter should inform you of the result, but if you want to check the status of your application, you can see if your application is still listed as "Under Consideration" on amazon.jobs.

Resources

  • The Blind 75 is a curated list of 75 Leetcode questions that prepare you for many of the Computer Science fundamentals that you might need. Some candidates say they were asked questions directly from this list.
  • Cracking the Coding Interview by Gayle Laakmann McDowell is two things: a step-by-step guide to conquering coding interviews given to software engineers, and additionally a series of practice questions with explanations of how to solve them.
  • GlassDoor lists a bunch of coding questions that have been asked in real Amazon interviews.

Answering Leadership Principle questions

If you don't prepare for these, you will probably fail your Amazon interview

Amazon heavily emphasizes the Amazon Leadership Principles (LPs) during the interview process. They care as much about the Leadership Principle questions as they care about the technical questions. In fact, if you fail the interview and you are surprised, it's possible that you underperformed while answering the LP questions.

Amazon is a data-driven company, so provide data for each of your explanations. Anecdotally, a common reason that SDE candidates fail the LP questions is that they fail to discuss the metrics or impact when explaining their answers. You can avoid falling into this trap by using the STAR framework.

The STAR framework

The recruiter will coach you how to answer the LP questions. This will likely involve explaining how to frame your responses in the "STAR" format: situation, task, action, results.

Here's an explanation of each step, and an explanation of how you might describe a project from your past in the STAR framework:

  • situation: What precipitated the change? Revenue was weak in Q3, so I was placed on a team responsible for improving our revenue via A/B experiments, with a focus on adding extra signals to the site.
  • task: What task were you given? I was the tech lead, and I worked with the designer and product manager on a particular change to show an interstitial in complex cases involving sales with minimum prices.
  • action: What did you do? When discussing the change with them, I noted that the path they wanted to edit was more technically complex than it seemed, since it actually involved a step where it contacted an application that attempted to do some complex bookkeeping, and then decide where to redirect. The logic would need to be kept in sync between the old and new experiences, and error states would need to be implemented in a few places, which could add months of development time to something that was supposed to be a simple change. I made an alternative proposal that the information should solely be presented in the checkout flow, which would not require any error state handling or logic synchronization, and would end up being a very simple change. After discussions, they agreed to try the much simpler experiment.
  • result: What happened? The experiment was successful, and A/B testing showed that it increased our conversion rate in this path by about 1.2%. I can't give exact revenue numbers, but it probably paid my salary by itself, if you catch my drift. The final implementation only touched one customer-facing point instead of the several that would have been required by the other proposal, and since the experiment was statistically significant, we earned the company more money by speeding up the development time.

Preparing for the LP questions

You should prepare for the LP section by making two lists:

  • For each LP, list the aspects of your work experience that meet each LP. Whenever possible, try to come up with hard data about the impacts. If you can't come up with hard numbers, focus on a compelling explanation of the impact of your decision. If you can't come up with one, then it's possible that you shouldn't mention this part of your work experience.
  • For each item in your resume/LinkedIn account, list the LPs that it demonstrates, if any.

Why make both lists? This allows you to easily talk about your experience however they ask the question. If they ask you about a LP, and want to know how you have demonstrated it in the past, you can use the first list. If they walk through your experience and ask how each line item reflected the Amazon Leadership Principles, then you use the second list. You will be covered however the conversation flows!

Before your interview, review each of the lists until you can comfortably discuss your experience in terms of the Amazon Leadership Principles.

Onsite (or remote onsite) interviews

Coding and Leadership Principle questions

You will typically have four interviews during the onsite. Three of the interviews will be coding screens, and one of the interviews will be dedicated to a LP screen. The coding screens will typically ask you two LP questions in addition to the coding question that they ask.

For the LP questions, see the section above titled "Answering Leadership Principle questions".

Amazon provides a list of topics that you are expected to know, and also provides a detailed list of how they evaluate the interviews. The information from these interviews will commonly be distributed across the three technical interviews as follows:

  • A data structures/algorithms question.
  • A "low-level design" question, like designing a class.
  • A "high-level design" question, like a system design interview.

Data structures / algorithms question

Candidates typically report that the data structures and algorithms questions are easier than the onsites of other top companies. The difficulty of the coding screen questions ranges from Easy to Medium on the Leetcode scale. This stands to reason. Since each coding screen asks two LP questions, there is not enough time for the coding question to be exceedingly difficult.

See the Resources section below for resources that will help you on the coding screens.

Low-level design

The low-level design question is concerned with evaluating your code design skills. Can you model the classes in a domain properly? How good are you at providing accurate and informative names? Do you have intuition for what makes the class maintainable? Do you understand how to write code for the classes that you implemented?

When doing these interviews, treat them as conversations with the interviewers. You are working with them to define the target domain as much as possible. Learn what the actors in the system are, and what they can do. Ask questions until you feel like you've learned as much as you can, and then ask, "Is there anything else we should have gone over that we didn't?" If they indicate there is not, ask how they want you to code this, and what they are looking for.

They expect the output of this interview to be code. You will need to discuss with the interviewer to determine exactly what they want. It's possible that they would like you to define the declarations of functions and methods for all of the different actions and clasess in your system, but that they don't want the implementations. Other interviewers might want you to implement

You may also need to write test code. If they don't ask you for tests, don't assume that they don't want them. Explicitly ask if they are expecting you to write tests. Work with your interviewer to understand what kind of test coverage they want: unit, integration, etc.

High-level design

This section is called "Problem solving," and it is considered a whiteboarding challenge. You will be given an intentionally-vague problem statement, and expected to have a discussion with your interviewer to uncover all of the parameters of the system.

Some things that you can ask about: who uses the system? What do they use it for? What kinds of actions do they perform on the system? What kind of scale is it expected to have? What kind of performance considerations is it expected to have? Are there any notable constraints on how the backend can be implemented? Who has to maintain it?

Ask questions until you feel like you've learned as much as you can, and then ask, "Is there anything else we should have gone over that we didn't?" If they indicate there is not, ask what kind of diagram they are looking for, or what they would like the diagram to represent. There are a few possibilities: maybe they want a diagram of the machines in the system. Maybe they want a diagram of how data will flow through a system. Just find out what they're looking for.

This interview has a few key metrics. Did you learn enough about the situation by asking questions to design the system correctly? Does your solution solve the problem? And is your solution simple, and avoid solving problems that the system didn't need to solve (like adding caching layers for performance, when you were told that performance didn't actually matter)?

Resources

  • The Blind 75 is a curated list of 75 Leetcode questions that prepare you for many of the Computer Science fundamentals that you might need. Some candidates say they were asked questions directly from this list, but don't rely on that.
  • Cracking the Coding Interview by Gayle Laakmann McDowell is two things: a step-by-step guide to conquering coding interviews given to software engineers, and additionally a series of practice questions with explanations of how to solve them.
  • GlassDoor lists a bunch of coding questions that have been asked in real Amazon interviews.
  • Grokking the Object-Oriented Design Interview was recommended for preparing for the low-level design questions.
  • The System Design Primer is a resource for handling the high-level interview questions.

After the interview

What to expect when you're expecting to hear back from Amazon

The hiring decision will be made by two people: the hiring manager, and the "Bar Raiser." They will do this in conjunction with the feedback that they receive from all of the interviewers.

A "Bar Raiser" is a role at Amazon that acts as a steward for the Amazon Leadership Principles. In this case, the Bar Raiser will act as an impartial judge and assist the hiring manager in making the hiring decision. They will help guide the hiring conversation, attempt to prevent individual participants from forcing a group consensus, and ask prompts like "what would Amazon miss by not hiring this employee?"

Amazon will typically notify you about their decision within a week. Since their process is lightweight in comparison to other top companies, you should expect to hear back relatively quickly. You can check the status of your application using the Amazon jobs portal at amazon.jobs.

There is a possible situation where your application will end up in limbo. If Amazon has already filled the open headcount that you were applying for, you will go into a process called team matching. This is where Amazon will attempt to find a different team that you can work on. You will get to have a conversation with members of this team in order to help make your decision. If you are in team matching, you have passed the hiring bar, but you do not yet have a job offer from Amazon, and your application could still be rejected if they fail to find a match.

It can be difficult to evaluate teams from the outside. You can ask them about their work routines, how decisions are made on the team, and what successful team members have in common. If you talk to a manager, ask them if you can talk to a SDE on their team.

An Amazon-specific question is how much away team work the team is involved with. An "away team" works with a "home team" to implement a feature that the away team needs. Commonly at corporations, a service team will have lots of clients, and one of the clients will need a feature from the service team that is not on the roadmap. In most companies, this will just end with a stalemate, and the client team withers and never gets what they need to be successful. At Amazon, the client team can form an "away team" to go work with the "home team" (the service team). This away team will implement the feature, and hand it off to the home team for maintenance.

If you're interviewing with a specific team, consider asking how much away team work the team is involved with. If the teammembers indicate that they do a lot of away team work, ask them for details about the away team projects, and see if the situation sounds reasonable to you.

Understanding and negotiating your offer

Stock grants, leveling, and counter offers, oh my!

Once you have cleared the hiring bar, and you have an assigned team, they will give you an offer.

Some parts of Amazon's offer are unique to Amazon.

Year Other companies' stock grants Amazon's stock grant Difference
Year 1 25% 5% -20%
Year 2 25% 15% -10%
Year 3 25% 40% +15%
Year 4 25% 40% +15%

First, Amazon's stock offers vest at 5% in the first year, 15% in the second year, 40% in the third year, and 40% in the fourth year. In comparison, other companies will typically vest 25% each year (with a one year cliff, meaning that the first year of the vesting schedule is delivered all at once). Use the above chart to compare how much you receive per year. You will receive less than other companies in your first and second year, and more than other companies in your third and fourth years. Amazon provides a signing bonus to compensate for the lower stock grant during the first 2 years.

If you think that the first year stock award is not enough total compensation for that year, consider negotiating either your base salary or your signing bonus. They will not negotiate on the vesting schedule.

It's not uncommon for your Amazon offer to be downleveled. This may have innocent explanations. For example, if you are a new graduate, they may ask you to apply to a SDE II role, but offer you a new grad position at SDE I. Consider the role and the salary when deciding whether the offer is appropriate for you.

When negotiating your salary, understand that if you give them more flexibility in meeting your requests, you will be more likely to get a better outcome. Maybe they can't give you a higher base salary, but they have flexibility on stock and the signing bonus. For example, don't separately negotiate the signing bonus, your base salary, your level, your yearly bonus percentage, the amount of stock, the vesting schedule of the stock, etc. Instead, explain what total compensation number you want. "Looking at publicly available salary data on Glassdoor and Levels.fyi, I feel like your offer is lower than what I would accept. If you bump up the total compensation numbers by 12%, I would be much more happy with it."

If Amazon cannot meet your salary request, anecdotes suggest that they will tell you this, instead of stringing you along. You can respond, "Well, what can you do instead?" to fish for a counteroffer from them. If they will not give you one, then you are still negotiating the offer that they gave you. At this point, you will need to consider whether you will sign the offer, attempt to give them a counteroffer, or walk away.

What's next?

What happens after they make a decision?

If your candidacy is rejected at any point, the Amazon Jobs portal page will list your candidacy as "No longer under consideration." Ideally, this would be paired with some information from the recruiter with any feedback from the interview. Since every team's hiring process is a little different, your experience after the rejection may be a little different.

Officially, you can reapply for jobs at Amazon after one year has passed since your rejection. Anecdotally, it can be as little as 6 months in some circumstances, but there is seemingly no consensus about what situation or teams would trigger the 6 month cooldown instead of the year-long one.

If you sign the offer letter, then the hiring manager will be in contact with you to help schedule your start date. They will be the best person to contact about the onboarding process, and about any questions that you may have.