First, I would like to express my gratitude to the LeetCode community in helping me prepare for this opportunity. I invested more heavily in preparation this time, primarily through LC (premium), and delivered one of my better interview performances in recent history. I never thought I would be writing a post, but I am happy to give back to the community.

Background:

• BS from top 10 Computer Engineering school in US
• 3 years experience

Preparation (~ 1 month):
Coding:
LeetCode - Mock Amazon interview sessions (online accessment, phone screen, onsite) + the Amazon card on LeetCode explore. I pretty much exhausted these options.

System Design:
Gr##king the System Design Interview
Gr##king the Object Oriented Programming Interview

Behavioral:
For LP (leadership principle) questions, there were a few very helpful resources which helped me come up with sample questions and responses:
https://leetcode.com/discuss/interview-question/437082/Amazon-Behavioral-questions-or-Leadership-Principles-or-LP
https://medium.com/@scarletinked/are-you-the-leader-were-looking-for-interviewing-at-amazon-8301d787815d
https://interviewgenie.com/blog-1/category/Amazon+interviews

Round 1: Online Assessment
Q1: Number of Islands - https://leetcode.com/problems/number-of-islands/
Q2: Critical Routers - https://leetcode.com/discuss/interview-question/436073/

I was given 90 minutes, and I nailed the first question. Unfortunately, I was not very proficient in graph theory, and I had only studied a similar problem (Critical Connections, which is about removing an edge, not a node, which has a different solution). I was only able to get about 40% of cases to pass for this one.

Fortunately, I was contacted by my recruiter about a week later, and I made it to the final round, which was conducted virtually due to the current COVID-19 situation.

Onsite (virtual)
The interviews were conducted through the Amazon Chime app. There were 4 rounds, each 50 minutes long, with only 5-10 minute breaks in between (no lunch).

Round 1:
15 minutes of LP questions:

• Tell me about a time when you went beyond your roles and responsibilities
• Tell me about a time when your team made a decision that you disagreed with

30 minutes coding problem:

• Given a list of k sorted linked lists, return one sorted list

Round 2:
20 minutes of LP questions:

• Give me an example of a time when you reduced a complex problem and made it simpler
• Tell me about a time when you received critical feedback from your manager. How did you respond?

30 minutes coding design problem:

• Write a method that, given a directory, string pattern, and minimum filesize, returns a list of search results containing files that 1. contain the string pattern 2. have file size > minimum filesize.

My interviewer didn't seem concerned at all with how I chose to implement the method. He just wanted a "working" solution, and he did not comment much while I was coding. It may have been because I took the entire time to get a working implementation that we didn't discuss any tradeoffs or optimizations.

Round 3:
20 minutes LP:

• Can you give me an example of a time when you had to balance doing something "right" with doing something "fast"?
• Tell me about a time when you were not given much data, and you acted upon your intution and instincts instead.

30 minutes system design:

• Design a restaurant reservation system

Round 4:
So at this point, I was completely exhausted after 3 straight interview sessions, and I should have asked for a 5-10 minute break before jumping straight in. I don't like to make excuses for myself, but my performance was far from my best during this round, so a word of advice I would give is to take breaks when you have the opportunity.

15 minutes of LP:

• Tell me about a new technology that you learned recently
• What is the most difficult situation you've faced in your career?

35 minutes of coding:

• write methods to serialize and deserialize a binary tree without using recursion.

I had seen a very similar problem before, but I struggled immensely to implement the solution and made quite a few mistakes. For every few lines of code, my interviewer (who was more than helpful), would provide hints and help correct my logic. Half the time, my brain didn't seem to respond due to fatigue. It was quite embarrassing, but I did eventually arrive at the solution. I can't say that this was the nail in the coffin for me, but it certainly didn't help my case.

I received the unfortunate news of rejection a couple of days later from my recruiter, and, per company policy, I was not given any feedback. The news seemed to hit me harder than in past experiences because I felt that I invested much more time and energy this time around.

Although the interview experience was still difficult, I actually felt more encouraged after going through the process because the problems weren't as hard as I had expected them to be. On a LeetCode scale, they ranged from easy to medium, and two of my colleagues had similar experiences. I have only interviewed w/ FAANG companies 2-3 times, so I can only speak from limited experience, but I feel that the aura around of these companies has faded a bit for me now. Yes - they have talented engineers. Yes - they work on bleeding edge technology. But even for an average engineer like myself, I know that I have what it takes to earn an opportunity to work for one of them, and LeetCode is a great place to start working toward that goal.

Some general tips I would give:

• Get plenty of rest the night before. There's no point in cramming, and lack of sleep will only degrade your performance. You have a long day ahead of you, so don't make it feel any longer.
• For Amazon, do not underestimate the behavioral portion of the interviews. Practically half of the onsite interview experience consists of LP questions. Diversifying your examples is always better, and make sure to provide metrics and specific data to reinforce your responses when possible. If you read through Amazon's leadership principles, you'll see that they emphasize justifying your viewpoints with supporting data, which is why I wanted to make this point.
• I probably don't need to give coding problem advice. Just make sure to practice on a diverse set of problems, and write code that is clean and optimal. The logical understanding of the problem/solution is just as important as the implementation - don't neglect either one. Personally, I tend to jump straight into coding instead of explaining my approach and running through examples to verify my approach, which leads to many mistakes and inefficient programming. Being able to logically walk through an approach w/o coding first is an area that I need to improve on.
• For system design, communication is the biggest point of emphasis. It would be better to do practice design sessions with friends so that you can exercise communication skills. My interviewer wasn't concerned with technical knowledge. He wanted to see if I could clarify ambiguity by asking questions and really driving the conversation to define the system requirements.