Tech Interviews Demystified
Tech Interviews Demystified
2011-02-20 18:52:45 by Andrew Hitchcock G+

I encounter a lot of misconceptions about interviewing for software engineering positions at large tech companies. I’d like to spend a little time trying to debunk and demystify the tech interview for people outside the industry. I’ve interviewed at a few large tech companies and have performed interviews while working at Amazon. This article presents my own opinion and does not represent the views, opinions, or beliefs of my employers, past or present.

There have been a few articles in the mainstream media talking about the incredibly difficult interview practices of large tech companies and the bizarre questions they ask. It is natural that people who’ve never experienced a tech interview find them bizarre and intriguing (“they make you write code on a whiteboard!?”). Just as I have no idea what a non-tech interview is like (having never done one), most people have no idea what actually happens in tech interviews. Note: Some of the details presented only apply to large tech companies (such as Amazon, Google, etc.) and not small companies or startups.

Background

Before we begin I need to explain a little bit about the tech industry. The tech world has a high degree of meritocracy. There is a huge range in ability of programmers and this range has to be taken into account when hiring.

There is a vast range in programmer ability. Good programmers can be many times more effective than bad ones. In fact, bad programmers can have a negative productivity because they slow down the rest of the team. Also, the difference between good and bad programmers isn’t a matter of speed. There are some problems that mediocre programmers would never be able to solve given all the time in the world, or their solution would be too riddled with bugs to be useful.

Companies receive many more resumes than they have open positions, but most of these people are unqualified for the job. This is exacerbated by the fact that good engineers will almost always have a job and when they want a new one will selectively apply for the few companies they are interested in. On the other hand, bad engineers will be sending their resume to dozens of companies in the hopes that one will hire them. Even after receiving more applications than positions, companies will still be left with open positions because not enough applicants met the hiring bar of the company. You don’t want to hire people that will make your company weaker.

The Process

Interviewing is very expensive, so the overall goal of the interview process is to eliminate unqualified candidates as quickly and cheaply as possible. The secondary goal is usually selling the engineer on the company. Talented engineers will often have multiple options of where to work, and the interview process is one of the most direct means engineers have of evaluating the company before joining.

The tech interview process generally begins with phone interview, often referred to as phone screen. These occur after the resume pool has been narrowed to remove the undesirables and blatantly unqualified. The goal of a phone screen is to narrow the candidate pool even further by eliminating candidates who are unlikely to pass the onsite interview. Phone screens tend to involve a brief discussion of past experience, followed by a few technical and coding questions, and finishing with a brief Q&A with the candidate (letting the candidate ask the interviewer questions about the company, etc.). The answers to the coding questions are either read over the phone or written in an online collaboration tool like Google Docs that lets the interviewer watch as the candidate types. A phone screen usually lasts between 45 minutes to an hour.

After one or two phone screens the company will have enough confidence to bring the candidate on site to be interviewed, meet the engineers, and see the office. If you are from out of town they will fly you in and put you up in a hotel. The candidate will meet with one or two engineers at a time, for usually between 45 - 75 minutes. This is a full-day event, with somewhere between four and eight meetings. During this the candidate is asked to code on a whiteboard.

All of the interviewers (both phone and onsite) write up their feedback to exchange thoughts. Depending on the company, either the original interviewers or a hiring committee will review the feedback and make a hiring decision. The hiring committee will want to reach consensus on a candidate. Interviewers with a strong opinion on the candidate one way or the other will try to convince the other members of the committee. It is not at all uncommon for members to switch their preference during the course of discussion. If a member is unsure or on the fence, they should fall on the side of not inclined to hire.

Goal Of The Interview

The final goal of the interview process is to determine whether a candidate should be extended an offer. The decision is made by assessing the candidate on a number of attributes, such as knowledge, experience, and intelligence. The question becomes: how do you quickly assess the candidate on these criteria with a high degree of confidence?

Questions are designed to be open-ended in order to give the candidate a lot of room to show their ability. Programming questions in particular will often have multiple solutions, ranging from a relatively easy and straightforward one to perhaps several that are trickier but better. The candidate is encouraged to start with the easy answer, which they should get fairly quickly, and work their way toward the better ones. Along the way they might go on small tangents. Throughout this, the interviewer watches for signals that indicate strengths and weaknesses. These signals can include knowledge of a certain class of problems or the tendency to get stuck on little details that are irrelevant to the problem at hand. Dead ends and false starts don’t necessarily reflect badly on a candidate because they allow the interviewer to see the candidate’s thought process.

Interviewing is a very inexact process and there are many things which can throw off an interview. The candidate might be jet-lagged and under-caffeinated, or the interviewer might be in a grumpy mood. Interviewing is expensive but hiring the wrong person is even more expensive, so companies tend to fall on the side of caution when hiring. It is much better to have false negatives than false positives. This uncertainty prevents a precise ordering of “good” companies or “good” candidates. You might get an offer from one company and then not get an offer from the same company a year later. Engineers shouldn’t take it personally when they are not hired, because there are any number of factors which could lead to a negative.

The Questions

In my experience, tech interview questions tend to fall into three categories. The first category are coding questions, where the candidate is given a high-level specification and is asked to write the code that implements it. This is usually done on a whiteboard or piece of paper in the language of the candidate’s choice. At the simple end is a question like FizzBuzz where the interviewer tells the candidate precisely what the program should do, and the candidate must write the code to do it. Side note: The FizzBuzz question is somewhat famous because it is super simple and easy to explain, but many programmers absolutely fail when trying to answer it.

The second type of question involves algorithms. The interviewer gives the candidate an abstract problem and asks them for an algorithm that solves it. For example, given a list of numbers in sorted order, determine whether it contains a specific number. These questions will often overlap with coding questions, where the candidate must first find the algorithm for a problem and then write the code that implements it. Sometimes the interviewer will ask the candidate to think through a couple possible algorithms before asking for the code.

Finally, some interviews include design questions. The interviewer will describe a very high-level problem and ask the candidate to explain roughly how they would solve it. For example, the interviewer might ask the candidate to create something like the Facebook news feed and the candidate would have to describe the components they would use to implement it and how they interact with each other. This might include a database to store all recent status updates, a means of updating statuses, and a way of seeing all of your friends recent statuses (perhaps weighted by some relevancy metric).

If a candidate is going down the wrong track, the interviewer will often give hints about in the direction of the solution. There is no value in watching a candidate struggle with something that will never work. On the other hand if a candidate is helped out of a rut you can watch to see how far they get and where they start to struggle again. The goal of an interview isn’t to stump the candidate but to observe them.

Articles in the mainstream media often give supposed sample questions from tech companies as an illustration of how crazy and bizarre tech interviews are. They tend to attribute the questions to the current tech company media darlings (in the ‘90s that was Microsoft, in the early ‘00s Google, and more recently Facebook). The questions listed are often wrong or inaccurate. No one asks brainteaser questions like “Why are manhole covers round?”. If you get asked that in an interview, that should be a strong indication that you shouldn’t work there.

On the other hand, one article I read gave the following question as an example of the types of “bizarre” questions tech interviewers ask. “I’m thinking of a number between 1 and 1000. How many guesses would it take you to find the number I’m thinking of if I can only tell you if my number is higher or lower than your guess?” This is not bizarre at all and is actually describing a fairly basic computer algorithm called binary search. This is covered in introductory computer science courses. The way you solve this is by always guessing in the middle of the possible numbers, so the first guess would be 500. Every guess decreases the number of possibilities by half, which means the answer to that question is the base-2 logarithm of 1000, or slightly less than 10. Determining the running time of an algorithm is called complexity analysis and is an important skill for good programmers to have.

I could give examples of some of the more challenging tech interview questions I’ve received, but I’m going to decline out of respect for the companies I’ve interviewed with.

My Experience

It turns out I don’t actually have that much interview experience, but I have interviewed at some of the large tech companies that are often discussed in the media. Here are the companies I’ve interviewed with in roughly chronological order. Bold indicates that I was extended an offer.

While I only have a 50% success rate, I feel all of the interviews have been interesting and rewarding experiences. Each company has a different interview culture. I’d say my Google interview was the most technical and well organized. I’ve heard lots of Google horror stories (mostly from a few years ago), but my experience was mostly pleasant. Amazon also asked interesting technical questions. In my opinion, Apple and Facebook generally asked the easiest questions.

In terms of length, Apple was by far the longest at a grueling eight hours (including lunch). Google and Amazon tied at around 4 - 5 hours and Facebook was around 3 - 4. The worst organized was my original Facebook interview a couple of years ago. They had much improved when I interviewed there again recently.

Conclusion

I hope I was able to demystify the tech interview process. It really isn’t that weird, at least for those of us within the computer science ghetto. In summary:

Thank you Will and Jeff for reading drafts of this article.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.