Status: Experienced non-tech professional. Currently working at a small tech company where I get to write scripts. Attempting to transition to software development. Know programming languages but do not have a CS degree.
Position: SDE1 at Amazon
Location: Interviewed at another location for a role in Seattle
Date: March 2020

Intro:
*This is a lengthy post. I am offering a detailed description of my interviews and lessons learned since I hope the nuances will motivate and assist my peers in applying successfully *

I am not sharing any info on my team or compensation. My package is pretty standard. You can look up Glassdoor or levels.fyi for this info.

OA = Online Assessment
LC = Leetcode;
LP = Leadership Principles - 14 principles which Amazonians are expected to practice & embody

Step 1: Call with Recruiter
An Amazon recruiter found me via LinkedIn and we set up a call. Asked me a bit about my background and asked me to take the Online Assessment. I felt as if I needed more time to prepare for the OA. Normally, they say that the link to the OA will expire in a week. But this recruiter was empathetic. They revealed that the link is valid for a month. They clearly wanted me to feel comfortable and put my best foot forward.

Takeaway: I still get emails from Amazon recruiters even after the offer. Seems like they are hiring quite a bit. Once you get your info in their database, it seems as if it is quite easy to get a shot at an interview without a referral.

Step 2: Online Assessment (OA)
Qs 1: Variant of Number of Islands - https://leetcode.com/problems/number-of-islands/
Qs 2: Variant of Rotting Oranges - https://leetcode.com/problems/rotting-oranges/

45 mins to solve these questions and pass all test cases. This is followed by a 15 minute section where one is asked to explain time complexity, followed by a short survey

Takeaway:

• I don't know if this had any bearing on the final outcome, but I made sure to write good code with precise comments. The code passed all test cases.
• I also used up all the 15 mins explaining the reasoning behind my answer for time complexity. The recruiter had previously confirmed that one does not get extra points for passing all test cases asap. So there is no point in rushing.
• I did a demo test to become acquainted with the AMCAT platform. This was very useful since I had blown another take home test at another company because I wasn't acquainted with the platform once the test began
• Before the OA, I solved and was absolutely clear about every qs on this list, including the hard level questions: https://leetcode.com/discuss/interview-question/344650/Amazon-Online-Assessment-Questions. I wanted to eliminate luck from the equation. While this delayed me in taking the OA, it helped me a lot in my prep for the onsite

Step 3: Onsite Interviews
This was pre-lockdown so I had an in-person onsite. I had a few weeks between OA and Onsite since there was some confusion about the position I was applying for. This allowed me some more time to practice LC questions

For all my interviews, I used the whiteboard to walk through my thought process and to write pseudo-code. I used my laptop to write the actual code in Python

For every question, the interviewer verbally stated the question (it wasn't typed out as on LC). I had to ask them follow up questions to be clear about the inputs, the expected outputs etc

• Interview #1:
  Introductions and LPs for about 30 minutes. She asked me several details about my responses and even had many follow up questions. It was clear that the behavioural part was not some token exercise. This was followed by a coding question, a variant of this: https://leetcode.com/problems/top-k-frequent-elements/

  I provided a solid explanation on a whiteboard and then coded up an optimal solution.

  She asked me a follow up question. We were running out of time so she asked me not to write code, but instead to speak aloud. I think she wanted to see how I work through this.

  Takeaway: Over all, I thought this round went really well, and she seemed happy with me. She seemed to be the most experienced interviewer, so she could have been the bar raiser. But that's just my guess, I have no way of finding out.

• Interview #2:
  The interviewer offered a detailed introduction. He then asked detailed LP questions for 20 minutes. He then explained his role and a specific problem his team needs to solve and then asked me a question related to this. I correctly ascertained that this was a graph search problem for which I could use BFS.

  Before I began to solve, he asked to think of different use cases. I thought he was testing me but he was basically interested in defining the problem along with me. For example, for a specific input parameter, the program should return 1 etc.

  I was a bit unsure about whether to treat this as an undirected graph problem or a direct graph problem. I spoke aloud and clarified this with him. He made some notes, perhaps this was a negative point against me, because this problem can easily be solved as an undirected graph problem. In any case, I was able to code it up just in time. Forgot to add a visited set, he pointed it out and I quickly added it. Just managed to test my code in time.

  He asked me some follow up - I didn't really understand the question and we ran out of time, so he left it at that.

  Takeaway: I thought this was a mediocre interview for me. This was a straight forward BFS qs, but he asked me other ancillary qs which seemed tricky. In hindsight, I should have coded it faster (even if it meant bugs), then left more time for testing, and used a smaller test case. It was good that I spoke aloud as he clarified my misconceptions, ensuring I understood the question correctly before solving. I also asked him to write down an example of an input - seeing a 2D array on the board helped me visualize the solution and write code more confidently.

• Interview #3:
  By this time, I had understood that I have some control over how long the LP part of the interview could last. If I could be more succinct and wait for them to ask follow ups, that would be more prudent. This interviewer was loquacious, so he tended to digress and go into detail. So I was conscious of keeping my answers brief.

  The interviewer was very informal. They mentioned that they understood why LPs are a big part of the interviews since since they observe those traits in the organization.

  They seemed impressed with my answer to the question: “Why Amazon”?

  After 25 mins of LP questions I was asked an OOD qs: Design a vending machine class for a particular product. The machine was to have certain functionalities.

  Straight forward at first, they kept adding layers of complexity. At one point, they mentioned that if a customer asks for x number of boxes, then the correct combination of box sizes should be returned. At this point, I became nervous, since I recognized that this might be a DP question, and I hadn’t studied DP well. Fortunately, they told me to assume that the algorithm works, they were more interested in the design.

  There was a point here when they went into detail and I zoned out for 15-20 seconds so I didn’t know what they said. I felt nervous, but regained my composure. I told them there was a “gap in my understanding” and asked some clarifying questions. Their response helped me come back on track.

  I was asked to write out the code for my question. As we were running out of time, I just wrote the skeleton for one of the methods.

  I asked them a qs about an upcoming challenge on their team. Also, I wanted to highlight my knowledge of statistics so that I can display that I’m a good fit for their team. Their answer was very detailed. I was conscious of not asking a follow up question, since I knew this would rob me off valuable time in my next interview (I could see the final interviewer loitering outside the room). These kinds of things really matter.

  Takeaway:
  As mentioned, I zoned out for 15-20 seconds during this interview. This can happen when you’re switched on with 120% intensity for 3 hours non-stop. So one must be able to regain composure quickly, and be in the present moment. I also did a good job at controlling the duration of the behavioural part of the interview, which could have adversely affected me. Over all, they seemed happy with me. They were one of those interviewers who seemed like they wanted me to succeed. They seemed very satisfied with my LP answers as well. So I felt good about this interview

• Interview #4:
  Started with LP questions. I offered an answer from outside my work experience, and embellished it with some good examples. So both the interviewer and I were satisfied with this response

  This interviewer was different in that their sentences were brief and to the point. The LP section lasted only about 15 mins.

  Technical qs: They asked me to design a class which should enable certain functionalities. I promptly offered an answer. The interviewer looked confused, and spent some time googling things. They then changed the question. Apparently, this question could be solved easily in Python but was more challenging to solve in another language.

  They presented another question: Assume you are given a url for a web page which has more urls on it. Write a method which takes the input url and collects all urls which can be reached via the first url.

  I immediately recognized that I can solve this using recursion. I created an example on the whiteboard and ran through it, then wrote pseudocode for the method, and tested my example. I had doubts about one point in my implementation and shared this with the interviewer. They suggested that I write code, since without seeing anything, they are unable to comment. I wrote down the code quite quickly. I used the same example on the white board to test my code

  They asked me if a url can lead back to itself. I realized that they were prompting me. I had forgotten to use a visited set and I quickly mentioned the need for one, and then added it to my code.

  The example I had on the whiteboard had 3 layers of recursion and was simple enough. However, it took me a while to test, since I had to keep track of each function call and different line numbers in that call. I should have used a smaller example while testing.

  Interviewer was satisfied with my solution and wanted to move onto the final part of the interview where I could ask them questions. But I noticed that we hadn’t discussed any space and time complexities, and I was worried that if I did not offer an answer, this would go against me. So I asked them if we should discuss time and space complexities? And they said they hadn’t planned on asking me, and they weren’t planning on penalizing me, but now that I mentioned it, sure, we could talk about it. We laughed as I joked how I had shot myself in the foot. I wasn’t sure of the answer, since it was complicated , but I explained my approach, the depth and branching factor of the recursion tree etc. They were satisfied, it seemed as if they did not know the answer themselves.

  We moved on. I asked them questions about their work, and then some other questions relating to my own aspirations. This was a really positive engagement. I think they were happy that I had good questions.

  The interviewer wished me luck and then walked me to the exit.

  Takeaway: Use simple, really small test cases while testing your code, as recursive calls are hard to keep a track of. Practicing questions such as https://leetcode.com/problems/word-break-ii/ and https://leetcode.com/problems/word-search-ii/ really helped here as I had become more comfortable with recursion. Don't volunteer to answer questions you haven't been asked!

The Offer
Within a few hours, I received a call from the recruiter stating that they had decided to make me an offer.

Learnings:

1. Go for the onsite even if you are not yet 120% confident. I think that if I were to solve some of the coding questions over the phone, I would have not made it. But in person is a different ball game. I think my personality came through during the LPs, and other Q&A, and even during the parts where I wasn’t fluent with the coding, I asked clarifying questions and spoke aloud and my thought process was clear. The onsite was a really good interactive experience. It was not as intimidating as many blog posts had me believe. While I was prepared for the same, I was not asked any impossible questions.

2. Don't discount the non-technical portion: Practice LP questions. I prefer concise books over videos so I read most of 'Cracking the Amazon Interview' by Misha Yurchenko. This blog post also helped: https://medium.com/@scarletinked/are-you-the-leader-were-looking-for-interviewing-at-amazon-8301d787815d

   a. I listed down each LP and why it was important for Amazon
   b. I listed down all my jobs and created bullet points of major achievements, failures and what I learned from each. Then I tried to map these to the relevant LPs. I found this to be a far more efficient and realistic method than trying to find one unique example for each LP.

   Engage with the interviewer. Prepare solid questions (not some token, shallow ones) to ask them. Apprise yourself with the business model of the team you are interviewing. All this helps. They wouldn't share any feedback with me so I am not sure how they evaluated me. But my sense is that I did very well on the LPs and definitely connected with them on this and the overall soft skills aspect.

3. Believe in yourself: Try your best to maintain a positive outloook. Do not be discouraged on a tough day when you couldn't even understand the solution to the single recursion problem you attempted. I tried to follow these principles and I think they really helped me succeed. If you don’t crack the interview because of a lack of knowledge, that’s okay. But don’t fail because you forgot something you knew or blanked out because you were nervous. Believe that you deserve this job, that you’re good enough. Such a belief manifests itself in your performance. Initially, I was feeling very weak and under-confident. Had I not actively infused positivity and belief within me, I think the outcome would have been different.

4. Quality over quantity: When I practiced a question, I tried to understand the solution inside out. For example, with questions on recursion (which is still challenging for me), I would walk through every call of the recursion and see what happens. This really helps unravel how the recursion works and how caching solutions makes things faster. If possible, also learn to sketch the recursion tree. This really helps deepen understanding and also recognize time and space complexity for the problem. After you have done this a few times, these things come much quicker and more naturally when you see them on other problems. I even wrote down the algorithm in words in the notes section. At times, this required 2 hours for a medium question, sometimes even half a day. But I think this helped me recall solutions really fast. So when revising, I required 5-20 mins to solve an entire question/write pseudo code for the algorithm for even hard level questions

5. Progress sequentially: When I first started solving on LC, I started with medium level questions. This proved disheartening as I was almost always unable to solve the question (or even understand the solution) on my own. It was also very inefficient since I was spending too much time on a single question. I realized my folly, and went back to easy level questions on the Top 100 questions list. While solving these questions, I kept track of the topic of the question and my comfort level on it. I then picked a topic I wanted more practice on e.g. Hash table and solved 4-5 easy questions on it until I felt really confident. After this, when I moved onto medium level questions, I was far more fluent. So unless you have absolutely no time, I recommend progressing sequentially.

6. Methodology:

   a. Use approach outlined by Gayle Lakman Dowell: These resources -
   
   
   Cracking the Coding Interview - "Walking Through a Problem" section.

   really helped me.

   I tested and then adopted the approach outlined by her. The BUD (Bottlenecks, Unnecessary work and Duplicate work) and DIY (Do it yourself) are especially effective. I realized the power of DIY and walking through a problem, thinking as you are speaking. Inherently, I am one of those who wants to first think in silence, and once I have arrived at the solution in my mind, only then start articulating what the solution is. I used to believed that thinking while speaking just does not work for me. But I was wrong. I practiced 5-6 qs with the approach suggested by GLD, and it really seemed to come together. I found that when I started speaking, I didn’t know the answer. But as I articulated the bruteforce, what the bottle necks were etc, the optimal answer just seemed to flow. I think it takes some practice to become comfortable with thinking while you’re speaking, but once it clicks, then you go from strength to strength. And I think this is what interviewers want. Realistically, you can ask for time to think in silence, but if this exceeds 2 mins, it becomes really awkward for both parties.

   b. Buy a white board asap - The approach she enlists requires the use of a whiteboard. I have tried walking through a problem on paper or a coder pad but its just not the same, at least for me. Writing on a whiteboard is a very powerful technique as it leads to important insights which you may not arrive at through merely thinking. Do not wait to first receive a call to an onsite interview. Practice the right way, using a whiteboard from Day 1.

   c. I wrote the algorithm in words on the coder pad/white board before writing the code. This proved very powerful. I found that if I could do this, I could then write the code within a matter of minutes. It also ensured that the interviewer knew exactly what was on my mind.

7. Demo interviews - I used https://www.p_r_a_m_p.com/#/ to do a bunch of coding interviews over a video call. No matter how many questions you have solved, when you are presented with a question you haven't seen before by someone who is staring at you, under time pressure, it's a whole different ball game. p_r_a_m_p is a free platform and these mocks helped me become comfortable with thinking while I was speaking.

8. Concentration, training your mind: If you had a bad interview, do not dwell on it. It will adversely effect other interviews. If your mind wanders, bring it back to the present moment. This is very important. I thought I had made a mistake during my first interview at the onsite. And I felt bad about it. But I tried to bring my mind back to the present moment and focused on the question I was asked at that moment.

9. Listen to the recruiter - The recruiter told me the types of technical topics that they'd examine me on (Algorithms, OOD etc) and that the LPs are as, if not more important. The interviews definitely seemed to follow this template. LC and other online posts had made me believe that I'll only be asked standard algorithms questions. But it turns out that what the recruiter said was more accurate.

10. No guarantees about which questions may appear: Except for one medium LC qs, the others were neither from the LC Amazon top qs list, nor from LC itself (or I can't find them on LC). I found this to be really strange and was actually a bit disappointed. I had practiced almost every question on the Top Amazon questions list and I was hoping they would ask me some so I could shine and differentiate myself from the others.

11. Develop a solid, sustainable leetcode habit for the future: After the interview, I bumped into a fellow interviewer who had ~15 years of experience and had just interviewed for an SDE 2 position. We discussed questions, and to my surprise, except for an additional Systems Design question, he was asked the exact same questions! Now, this does not mean that I would have cracked the SDE 2 role since the bar for that is higher. However, it suggested to me that until I reach a managerial role, I will keep getting asked the same types of questions in interviews. So I have already started preparing for the future. I am doing a deep dive on DP and Recursion which are my weakest areas. I have also started solving one medium level LC question a day. The point here is to exercise those brain muscles everyday so that you're never out of touch. My current experience has made me realize that cramming LC is painful and a sub-optimal approach

Conclusion:
At the time of my LC interview, my LC question count was as follows:
Easy - 55
Medium - 55
Hard - 11

I probably also solved about 25 questions from other sources. I had also solved every question here: https://leetcode.com/discuss/interview-question/344650/Amazon-Online-Assessment-Questions

I had been rejected straight away by almost every company I applied to. I had a phone screen (useful experience but rejected) with only one other reputed tech company, and I had no other onsite invitations.

From reading LC posts, I am aware that people have solved anywhere between 300 and 800 questions, and been through onsites at several companies before landing a FAANG job. Most people work really hard, so I think I got really lucky. LC has been my only constant companion these past few months and I'm truly grateful to the LC community. I hope this lengthy post can help others.

If I can do it, so can you. Good luck :)