Amazon Interview Preparation

It's been about a month since my last post and a lot has happened. For the last three weeks I've been in northern Japan doing training with the Japanese Ground Self Defense Force (JGSDF) and have been swamped with schoolwork and studying for upcoming interviews. The biggest news out of all of this is that one of those interviews is with a large company that I'm very excited to have gotten an interview with; Amazon.

Amazon has one of the most successful online retailing websites on the planet and is constantly striving to innovate and improve themselves at such a high rate that they're constantly hiring new talent. Along with the scheduled time for my first interview, the email included two attachments of subject matter I should brush up on. The topics included typical programming concepts like data structures, algorithms with big O notation, operating system concepts, distributing ideas, SQL, and coding abilities.

This might seem like a lot for the average person who either does a small amount of coding or not all but after four years of college these are familiar. When I was browsing through the list when I first received the email, I was skeptical of my abilities and felt like I wouldn't be able to code a lot of these topics. I imagined myself in an interview where they asked me question like, "please code a merge sort where we pass you an array with up 300 elements" and me staring in silence for a while. Interviews are supposed to be quick, fast, and hardly have any silences in them. You want the interviewer to know that you're not only confident in your abilities but you can also make coding a social experience.

I hit the whiteboard in my local library the next day and went down a list of interview questions that I found on glassdoor.com. The first question that I read was, "design a program that takes a integer value up to 999 and outputs it's English equivalent. So if I entered 124, it would output one hundred and twenty four." I've done a problem like this before but staring at the board, I had no idea how to start. The interview books I've read said to ask questions about the problem, so I asked if I would error check, test for non-integers, and if I was just writing a function. Since I was the interviewer for this problem, these questions didn't help.

I was a little frustrated with myself because I felt like I was such a stronger programmer than this. When I worked on projects for the iPhone, it just came naturally; I need a class for these objects, and I need to create lists here, but coding a simple problem was so much different. After a few minutes of self anguish I decided to consult the internet for the sage advice of senior programmers who've all been through the same problems. The first result that popped up after I typed in "Programming Interview Amazon" was a video from Careercup.com

If anybody who's reading this unfamiliar with what Careercup does or it's back story, it was founded by Gayle Laakmann McDowell who was a head recruiter for some of the biggest software companies in the United States and started the company. The intention of the company was to provide references for those applying for jobs in the programming field including books such as Cracking the Coding Interview, and the Google Resume. The video had McDowell with a interviewee as he attempted to solve a problem by following a set of guidelines.

The pace of the interview made me feel immediately more comfortable because this "perfect example" was relaxed. The interviewee wasn't a hot shot who immediately responded with perfect answers and the suaveness of Harrison Ford but just a 20 year old in a hoodie who would stop and think about his problem and ask questions. I'm sure that this seems obvious to those that have interviewed but undergraduate school doesn't teach you what to expect in an interview and the only other interviews that I've done were for customer service which required well rehearsed lines to pass.

He would ask questions about the problem and it's implications and would begin talking out loud about some possible solutions while giving them pro's and con's as he went. At the end of this process McDowell would ask wether he felt those were the best approaches or what the benefits of one over the other was. I found myself answering over the candidate because it seemed like a class discussion now and I felt far more comfortable with that. After that he decided what approach would yield the best results and started to code while talking through it. The best part about the coding process was that he had minor syntax errors through the code but McDowell didn't care and mentioned as long as they weren't too big or numerous, she only cared about the functionality of the code. Coding without an IDE can be intimidating because you're not sure if you're making mistakes or not.

To anybody who is planning on going into their first interview for programming just remain calm and do what you've been doing for four years: code. If you have a passion to code, you probably have a lot of valuable skills that employers are looking for and they only need you to understand the basics of the process in order for them to develop you into a productive programmer. Good luck to future coding interviews and I'll be sure to keep posting about my upcoming interviews and results.

-Joseph Priest