Amazon SDE-III Interview Experience
I recently gave an interview for the Amazon SDE-III role for the Alexa UK team and would like to share my experience in this article. Currently, I’ve just started leading a small team of 4 engineers and my main objective of giving the interview was to evaluate where I stand in the market and see if I can meet Amazon SDE-III even though I know it's too early!
Hiring Process
- 1 Technical Screening Round
- 5 Onsite Rounds
- Final Offer
Initial Screening (60 minutes)
I applied on LinkedIn and within a few days, I received an email from the recruiter regarding a screening interview. Once I confirmed the dates, the screening round was set up with an SDE-III engineer. All the tools used during the interview were mostly in-house. The round started with a basic introduction and the interviewer quickly gave an overview of what the next 1 hour would look like. He started with a string-based coding problem that I could straightaway identify and gave a solution using the Trie data structure. I had to code up a Trie from scratch and completely solve the problem. He found some minor bugs which I could instantly fix and he was happy with the code. He then improvised the same problem to expose it as an API and asked me to scale it to handle lots of requests. We talked very high level about running multiple instances of trie as a service, load balancing and caching requests, etc. After this, he briefly touched upon some behavioral questions where he asked me about situations where I made a wrong design choice. Overall, I think did very well and I was confident that I would make it to the onsite rounds.
After a few weeks, I got an email from the recruiter saying I’d cleared the screening and they want to schedule my final virtual onsite interview which is going to be 5 rounds. The final rounds were set in a way that you will go through all 5 rounds even if you screw up one of them. I was pretty unlucky due to the ongoing pandemic as I missed a free visit to the UK. On the other hand, due to the timezone difference and some inefficiencies in their scheduling process, it was quite a lengthy process to get the dates for my final interviews. Ironically, it took almost 2~3 months for my final interview after the screening round.
Note: I’ve signed an NDA which doesn’t exactly mention not disclosing the questions that were asked. AFAIK, NDA is meant to protect any confidential information like top-secret projects that the interviewers might discuss with you or any proprietary tools or technology that I might get exposed to during the interview. So to be on the safer side, I won’t give away the coding questions or system design questions that were asked.
Onsite Round 1 (60 minutes)
This round was with my hiring manager. He started with a pretty good introduction to the role and also gave me time to give details of my past experiences. This was followed by Amazon’s infamous behavioral interviews which target competencies in their 14 Leadership Principles (LPs). For the next 45 minutes, the interviewer greeted me with a barrage of behavioral questions. He wanted to know about instances from my past projects where I displayed lead-level capabilities. He was very attentive and often would ask me more in-depth questions about certain situations. He also wanted to hear very specific scenarios which are very hard to recollect and also something I never faced in my career. At a very high level, he touched upon (although there were more drill-down into my examples):
- situations where I gave direct feedback to peers.
- situations where you mentored junior engineers.
- situations where you worked on a challenging project with lots at stake.
Last 10~15 minutes, he asked me about a system design problem which most likely is something that he was building or already built. I didn’t like the idea of getting thrown a system design problem in the final minutes of the interview. It took at least 5 minutes to get the requirements clear enough to start putting things together. Due to lack of time, I couldn’t go deeper into one of the main use cases and I hurried into the approach I would take while the next interviewer was already on the call and waiting. If I had time I would have given him several better options but what a bummer! Seriously, who on earth designs systems in 5~10 minutes?
Onsite Round 2 (60 minutes)
This round was with a principal product manager and was not technical. I greeted him with a very detailed introduction and after that, it was full-on behavioral interview questions. At a very high level, he touched upon:
- situations where I worked on an ambiguous project.
- situations where I had to convince the entire team to break the norm and do things differently.
Honestly, this guy was so much fun to talk to and being a scrum master myself, I’ve worked a lot with product managers which made it a very smooth conversation. He drilled down to see how deeply I knew the product I’m building from a business perspective. Even though he had just asked me 2 questions, I walked him through more scenarios I faced while narrating my story. As a result, I think it would have covered way more leadership principles than he intended to analyze. Overall, I felt this round went extremely well and was probably the one I truly enjoyed out of all.
Onsite Round 3 (60 minutes)
This round was with a principal engineer who appeared to be a bit tough from the start. As usual, the first 30 minutes were focused on behavioral questions. For some questions, I gave the same example I used in the previous interviews. At a high level he touched upon:
- situations where you had to go beyond your comfort zone.
- situations where you had to persuade your stakeholders to take a different approach.
In the last 20 minutes, he gave me a coding problem which was a medium-difficulty leetcode problem based on linked lists. I explained the approach clearly and got buy-in but I failed to write a fully working code. There were several edge cases to be carefully handled which almost took my entire time. There was a brief period when I went completely silent and I realized that I started losing rapport with the interviewer. Overall, I felt I did well with the behavioral questions but was not able to complete the coding problem and I didn’t communicate what I was writing.
Onsite Round 4 (60 minutes)
This round was with an SDE-III and he was a very calm and polite guy but I felt he wasn’t a confident interviewer. As usual, the first 30 minutes were behavioral questions about past projects. I repeated the same example from previous rounds and I did mention that to him. At a very high level he touched upon:
- situations where you disagreed with your team’s solution and convinced them with yours.
- situations where you had to make a difficult decision. (I skipped this question since I couldn't recollect)
- situations where you had to agree with the team even though you disagreed.
In the second half, he asked me a medium coding problem which was a slightly modified form of a typical DP question. I asked him lots of questions to make sure I clearly understood the problem. I was confused about whether it was a Greedy or DP, so I discussed it with the interviewer. He asked me to write the code for the greedy solution but I found a bug a bit too late and realized this was a pure DP problem! The interviewer said greedy would work for most cases and asked me what my DP code would look like. I gave a verbal explanation of how I would write the code and he was happy with that. I felt it went OK except for the last-minute realization that I took the wrong approach to the coding problem.
Onsite Round 5 (60 minutes)
This was my final round and it was again with an SDE-III. Again, the first 30 minutes were dedicated to behavioral questions from past projects. He asked if I needed a chance to discuss any high-impact projects which I might have missed in previous rounds. He touched upon the following scenarios:
- situations where you had a simple fix for a complex problem.
- situations where you had an innovative idea that made its way to production.
In the second half, he gave me a hard leetcode graph problem. While reading the problem statement I thought it was a backtracking problem and started discussing a solution that later looked more like a DFS. I had a solution that could theoretically solve the problem but I still couldn’t come up with a working code. The interviewer gave some hints and pointed me to some bugs in the code. After the interview, I realized that a BFS approach would have saved me although DFS was more intuitive. Looking back at this round, I think this was most likely the Bar Raiser round and I felt like I didn't raise the bar here!
Final Offer
The recruiter assured me that they will get back to me in 5 working days regarding the offer. On the 4th day, the recruiter called me and said that they won’t be making an SDE-III offer and that if I’m interested they could find me an SDE-II opening. The recruiter mentioned that I did well with the LPs but my performance was not at an SDE-III bar for coding and system design. I was pretty disappointed with the system design part since it was asked when there were just 10 minutes left on the clock and gave this feedback to the recruiter. In all the coding rounds, I came up with the right solutions but I couldn’t code them up on time since I was a bit rusty with them as I hardly practiced before the interviews. The funny part is I solved even harder problems when I interviewed with them for an SDE-I position:
I rejected the idea of finding me an SDE-II position and the recruiter asserted the same since she felt I would have a faster route of boomerang back as an SDE-III if I continued my current role in Agoda rather than getting converted from SDE-II to SDE-III within Amazon. I believe if I had kept grinding leetcode for a few weeks before the final interviews I would have most likely ended up with the offer.
Key Takeaways
Although the delay in scheduling interviews was terrible, the final interviews were very thorough and worth the experience. I got the chance to talk to a bunch of very senior-level engineers and managers. Almost all of them appreciated me being an ex-amazonian and they liked the fact that I knew how Amazon hiring works. It made me feel like they do respect boomerang recruits and I think it would have given me a slight edge. I felt time management was a bit off in almost all the interviews and don’t know whom to blame — me or the interviewer.
Also, for the behavioral rounds, interviewers wanted examples that had org-level impacts and not ones with a small scope. To clear these rounds, you need to have authentic stories at the tip of your tongue and if you try to fake them, you most likely end up having trouble facing the counter questions from the interviewers. I recommend practicing the STAR technique for such interviews and educative.io has a well-crafted course on this. The best strategy is to have 2 good stories per LP and I felt it’s ok to repeat some stories if they apply to multiple LPs.
Clearing the system design rounds, most of the knowledge comes with experience. If you just mug up some system design content before the interviews, you would most likely go all over the place. I’ve been reading engineering blogs, watching tech talks, and reading good books for the past 1 year and I’ve also tried to apply them to my work.
For coding rounds, it’s a bit unfair to ask lead-level engineers to write code to invert a binary tree or reverse a linked list when time is limited. Even when you are a junior engineer you will never face such situations. To make matters worse, you are supposed to do it on a notepad-like tool that has no autocompletion or syntax highlighting! The only way to clear these is by exhaustively practicing data structures and algorithm questions for at least a month or more on websites like leetcode, hackerrank, etc. There are a lot of debates going on around such interview practices in the developer community. I feel the emphasis should be given to how we approach the problems and the ability to think out loud.
