Tips for code interviews

If you are a programmer, then you inevitably spend some time every few years doing a bunch of interviews for a programming job. You probably are going to have to do some code interviews as part of that, which means you'll be doing coding interviews many times throughout your career.  Allow me to help.

Since I previously wrote a post on why I prefer coding interviews, I thought I'd follow up with some tips for doing well at these things.  I suppose it can also double as a list of things to look out for if you do code interviews.

The problem is, coding interviews, done well, are a pretty accurate gauge on your ability to code.  If your coding is rusty, it's hard for that not to show up during an interview. Still, there's a few things you do to help your chances.

• If you are given a choice in languages, choose the most high-level language you are relatively good at.  So if you code mostly in C++ and sometimes in Python, use Python.  The coding will be faster and easier. If you aren't a regular user of any high-level language, though, better stick with what you know.
• Know your chosen language well.  Know the standard data structures - sets / hashtables / lists / arrays.  If it's C++ or Java, know how to use Generics.  Know the features of the latest version.  If you tell me you primarily program in Java, but haven't used any version over Java 1.4, I'll feel you just don't care very much about programming.  On the other hand, if you tell me about upcoming features in C++11, I'll be pretty impressed.
• Know when to use each type of data structure.  In Java, if you don't care about ordering, and items shouldn't have duplicates, don't use a List. Use a Set.  I am supremely annoyed when candidates just use LinkedLists for everything.  In fact, using it for anything is usually a bad sign.  Make sure you understand why.
• You don't have to necessarily complete the whole program in order.  Feel free to write the main structure of the code, then fill in the more complicated bits later.
• Go back and refactor code if possible.  Don't leave your code in a messy state if you think you have time to fix it.
• Test out your code on an example.  I can't stress enough how important this is.
• Choose meaningful variable names.  Not just good practice stylistically, but you are less likely to trip yourself up.
• If the algorithm you are coding could be done in several different ways, choose the easiest way to code up first.  Then if you have time you can change it or just explain to the interviewer how to improve it.  It's better to have complete suboptimal code than incomplete optimal code.
• Make sure you can figure out the running time of simple programs.
• When physically writing on a whiteboard, leave as much space as possible between consecutive lines.  You often will have to go back and insert things in between lines.  Having to erase or write somewhere else and have an arrow pointing to the insert point will make things look confusing, which is bad for your comprehension.

Now, if you feel you are rusty or just a bit slow at coding, these tips won't help you too much if you can't actually code up the problem in question in time.  What you can do, though, is train this skill by doing coding exercises.  There's a few sites that offer small coding exercises, such as CodeSprint or  Project Euler.  Do these as much as possible before your interviews.  Don't just wait until you are actually about to interview.  Start as soon as possible.  

If you have any other suggestions for doing well in coding interviews, please share in the comments!