Amazon Development Centre Interview Experience

In a previous post, I spoke about my application experience for an Amazon internship. Here's how the interview stage went.

Read about the application stage in my previous post.

Interview Stage

On November 4th I received an email inviting me to attend one of three interview sessions. The sessions were all in the afternoon, at the office I was applying to in Edinburgh. They were spread over a week (Friday, Wednesday, next Friday), and were to last around 3 hours. I chose the first available one as it was convenient, but also because I knew they were likely to hire the people they liked first. I was given the following brief about what to expect:

"The interviews will cover technical topics such as algorithms (including efficiency/'big O notation'), data structures, operating systems, object orientation and architecture. Non-technical questions, based around the Amazon Leadership Principles and your experience, will also be asked."

Preparation

As you can see, all fairly standard interview stuff, with some added things about specific Amazon principles. I spent most of my time reviewing interview questions in Cracking the Coding Interview, as well as reading about other peoples experiences while interviewing at Amazon. I spent a small amount of time refreshing myself about the projects I had worked on, and what I put on my CV. I also looked at the Amazon Leadership Principles, but didn't spend too much time on relating my experience to them.

I thoroughly recommend that anyone going for a technical interview be confident in implementing basic abstract data structures such as single and doubly Linked Lists, and binary search trees in a C or Java-style language as well as some basic common algorithms such as merge sort, and also be very familiar with manipulating arrays. As mentioned in the previous post about the application process, my code test was quite heavy on array manipulation with tight space and time constraints.

Another very important thing to be very familiar with is the basic workings of common processes. For example, being able to confidently answer "what happens when you enter a URL in a browser". Having a decent grasp on every point of the chain is important, an answer to that question may start off with some basic text validation that it is a valid URL, then there's a DNS lookup to find the IP of the entered domain, then the browser uses that to send off an HTTP request to the server located at that IP. That server returns a response depending on the header of the request, which the browser typically reads and interprets as HTML. This HTML is parsed and rendered to the user, and related files are requested in new requests.

This is all basic knowledge, but actually was a question during my interview at Amazon. My preparation finished the night before the interview as I took a train to Edinburgh to stay the night. This was so I could be calm, collected and on-time to my interview and wouldn't have the faff around with trains a couple hours before the interview.

Interview Day

I arrived in the area of the office around 20 minutes early, and hung around across the road until 5 minutes before the interview was due to start at 1pm. I was taken to a room filled with sofas in which another applicant was sitting. We introduced ourselves, but it was quite clear that we were both very nervous. Over the next 15 minutes two other applicants arrived. One applicant was from as far away as London, but one was studying in Glasgow like myself, and the other in Edinburgh. We all signed Non-Disclosure Agreements about anything private we saw on screens, walls, or overheard in conversation.

We were given a presentation about the Edinburgh office, and shown what teams they have. We were given a group tour of the offices, let in on a few office jokes (including ever shrinking pool table sizes). This all took around an hour. After that it was down to individual interviews.

We were assigned an interviewer each, who was to interview us for around an hour, then we would swap and interview with a different person for another hour. All the interviewers appeared to be senior software engineers for various teams. The two interviews were both on technical software engineering topics, and didn't seem to be particularly separated by content.

From what I remember of the first interview, I was asked a couple questions about object-oriented programming including sketching out a class diagram for a couple different systems. I was also asked about what design patterns would fit, and what kinds of things one should look to extract from a class diagram (such as different interfaces).

I was also presented several opportunities to talk about my experiences, and was probed about specific situations I had to deal with, such as serious bugs I had fixed, problems with other people's code, and improvements I had made.

I wasn't asked to write much code, although I could if it helped demonstrate a point. I was asked about tools I had used, such as version control, and what types of applications I had worked with (front-end, back-end, desktop, command-line, etc).

I was also asked about a single Amazon Leadership Principle. I was told what the principle was about, and asked to relate my previous experience to this principle and demonstrate I had used it before. The interviewer was quite vague about the principle, and slightly struggled to fully explain the principle. He wasn't surprised when I struggled to relate my experience with it (especially since the principle was targeted more towards management).

The second interview was a bit more practical. I was given a code snippet to look over and fix errors with. The errors were fairly simple: uninitialised variables, incorrect variable names, an off-by-one error - you get the picture. I was also told to write a simple bash script which parses a text log file and finds an entry for a specific date. My solution was simply a grep command for that date.

At the end of this interview there was quite a lot of time spare, so the interviewer showed me the type of application he works on, and I asked him several questions about the software engineering process at Amazon - about whether they did code reviews, how they handled tickets, and what team structure was like. Obviously many of the answers to these questions were "it depends on the team", but I felt it useful to get an overall insight into how the Edinburgh office works.

At the end of the interviews, we met with our Amazon recruiter who asked if we had any questions, I did not as at this point I was exhausted. I grabbed a bottle of water and went on my way back to Glasgow.

Overall, I was moderately positive about the interview. I thought it went well, but not amazingly - but I must have done something right as I received an offer about a week later, which I have accepted. I very much look forward to joining them in the summer.

If you enjoyed this post, please check out my other blog posts.