Amazon SDE III Interview Experience (2023)

I recently did an interview for the Amazon SDE-III feature for the Alexa UK team and would like to share my experience in this article. I am currently leading a small team of 4 engineers and my main objective in conducting the interview was to assess where I stand in the market and see if I can handle Amazon SDE-III, although I know I still can is too early.

• 1 round of technical evaluation
• 5 rounds on site
• final offer

I signed up for LinkedIn and within a few days received an email from the recruiter about an interview. After I confirmed the dates, the selection round was scheduled with an engineer from SDE-III. All tools used during the interview were mostly internal. The session started with a basic introduction and the interviewer quickly gave an overview of what the next lesson would be like. Started with string based codingProblemwhich I was able to identify immediately and gave you a solution using the trie data structure. I had to recode a trie from scratch and completely solve the problem. It found some small bugs that I was able to fix right away and I was happy with the code. He then cobbled together the same problem to expose as an API and asked me to scale it to handle many requests. We've talked about running multiple test instances as a service, load balancing and caching requests, etc. at a high level. After that, he briefly addressed some behavioral questions, asking me about situations where I had made a bad design decision. In general I think I did very well and I was confident that I would make it to the local rounds.

After a couple of weeks I received an email from the recruiter saying they had approved the selection and wanted to schedule my final virtual interview on the site which would be 5 rounds. The final rounds have been designed so that you beat all 5 rounds even if you fail one of them. I was very unlucky to miss a free UK tour due to the ongoing pandemic. On the other hand, due to the time difference and some inefficiencies in the planning process, getting my final interview dates was quite a slow process. Ironically, it took almost 2-3 months for my final interview after the selection round.

monitoring: I signed an NDA that doesn't specifically mention the secrecy of the questions asked. AFAIK, NDA intends to protect sensitive information like top secret projects that interviewers discuss with you or proprietary tools or technology that you are exposed to during the interview. To be safe, I will not disclose any coding or system design questions that have been asked.

This round was with my hiring manager. It started with a good introduction to the role and also gave me time to build on my previous experience. Then came Amazon's infamous behavioral interviews, which focus on the competition14 Leadership Principles(LP). For the next 45 minutes, the interviewer greeted me with a barrage of behavioral questions. He wanted to know in which cases I had demonstrated managerial skills in my previous projects. He was very observant and often asked me more in-depth questions about specific situations. I also wanted to hear very specific scenarios that are very difficult to remember and also something I've never experienced in my career. It played at a very high level (although there was more detail in my examples):

• Situations in which I gave direct feedback to colleagues.
• Situations in which he mentored young engineers.
• Situations where you worked on a challenging, high-stakes project.

In the last 10-15 minutes you asked me about a system design problem that you probably just built or have already built. I didn't like the idea of ​​having a system design problem in the last minutes of the interview. It took at least 5 minutes to get the requirements clear enough to start compiling. Due to time constraints I couldn't get into one of the main use cases and quickly decided on my course of action while the next interviewer was already on the phone waiting. Had I had time I would have given several better options but what a bummer! Seriously, who the heck designs systems in 5-10 minutes?

This round was with a senior product manager and was non-technical. I greeted it with a very detailed introduction and after that it was full of behavioral interview questions. At a very high level he played:

• Situations where I worked on an ambiguous project.
• Situations where I had to convince the whole team to break the norm and do things differently.

Honestly, this guy was a lot of fun talking to, and being a scrum expert myself, I worked a lot with product managers, which made the conversation very fluid. He did some research to see how well I know the product I'm building from a business perspective. Although he had just asked me two questions, I walked him through additional scenarios I faced as I told my story. As a result, I think I would have covered many more leadership principles than I intended to reiterate. Overall I felt this round was extremely good and probably the one I really liked out of all of them.

This lap was with a lead engineer who seemed a bit harsh from the start. As always, the first 30 minutes focused on behavioral issues. For some questions, I gave the same example I used in previous interviews. At a high level he played:

• Situations where you had to leave your comfort zone.
• Situations where you had to convince your stakeholders to take a different approach.

For the last 20 minutes it has been giving me a coding issue which was a moderate leetcode issue based on linked lists. I explained the approach clearly and got approval, but couldn't write fully functional code. There were several edge cases that needed careful handling, which cost me almost every time. There was a brief period when I was completely silent and realized I had started to lose my relationship with the interviewer. Overall, I felt I did well on the behavioral questions, but I couldn't solve the coding problem and communicate what I was typing.

This round was with an SDE-III and he was a very calm and polite guy but I got the feeling 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 mentioned it to him. At a very high level he played:

• Situations where you disagreed with your team's solution and convinced them of yours.
• Situations where you had to make a difficult decision. (I skipped this question because I couldn't remember)
• Situations where you had to agree with the team even when you disagreed.

In the second half he gave me a medium coding task that was a slightly modified form of a typical DP question. I asked him many questions to make sure he understood the problem clearly. I was confused as to whether he was a greedy or a DP, so I raised it with the interviewer. He asked me to write the code for the greedy solution, but I spotted a bug too late and realized it was a pure DP issue. The interviewer said that greedy would work in most cases and asked what my DP code would look like. I verbally explained to him how I would write the code and he was happy about it. I thought everything was fine except that I realized at the last minute that I had approached the coding issue incorrectly.

This was my last round and it was again with an SDE-III. Once again the first 30 minutes were spent dealing with behavioral issues from previous projects. He asked me if I needed the opportunity to discuss a high-impact project that I might have missed in previous rounds. Played in the following scenarios:

• Situations where you had a simple solution to a complex problem.
• Situations where you had an innovative idea that went into production.

In the second half I had a difficult leetcode graphics problem. After reading the problem description I thought it was a backtracking problem and started discussing a solution which ended up looking more like a DFS. I had a solution that could theoretically solve the problem, but I still couldn't find any code that would work. The interviewer gave some tips and pointed out 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 on that round I think it was probably the bar raiser round and I felt like I didn't raise the bar here.

The recruiter assured me that he would contact me within 5 business days regarding the offer. On day 4 the recruiter called me and said he would not be making an SDE III offer and that if interested he could get me an SDE II position. The recruiter mentioned that I did well on the LPs, but my performance wasn't up to an SDE III bar for coding and system design. I was quite disappointed with the system design part when asked when it was only 10 minutes on the clock and I gave this information to the recruiter. In each round of coding, I found the correct solutions but couldn't code them in time because I was a bit rusty from having hardly practiced before the interviews. The fun part is that I solved even harder problems when interviewing her for a position at SDE-I:

I turned down the idea of ​​looking for a job at SDE-II and the recruiter said the same as he thought I would have a quicker route back to SDE-III if I continued my current position at Agoda instead of SDE to switch :II to SDE-III in the Amazon. I think if I had worked with leetcode for a few more weeks before the last few interviews, I probably would have been done with the offer.

Although the delay in scheduling the interviews was terrible, the final interviews were very thorough and the experience was worth it. I had the opportunity to speak to several senior engineers and managers. Almost everyone liked the fact that I'm a former Amazon and that I know how Amazon recruiting works. It made me feel like they respect boomerang recruits and I think that would have given me a small advantage. I found the time management a little bad in almost every job interview and I don't know who is to blame, me or the interviewer.

For the behavioral rounds, too, the interviewers wanted examples with an impact on the organizational level rather than those with a small reach. Clarifying these rounds requires authentic stories on the tongue, and if you try to fake them, you'll likely struggle to cope with interviewers' counter-questions. I recommend practicing the STAR technique for these types of interviews, and education.io has oneCoursein this. The best strategy is to have 2 good stories per LP, and I've found it's okay to repeat some stories if they apply to multiple LPs.

Aside from rounds of system design, most knowledge comes from experience. If you just grab some system design content before interviews, chances are you'll go everywhere. I read and watched engineering blogstechnical conferencesand happy readingBookslast year and have tried to apply them to my work as well.

It is somewhat unfair for coding rounds to ask high-level engineers to write code to invert a binary tree or invert a linked list when time is limited. Even as a young engineer you will never be confronted with such situations. To make matters worse, you have to do this in a Notepad-like tool that doesn't have auto-completion or syntax highlighting. The only way to get rid of them is to practice data structures and algorithm questions on sites like thorough for at least a month or morelelet-Code,Hacker Rating, etc. There is a lot of discussion in the developer community about these interview practices. I think the focus should be on how we approach problems and the ability to think out loud.