Acing the Coding Interview

If you’re a computer science / information systems / computer engineering student, or if you’re working as a software engineer / developer / programmer, chances are that sooner or later you’re going to run into a coding interview: you’ll be given a problem and will be expected to solve it, face to face. Even if you can write great code, there are a few things you can do to increase your chances of impressing an interviewer. While different companies use a variety of styles, here’s some advice that should apply generally.

Before the Interview

Read up on the company and the position before you walk in the door. You don't have to go crazy - a few minutes spent searching the web can give you good results here. Find out about the languages and technologies they use - if you know some of them, leverage your strengths here. If you don't, try to fill the gaps as much as you can before the interview. You might not be able to learn everything you don't know by the interview, but learning even just a little can go a long way - it demonstrates your interest in the job and shows you're willing to learn new things.

Understand common data structures. You should know how common ones work, and what they're useful for. It's good to know lists, hash tables, and binary trees, and how to use them to solve problems - they come up a lot in coding questions. Brush up before your interview if you don't remember them.

Review Big-O notation. You should be able to evaluate your code and talk about your thought process. It's reasonably common for an interviewer to ask you to analyze the computational complexity of your solution.  

Know some sorting algorithms. It's important to be able to explain at least one sorting algorithm; insertion sort and merge sort are pretty good ones to know. It's definitely good to be able to write the code for those - try to find some solutions in your chosen language or the language you'll need to use and practice them. More than once I've had interviewers simply ask me to write a sorting algorithm, so a little preparation here might really help you in the interview.

Practice. One of the most important things you can do (and one thing that many candidates skip) is practice; so many candidates spend years honing their technical skills but won't spend an hour to practice their interviewing skills. An easy way to do this is to find a friend and ask each other technical questions. Even if it's a question you already know the answer to, it's definitely useful to practice articulating the answer and explaining your solution. Project Euler and Google CodeJam are good places to start for practice questions.

Be prepared to write code a few different ways. Some companies will let you use a laptop, some ask you to scribble a solution on paper, and some will have you write it out on a whiteboard. Make sure you can solve the problem with any of those... you don't want the first time you solve a problem on the whiteboard to be in front of the interviewer.

Before You Answer

Pick the right language. The interviewer might ask you to use a specific language, but if he or she doesn't, make sure the language you want to use is OK. If you're most comfortable with one particular language, use that one if you can. Don't try to get adventurous and attempt to answer questions in a language you're just starting to learn - put your best foot forward here.

Ask questions. It's important to ask lots of questions to make sure you understand what the interviewer is looking for - don't make assumptions without verifying them (even small things). Approaching a problem the wrong way can really derail your solution, and missing some small details can invalidate your whole approach. Make sure you're on the same page with the interviewer.

Answering the Question

Communicate. After you've been asked a question, talk through your thought process and communicate with the interviewer. If you need a minute to think, just tell the interviewer that. The interviewer can't read your mind - keeping an open line of communication will help the interview flow. If you get stuck, explain why you're stuck. It might help you figure out your problem, or it might prompt the interviewer to give you a hint - either way, keep communicating.

Draw a picture if you need to. Sometimes it helps to draw pictures or sketch out a solution before starting to write code - drawing a picture can help to make sure that you and the interviewer are on the same page about expectations. If you're still not sure how to start, write down some test inputs and explain how you'd approach the problem for them - that might help you to find the right way to code the solution.

Brute force isn’t always bad. If you're not confident about coming up with an optimal solution for the question, it might be a good approach to start with a brute force approach and iterate to improve it. Even if you don't know an elegant solution immediately, you'll at least have something to show if you start with the obvious solution.

Keep an eye on the time. Don't rush if there's still a while before your interview is over - pace yourself. Let your interviewer prompt you if there are unknown time constraints.

After You Answer

Be ready to ask your interviewer a question or two. If you do a bit of research about the company you're interviewing with you should be able to come up with some questions, but here are some ideas if you don't come up with anything:

• Is the question you just asked a typical problem you solve here? How is the real job different?
• What's your favorite thing about working here?
• What's a typical day like in your role?
• What's something about your job that bothers you regularly?
• What about your current role has helped you grow in your career?
• Other than this company, what other companies are you interested in?
• If I ultimately want to do ______, how might this job help me do that?
• What's the hardest problem you're facing right now?

Make sure you thank your interviewer for their time. It's a formality, but one that's noticed (especially if you skip it).