Interviewing at large tech companies is different from interviewing at a startup. Here are some tips about how the interview process differs, and some specific advice for how you can prepare.
Programmers who have spent a lot of time reading startup-focused blogs and news sites may have come to expect verbal phone screens and interviews followed by a trivial coding exercise (“reverse this string”) and maybe a probationary hiring period, because that’s what makes sense for small companies. Startups don’t get that many candidates in the door, and can afford to hire someone as a contractor based on a good feeling and terminate them if they don’t work out. Also, startups generally want to hire someone yesterday and need that person to “hit the ground running”, meaning that they need that person to start contributing immediately.
Large, well-known tech companies have a different problem. They have a huge number of candidates applying for each position, and they really want to hire extremely smart people who will make tremendous contributions over time, allowing for top notch graduates who don’t necessarily have a lot of experience with particular technologies, while keeping out candidates who are not really good at programming. Large companies are also litigation targets, so firing someone is not as easy. As a result of that, hiring someone is not as easy to do.
This difference shows up in the way that large tech companies interview candidates. The classic puzzle questions (made famous by Microsoft, and imitated by many since then) are designed to measure intelligence via problem solving ability. Whether they ever accomplished that is debatable, but this sort of interviewing is now easy to prepare for because there are so many answer guides available online.
A more respected technique of interviewing programmers that has survived is the coding interview. In my career I have found that most of the companies that required me to code in an interview were better overall (nicer companies to work for, more successful, with smarter co-workers) so I am happy when a company I’m interviewing for asks me to write some code.
However, in my experience as an interviewer at several companies, programming job candidates are generally unprepared for this type of interview. I suspect that this is because they expect to just have to answer questions verbally and then get hired, proving their skills afterward. As I mentioned above, this may make sense for startup companies due to the lower volume of candidates, but for large tech companies, this is not feasible. (Similarly, for smaller companies growing quickly, such as a startup that just got a VC cash infusion that is ready to staff up, hiring a bunch of promising candidates and then having your existing programmers look over their shoulder for the first few weeks may not be feasible due to the sheer number of people they’d have to keep an eye on.)
When I was a college freshman studying electrical engineering, I was shocked at the workload in the engineering classes that every engineer had to take, as compared to some of the general prerequisite classes or more specific EE courses. I later learned the term “weed-out course”, which refers to a course designed to both teach the material and to “weed out” (eliminate) students who were not prepared to work hard and really pursue that major.
Larger companies need to use coding exercises in interviews as a “weed-out” technique, to eliminate the weak candidates as early as possible. So if you’re trying to get hired at a large tech company, you need to get over the idea that you can talk your way into a job, and prepare yourself for the somewhat unnatural challenge of coding during an interview.
Coding Interview Advice
Working on a small, unfamiliar problem with no language reference, no API reference, no autocomplete, and no error highlighting really flusters some people. This is a hurdle that you will have to overcome in order to demonstrate that you are in fact a good programmer.
Specifically, you should develop the ability to write a correct 10-20 line program body on a whiteboard, a piece of paper, napkin, etc. under time pressure in your preferred language. Practicing in ink on paper, maybe using a sharpie or dry-erase marker on a legal pad, and then typing it in and trying to compile and run it, is great practice.
Also, as a programmer your job is to talk to people and understand the problem that your code is supposed to solve. This is incredibly important in real programming work, and is a gigantic topic in itself (e.g. are the requirements you’re being given really the requirements or are they someone else’s partial solution to the real problem, which you can negotiate?). Not surprisingly, if you solve the wrong problem in your interview, you won’t give a good impression even if your code solves some other problem that the interviewer doesn’t care about.
So, make sure that you fully understand the problem; repeating it back to the interviewer and maybe rephrasing it is a great way to do this. Write down lots of notes and scribbles (tables, diagrams, maybe the exact text of the question as the interviewer said it) until you completely understand the algorithm and corner cases before jumping to code. The last thing you should do is to write out the code, and it should be obvious to you and the interviewer that you already have solved the problem before you do so. Remember how your math teachers insisted that you show your work instead of just writing down the answer? This is a good way to think about coding interviews: you need to show how you got from the question to a particular solution; this will help you avoid misunderstanding the question, gives the interviewer a chance to correct any confusion you have about what the problem is, and will force you to really think through your solution. You don’t want to be distracted by looking around the room for an eraser or trying to improve the penmanship of your curly braces while you scribble some half-baked code on the whiteboard and then constantly erase and rewrite it as you think. Finish thinking through your solution in detail, then write down the code.
Finally, practice with friends in mock coding interviews. If you’re lucky you will have other programmer friends who can benefit from switching places and letting you be the interviewer, and you may be able to learn how to be a better interviewee from watching them make mistakes. :)