Why bother?

No one prepares for technical interviews. After all, why should you? Whether you’re a college student or a 20 year industry veteran, you’ve spent years honing skills that simply need to be demonstrated. You’re as ready as you’re going to be, and no preparation could be a substitute for the years of your life you’ve already spent developing your skills.

This is how most people approach technical interviews. Whether through arrogance (“I’m awesome, and don’t need to prepare”), fatalism (“there’s nothing I can do to prepare”), or ignorance (“preparing is an option?”), virtually no one does a thing to stack the odds in their favor during one of the most important inflection points in their career. Your job will likely determine where you live. If you get an offer with a low starting salary, it could take years to catch up to a higher one (if at all). And an impression that you’re a questionable hire vs. a good hire vs. a great hire can have a lingering effect on people’s perceptions, impact team assignment, opportunities, etc. This is not to say that you can’t overcome any or all of these obstacles, but why not give yourself the best chance right off the bat? The job application process, with the interview as the fulcrum, is one of your greatest points of leverage to define your compensation, opportunities, and career.

Interviews are different from real life

In normal, everyday life, you have an IDE to remind you of syntax. You have reference materials, coworkers, Google and StackOverflow if you need to ask a question. There are libraries to handle almost any permutation of basic data structures or commonly-used functionality. And knowing how to stitch together legacy code, libraries, and new code is the path to maximal effectiveness. The ideal interview would judge your ability to do all of these based on some objective criteria, while taking into account your specific set of technologies, skills, and experience.

The reality, of course, is very different. Interviewers tend to develop a standard set of questions over time, perhaps different ones for different levels of seniority, and ask them over and over. Yes, many interviewers will look for something on a candidate’s resume to ask about, but this is usually in addition to the standard set of questions. The reason for this is simple – it’s hard to come up with good interview questions, and it’s impossible to know how to judge performance against a new question until you’ve asked it a bunch of times. Also, over time you get better at asking a question, anticipating areas of confusion and paring it down to its essence. Seeing how a candidate responds to a question you’ve asked a hundred times gives you a lot of information. Asking a brand new question – not so much.

So you’re going to be asked one or more fairly generic questions that could be asked of a wide variety of people. Sure, if you’re going for a more specific position (e.g., 3D programmer) you may be asked domain-specific questions (e.g., “how do you find the angle between two vectors?”), but these will almost certainly be the interviewer’s standard domain-specific questions, not questions thought up specifically for you. Good interviewers will avoid gotcha questions about obscure language-specific details (“What are the five uses of the static keyword in C++?”), as well as generic brainteasers along the lines of “why are manholes round?” They’re going to try to ask questions that will be impossible for weak candidates, and easy (though hopefully interesting) for good candidates.

In sum, interviews are different from real life: you’re typically going to be on a whiteboard, not at a keyboard. Everything will have to come out of your own head – no one to ask, nothing to refer to. The problems will be different than those you’re used to, because they’ll have to be simple enough to do in a limited amount of time, interesting enough that you won’t think the interview (and by extension the company) is boring, and general enough that a wide variety of people could answer (which tends to converge to fundamental data structures/algorithms, simple library routines, and nonsensical algorithmic challenges). You’re going to be under a significant amount of time pressure, and will have the additional stress of being judged by someone who’s sitting three feet away.

This may sound like an incredibly unfair, inaccurate way of interviewing candidates for real-world effectiveness. And while you can find plenty of people writing that the interview process is broken, and apologists for the status quo, in the end it doesn’t matter. You don’t get to choose how you’re interviewed, and complaining about the interview process during the interview makes you look defensive and whiny, and will typically end the interview early. I’m not here to attack or justify the current regime – the goal of this blog post is to give you practical tools to help you succeed.

Reviewing the basics

Basic data structures and algorithms are favorite sources for interview questions. Arrays, Linked Lists, Binary Search Trees, Hash Tables, Sets, and Graphs show up all the time. If you’re asked to code something involving a particular data structure, and you don’t remember how it works, you’re immediately going to be at a disadvantage. Sure, you can figure things out from first principles, but this is going to slow you down. Furthermore, you have to remember that the interviewer has been asking this question for a while, and as such is going to be intimately familiar with the data structure. It will be hard for him or her to remember what it was like before they started asking this question, and they will be disappointed if you don’t understand something “so simple”.

One common refrain from candidates who realize that they’re failing, is that “normally, I would just use a library function for this.” The implication is that it’s unnecessary for them to understand how a specific data structure works, or to be able to implement it, because it’s a solved problem and they’re busy solving more important problems. When you find yourself making these kinds of excuses, you’ve already lost, and all you’re doing is annoying the interviewer. S/he isn’t asking you to program data structure X because that’s what programmers at his/her company do all day. S/he’s asking you to do it because it’s a quick way to explain a coding problem using a common language. I.e., it’s fast and straightforward to describe a problem that’s something along these lines: “implement a Linked List with the following characteristics…”

You’ll likely be asked about algorithms and complexity theory. If someone asks you to name a sorting algorithm, “bubble sort” shouldn’t be your first answer. Know what the big-O times are for different sorting, search, and graph traversal algorithms (and, ideally, how each works). Understand why you throw away constants in complexity analysis. Know what P and NP are. Unless you’re applying for a position in hard-core algorithm research, no one’s going to ask you to do in-depth complexity analysis of large pieces of code. Just know the different algorithms and how much time they take.

These days, the most popular book for data structures and algorithms seems to be Introduction to Algorithms. It’s a big book, and it will take you some time to get through, but it’s absolutely worth it. Not only because it will help you in the interview, but because it will make you a better programmer. You need to know this stuff, no matter what kind of programming you’re doing.

A special note on Hash Tables

Interviewers love these. Know how they work – intimately – and know the difference between Maps and Sets. You can frequently get from O(n²) or O(n*ln(n)) down to O(n) by using a Hash Table or Set, and understanding the tradeoffs (e.g., more memory vs. more time) can start an interesting conversation that will impress your interviewer.

Practice coding

Find some interview questions on the internet. Practice using paper and pen, with real code, not pseudo-code. Never be put in the position of having to apologize for not remembering syntax – compile and run your code if necessary. Practice coding all of the data structures and algorithms from the previous section. Practice coding even if you’re applying for a non-coding position. You might think that after five or ten years of management no one should care if you still remember how to sling bits, but someone’s going to ask, and you’re going to look like a fraud if you don’t know how to get started.

Shameless plug: I have two other posts related specifically to coding in the interview, which I would recommend reading as part of your preparation.

• Various Approaches to a Simple Interview Problem
• Screwing up the technical interview – common mistakes

I can’t tell you how often candidates ask me questions that betray a fundamental lack of preparation and/or interest on their part. “Where is your office located?” “What does your company do?” Asking these types of questions indicate that you really have no interest in the company you’re applying to. If you did, you would have spent 15 seconds looking them up online before the interview, or would have the courtesy to wait until afterwards to do so. You should know what the company does, have played around with its product (if possible), and have a couple of questions prepared. These could be highly specific to the company, or generic things like “tell me about your development/release/build process,” or “do you use a particular methodology,” or “what is your main technical challenge?” Just don’t waste everyone’s time by asking purely factual questions you could answer in under a minute with Google.

A final note

In late 2008 my startup was falling apart, the world economy was imploding, my wife and I had a new mortgage, and we were expecting our first child. I needed a job and a paycheck – fast – and there weren’t that many companies nearby I was interested in. I only had one shot to get it right, and I wanted to make sure I didn’t screw it up. So though time was tight, I invested time in rereading both Design Patterns and The Algorithm Design Manual before sending out resumes. I practiced questions I found online. I even reviewed a lot of the common brainteaser problems – even though I thought they were stupid – because I didn’t want one of them to knock me out of the running.

Preparing like this can take a lot of time, and the question inevitably comes up – is this really necessary? Shouldn’t you just be able to go in cold? Sure! You can do whatever you want. The question is, do you want to use The Hope Method™, or do you want to give yourself the best possible chance at a process that will ultimately determine how you spend the majority of your waking hours for the next couple of years?

Good luck!

Coda

If you found this post interesting, you might also like:

• Dissecting an interview question
• What not to do during an interview
• Why won’t anyone talk to me? What recruiters look for in a resume