Original date of writing: 3/29/2021

Status: New grad, BS computer engineering top 10 US engineering school
Position: SDE1 at Amazon
Location: Seattle, WA
Date: March 2021

This was the standard process for new grad applications for Amazon. I'm happy to answer any questions, but I won't post the exact problems I had. Formatting inspired from this great post.

Online Assessment

• OA 1 - Debugging [21 mins]:
  In this phase, you're given 7 questions where you need to find the errors in the code and fix them so that the code compiles with the correct output. As far as I can remember the errors were only a single line of code. You could choose C, C++, or Java. I got 5/7 on this phase. The probems near the end were definitely more difficult to understand and I spent too much time on the early ones. There isn't much review you need to do for this other than knowing basic syntax for one of these languages.
  Final score: 5/7

• OA 2 - Coding [70 mins]:
  2 coding problems, need to compile and pass 2 test cases you can see along with 20 hidden test cases. In my case, both problems were straight from Leetcode easy. First problem I passed all test cases in less than 10 mins, but for the life of me I couldn't pass the 20 hidden test cases for the second problem. However, I heard other people had the same issue on this problem and due to that and the fact that I got OA 3 after, I figure there was some error in the test. To prepare for this step, just grind Leetcode easy/medium.
  Final score: 22/22 for the first problem, 2/22 for the second problem.

• OA 3 - Work Style Simulation and Logical Reasoning [2 hours]:
  This round is the least straightforward and intuitive. You need to answer pretend emails and work situations in the way Amazon wants you to. For example, you'll be given a situation in which you need to meet a tight deadline and you'll choose from a list of responses for what you would do. It's important to study Amazon's leadership principles to know how they want you to answer. After this portion, you have a list of questions where you have to choose which phrase describes you more. For example, you have to choose between "I always meet deadlines" and "I work best in a fast-paced environment." There isn't necessarily a connection between the two. I think the two important parts for this step are answering in a way that matches Amazon's leadership principles and being consistent in your responses. Although performance might seem nebulous to us applicants for this assessment, I honestly believe this is the most important assessment in getting the final interview.

Final Interviews (3 rounds)

3 interviews, 45 minutes each, 15 minute break between each. I've heard you can get only 1 interview for this step which probably means you're already accepted. I've also heard that you can have 4 rounds, the one that I didn't have being with a hiring manager that isn't a software dev. For me, all 3 interviewers were software devs. The rough outline for each interview was as follows:

• 15 minutes for one or two technical questions
• 20 minutes for one coding problem
• 10 minutes for followup questions

Round 1:

Interviewer was a senior software dev. Introduced myself and explained why I want to work for Amazon. Asked me one behavioral question about leadership, answered within 5 minutes. He said it was great and all he needed to hear. We then proceeded to coding. This was a basic system design question, which made me a bit uneasy as I hadn't really prepared for system design. However, it was quite simple and ended up just being a variation of a popular question under the Amazon category on Leetcode. I solved it optimally in under 10 mins.

Because we still had 20 or so minutes left in the interview at this point, he just left it open for me to ask whatever I liked. Thankfully, I prepared a ton of questions and just kept the conversation going. He seemed pleased to speak and enjoyed hearing about my experiences. He wished me luck for my next interviews and I rested for the 15 minute break.

Important data structures: heaps, collections.

Round 2:

This round did not go nearly as well as the first. From the beginning, the interviewer (another software dev) wasn't nearly as talkative as the first and he seemed pretty disinterested. I answered his behavioral question well and he said it was good, but didn't really ask any followups which makes me question whether he was actually interested or not.

Coding was much worse than the first round. It was similar to a LC hard problem that I had not prepared for. It took me a while to get started, and the interviewer wasn't much help in this regard. He kept walking away for a minute at a time and would take a while to respond to my questions, which was pretty frustrating. I didn't realize until about 15 minutes in that it was actually a DP problem. Once I realized it, I changed my solution to something much better but very likely not optimal. I stated my time and space complexity and he said it was fine and he understood what I was going for. There wasn't time for followup questions due to the coding portion taking longer than expected.

I honestly thought this part might have killed my chances, so I was a bit put down going into the next round.

Important data structures: collections, dynamic programming.

Round 3:

Thankfully, however, this ended up being my best round. The interviewer was nice and talkative from the beginning and was a complete turnaround from the second guy. I had a good time talking about my behavorial questions (I heavily recommend preparing a lot of different stories for these). He was the only interviewer to ask me two behavorial questions along with a followup for one of them, but I don't think this was a bad sign as he seemed interested the whole time.

Coding problem was about graphs, another subject I'm not super strong in. It was actually a variation on a popular algorithm I wasn't familiar with at the time, but I managed to derive it on my own regardless. The problem was quite long, to the point where I question whether you're actually expected to finish the whole thing along with the followup. Nevertheless, I solved both parts and my interviewer said it was the time and space complexity he was looking for. He also commented that my code was clean and understandable, which helped him out since he wasn't very familiar with Python.

Had 10 minutes left for questions, and he even stayed an extra five minutes to answer anything else I had. I actually enjoyed this part of the interview and I was so happy to leave on such a high note.

Important data structures: collections, graphs.

Results and final thoughts

Three days later, I received an email from Amazon stating that they had no positions open and would be me on a waitlist. From my understanding, this isn't rejection and many on the waitlist do get followups later on. If anyone reading has any input on this part I would appreciate hearing about it.

For preparation, I solved about 110 LC questions, about 70% of them being mediums, along with the entirety of the Amazon section. I also went and resolved every question I had done in the 2 days prior to the interview. This part was critical. I didn't do much preparation for the behavorial part other than studying Amazon's leadership principles and thinking of how my stories applied to them. I have research and grant-writing experience along with publications and this was enough for me to have stories for every principle. If you aren't comfortable with interview speaking, this channel is often recommended for practice.

If you're interested in applying to Amazon, I would really encourage you to go forward with it. A month ago I was nowhere near ready for this interview. In that time, with Leetcode, I was able to take myself to the point where I would say I had an overall very successful interview. I truly believe that if I was able to do this, anyone can.

Some random thoughts on interview preparation:

• Write down the time and space complexity for every problem you solve.
• Comment your code, even the code you solve on your own. If you're like me, you don't write a lot of comments on actual projects you work on. However, writing comments on Leetcode problems helps to verbalize your thought process and makes it easier to review.
• Make two or three stories for every leadership principle.
• It's okay to spend an hour solving a Leetcode medium problem. Even some problems marked easy are difficult. You'll get more doing it yourself than you will just reading the solution.
• If you do have to read the solution, at least try to plan how you think the problem should be solved beforehand.
• BFS and DFS are used to solve a TON of problems, so know them well.
• In terms of coding review, I felt that LC was more than enough to prepare me for the interview. Also, LC premium is worth it so you can see the Amazon section and official solutions (which are sometimes good).
• Don't leave any moment of silence in the interviews. Always be talking, either about a story for the behavorial section or your thought process for the technical section. Seriously, talk as much as you can.
• Don't forget to do input validation and error checking in your code. You can't compile your code and there are no test cases. However, I could see the reviewers making notes when I did input validation and error checking, so it's definitely important. Of course, this is also important for actual software engineering and that's what they're really testing for.

This took a while to write so I hope it helps! As for myself, I hope I end up getting an offer on this waitlist. If anyone knows the likelihood of response at this point, please let me know. If you have any questions, let me know and I'll do my best to respond in the comments section. Good luck!