Guide to Tech Interviews

I’ve been interviewing people for programming jobs for five years and I’ve recently gotten a look at the interview process from the other side. Here are some suggestions for acing tech interviews.

Read Cracking the Coding Interview (available for free from here, Google Play, and various other places). It is incredible, it basically covers every questions that a sane interviewer could ask. That’s really my main suggestions, but here are a few other supplementary tips:

Pre-Prep

Go onto Glassdoor and see what people say about the interview process at the company. Often they’ll list questions they were asked and interviewers are not that creative: if there are any questions listed whatsoever, make sure you can code them up perfectly. Google, too, can be helpful: “<company> phone screen” or “<company> interview” often will give you other possible questions.

Once you’ve plumbed the internet, time to refresh the other stuff you might be asked. For data structures, make sure you know linked lists, trees, tries, heaps, sets, and hashtables.* For algorithms, make sure you still remember dynamic programming (I certainly didn’t).

*The answer is always “hashtables.” Use them early and often, they almost always make the problem easier.

Non-Technical Questions

You might be a brilliant coder, but you also have to come up with comprehensible answers stuff like, “Tell me about something you’ve debugged recently” or “Tell me about a project that shows your strengths.” I wasn’t sure how to prep for these questions in a general way, but Cracking the Coding Interview had a great system: make a table of the projects you’ve done and possible questions and fill it out. For example:

	Project 1	Project 2	Project 3	Project 4
Most challenging
What you learned
Most interesting
Hardest bug
Enjoyed most
Conflicts with teammates

This pretty much covers all of the “soft” questions you’re likely to get. I did mine using a private Noodlin board, which worked out well for me (but a Google Spreadsheet would probably work fine, too):

Note that mine’s a bit sparse and that’s fine. It’s actually even sparser than it looks, as a lot of the stories in the same column are very similar. I’d say come up with at least two projects for each row, though.

Then practice your responses out loud! At least for me, saying things out loud is very different than saying them in my head. I’d go off on random tangents complaining about things and then realize how it sounded halfway through.

Keep your responses short (1-5 minutes) and talk about your coding. For example, you could say: “All of the code was in a giant switch statement, so I abstracted it all out into <data structure> and then traversed it.” A bad answer would be “I used <some framework> and <hot new tech>.”

Prepping for Technical Questions

For the technical interview, try to answer all of the questions in Cracking the Coding Interview without looking at the solutions. If you can’t even get started on a problem, see if you can see any similarities between it and a more common problem. How would you solve it brute-force? There are answers at the back of the book if you’re really stuck.

For all of the questions you can get, come up with alternate answers. Can you optimize for space? Can you optimize for time? Generally you can find a fast solution that uses lots of space and a slow solution that uses very little. If you did it recursively, could you do it iteratively (and visa versa)?

Make sure you’re actually coding up these answers, too. TopCoder is pretty good for this. Google around for SRM challenges covering specifc areas, or check out the problems linked to in the algorithm tutorials. However, you can also just code up answers in a plaintext editor and run them on your own test cases.

Before the Phone Screen

Try to schedule interviews for when you peak: e.g., I can barely function before noon, so I tried to schedule all interviews for the late afternoon or evening (super handy if you’re applying to places in CA from NY).

Once your interview is set up, make sure you’re all set 15 minutes before the prearranged time. If they didn’t tell you it would be a tech interview, assume it will be and have your computer ready with internet connection. Have a cellphone with hands-free headset (I got this one on Amazon for $10 and it worked fine).

Now get a nice, big, pad and write down some questions you’d like to ask them. Leave lots of free space on the pad to take notes. Try to keep taking notes and doodling while they’re talking: you absorb more info when you’re doodling than when you’re just listening.

Make sure you’re somewhere you can spread out, so you can lay your phone beside you and quickly switch between laptop and pad as needed. On one phone interview, I accidentally hit a button on my phone and started recording the conversation (I was so embarrassed and had no idea how to turn it off).

Finally, drugs! I make a cup of coffee about 15 minutes before the interview and drink most of it, but leave a little. I’ve found it’s nice to have a booster (or at least something for my mouth to do) if I get totally stuck on a question.

A minute or two before they’re scheduled to call, take some deep breaths, relax, and try to imagine you’re expecting a call from someone who you really like and with whom you enjoy talking about technical stuff (maybe a coworker or friend). They’re just calling to hear about the cool stuff you’ve been working on and get some tech advice on a problem they’ve been having.

Executing the Tech Questions

During the interview, take the coding in several phases:

1. Understand the question. Hopefully it will only take a few minutes to clarify what they’re asking, but make sure you have a clear mental model. Having interviewed tons of people, the difference between people who really grasp the problem and those that do not is staggering.
2. Get the algorithm down. This is the tough part.
   • As you think of edge cases, make notes about them (or clarify with the interiewer). You might realize you have to handle overflow 20 lines in, but have forgotten by line 30. Just add a // TODO: handle overflow and then make a pass through after to take care of all the TODOs.
   • If you aren’t sure you can keep the logic straight, make comments. For instance, for a connection pool problem, you might do something like:

     Connection* getConnection() {
         // Check if pool is empty
         // If so, create new connection
         // If not, return connection from pool
     }
     

     This lets your interviewer know what you’re thinking even if the code doesn’t come out right (and it turns the question into kind of a fill-in-the-blank exercise for you).

   • If you get to a part that is more complex than the surrounding area, just make it a function call, at least for the time being. For example, something like this:

     if (valid) {
         counter++;
     }
     else {
         while (x[i] == '') {
              int j;
              for (j = counter; j >= 0; --j) {
                   // oh crap, this is going to be even more complicated... 
              }
         }
     }
     

     should be turned in this:

     if (valid) {
         counter++;
     }
     else {
         counter += chompNulls(x, i);
     }
     

     Then go write chompNulls.

3. Check your work. There is an almost irresistable temptation to say “okay, done” when all you have is a first draft. Once you’ve coded the last line, walk through your code twice before saying “done.”
   • First, check edge cases. Can you pass in null? Zero? Empty string? Negative numbers? Really short strings? Long strings? Answer at beginning/middle/end? You can probably find most bugs with a few quick checks here.
   • Make sure your method signature still makes sense. Often you realize halfway through that you’re returning something different than you thought or you don’t need a parameter.
   • Go through any test case they gave you, make sure it works. (If they gave multiple, you don’t have to go through them all, just choose one.)
4. Report when your done. Keep your interviewer in the loop the whole time, of course, but it’s especially important once you stop programming and you’re just sitting there in silence (checking things over). “Now let me check the case where n is negative” will go a long way towards keeping the interviewer happy.

   Then let them know “Okay, I think that should do it” once you’re done (please don’t just sit there in silence).

The Long Haul

For all-day in-person interviews, be prepared to be mentally exhausted. If you have the time/dedication, try doing a “mock interview” where your friend asks you technical questions for five hours. Use this to identify when you start getting tired and what you do when you’re tired: stop checking edge cases? Make too many assumptions about the problem? Get cranky with the interviewer?

Whatever your response is to mental exhaustion, try to figure out ways to counteract it: take a 5-minute break after each interview (ask to use the restroom if they schedule them back-to-back), drink coffee, or boost your blood sugar with a quick snack.

Also, if you aren’t familiar with coding on a whiteboard, try answering some Cracking the Coding Interview answers longhand before you go in. Make sure you leave lots of whitespace between lines, even when you don’t thing you’ll need it. I’ve found that if I concentrate on spreading things out, my brain unconsciously leaves more space where I’ll need to add things later (e.g., checking for edge cases, adding more conditions to an if, etc.). Your milage may vary.

Finally, don’t get too hung up on making things flawless. In five years, I’ve had three interviewees that did perfectly. However, I’ve recommended hiring tons of other people (and I certainly didn’t perform flawlessly… more on that in my next post about the questions I was asked). So, don’t stress out too much if you mess up.

Afterwards

Take care of yourself. Do something special to celebrate getting it over with (even if you don’t feel like you did that well). Resist the urge to follow up with the company, try to put the whole thing out of your mind. You probably won’t be able to, but remind yourself that there is nothing you can do and concentrate on other things. (Also, feel free to write thank you notes, but I’ve never known a programmer at a geeky company who gave two shits whether you did or not.)

If you get a rejection, it really hurts. If you’re at work, take a few minutes to yourself to recover. Go out for lunch, call a friend, or just walk around a bit. Remember that you’re awesome, you did everything you could, it’s their loss, and it’s probably their flawed interview process’s fault (hint: everyone’s interview process is deeply flawed).

If you get an acceptance, congratulations! They love you. Now you just have to figure out what to do next. For negotiating (and more general interview/resume/cover letter) advice, I highly recommend Ask a Manager.

Find this useful? Please comment/upvote on Hacker News!