Acing your Programming Job Interview

The Interviewer

The first thing to know about a programming or tech job interview is that you're likely to be interviewed by other programmers--the people you will work with. Although you'll likely make a quick pass through Human Resources to give over your background, the final decision will often be made by your future (or not so future) coworkers.



This gives you a great opportunity to evaluate the company--do you want to work with these people? Do they seem to know what they're doing? Can you get along with them--can you learn from them? They're working on the newest projects, so you can actually ask them about the work and the working conditions.

One advantage of looking at the interview as both a chance to be evaluated and to evaluate is that you can maintain a good balance of power in the room. You don't need to feel as though you're the one who's under all of the pressure. The company, too, needs to impress you enough for you to want to work there. Don't let this become cockiness, but you don't need to let the interviewer run you over and leave you hanging out to dry. If he's a jerk, you don't want to work there anyway, right?

Presentation

The more quickly you can establish a rapport with your interviewer, the better. Always be sure to respect the interviewer, but don't be afraid of being yourself. If they don't like your manner, you probably don't want to work for them. At the same time, there are standards that you are expected to maintain during an interview--don't talk about your last drunken adventure, medical ailments, or the like.

Dress based on how you are expected to dress. If the company tells you that they don't care if you wear a suit or not, then you probably can take it at face value. If they don't make it clear that they don't mind what you wear, better to play it safe and risk overdressing with a suit than to risk underdressing. If nothing else, you don't want what you wear to distract you during the interview. You don't want to be wondering, "do I look all right?" Just take care of it in advance and don't sweat it.

Your Resume

Be prepared for your resume to be a point of discussion. You can practice explaining the different portions of your resume in advance, but don't script things too much. An interview should flow somewhat loosely and you don't want to end up embarassing yourself by repeating information that you already told the interviewer in reply to another question.

The Interview Questions

Aside from the general background questions based on your resume, you're likely to be asked some more technical or brain-teaser type questions.

Brain Teasers

Brain teasers are probably the most intimidating type of interview question. There's a sense in which your ability to answer some dumb riddle is associated with your IQ. It's also tricky to prepare for a brain teaser because there are no set-in-stone techniques you can apply.

Nevertheless, it helps to be prepared for them. There are a couple of types of brain teasers: the ah-ha question, the deductive reasoning problem, and the more open-ended questions.

Generally, a good strategy is to show your problem solving skills. Even if you don't get the answer, you can salvage the situation by showing that you understand how to approach a problem.
  • State your assumptions
  • Ask intelligent questions
  • Talk out loud, show your thought process
  • Draw pictures or diagrams
We'll look at each of these techniques later in the article in the categories to which they apply.

Ah-ha Questions

Example: Why are manhole covers round?

An ah-ha questions are the all-or-nothing variety: you either know the answer or you don't. There's no thought process that would really lead you to being able to solve the problem. If you're lucky, the answer comes to you in an "ah-ha" moment, hence the name. If you get asked one of these questions, you might want to re-evaluate whether the company is the kind of place you want to work at. These questions are mean-spirited and rarely useful.

Deductive Reasoning

Example: Given 8 balls, 7 of which weigh the same amount, in three weighings, how can you find the ball with a different weight?

Deductive reasoning questions are those that probe your ability to work within a set of basic assumptions toward an answer. When asking these questions, the interviewer will look as much at your process of solving the puzzle as at your final answer. It's best to show good problem solving skills: use diagrams and think out loud. This way, even if you don't get the answer correct, it's not a total loss.

Even better, talking aloud and drawing diagrams will generally help you find the answer. It also helps your interviewer see whether you are on the right track--maybe you're just making an incorrect assumption about the problem. Stating assumptions early can help a lot, both to clear up problems and create a better image of what's going on.

Open-Ended Questions

Example: How would you move Mt. Fuji?

Open-ended brainteasers aren't really designed for you to come up with one right answer. The goal is to see how you solve a vaguely defined problem. In fact, they might not even be brain-teasers so much as design questions. At any rate, the goal is again to show that you know how to approach a problem.

Since the problem is open-ended, you absolutely must clarify assumptions by asking the interviewer--or state your own. Try to gain information first and only then begin to follow a strategy designed to lead to the actual solution. If you run into trouble again, continue to ask for clarifications or state new assumptions; that's part of the point of these questions: how do you deal with a complex situation? The answer is usually to gather information and make intelligent simplifying assumptions.

Code Questions

Example: Write a program to reverse a linked list.

You should expect a variety of programming questions--you may get some that are in some ways closer to brain teasers than programming problems--these will ask you to come up with an algorithmic solution to a problem.

A good way to prepare for this type of question is to practice. You can practice on a variety of programming challenges on this site, or come up with your own. In general, you should realize that you'll be working on either paper or a whiteboard. You might want to take some time to practice writing code without the use of an IDE or compiler.

Your interviewer knows that without a compiler, or the ability to test your program, you may make some mistakes. If you're writing a piece of common code, these will matter more than if you're doing something more original. Keep calm, and don't worry too much about making a small mistake like leaving off a semi-colon or using the wrong variable name. These things happen when you don't have a keyboard, syntax highlighting, or other tools.

Whatever you do to prepare, be sure that you understand basic computer science ideas like data structures, including linked lists, recursion, and string manipulation. The questions are usually fairly simple programs that can be tricky under pressure if aren't familiar with the underlying ideas--things like strcpy, how to insert data into a linked list, or how to compute all the possible permutations of a string.

Language Questions

Example: When is a virtual destructor necessary?

You may be asked to explain some concept of a language--for instance, you should be familiar with why it's important for a parent class to have a virtual destructor. These questions are usually straightforward and designed to test your knowledge of a language. Don't be afraid to say, "I don't know" or, "I don't remember"--especially if it's a language that's not necessary for the job.

Other Questions

You may also be asked to do things like design a system or come up with test cases for what appears to be a simple piece of code. Keep your cool, and remember what interviewers are testing: your ability to think. The same principles that apply to brain teasers apply to design questions and other open-ended questions.

If you have to write test cases, the key is to be methodical. You'll definitely want to write down everything and clarify the assumptions about what you are certain works. For instance, does your test case need to rely on helper functions? If so, do you need to test them? Be thorough and methodical.

No Hard Questions?

So what happens if they don't ask you hard questions? Does it mean they don't respect you? Probably not. They didn't bring you in to the interview for nothing--why would they waste their time? Don't panic if you're not getting hard questions or your interviewer spends a lot of time talking about the company instead of about you. It might well mean that they're sold on you already (lucky you) and are trying to convince you that you want to take the job. This is probably the best you can hope for at a job interview, so be sure not to blow it. Don't act cocky or volunteer any information that makes it look like you have no idea what you're doing. Your guard may be down in this situation, so remember to stay alert.

Parting Advice

The best advice is to enjoy the interview. You're fortunate enough to meet some really smart people with interesting problems to ask you to solve. Talk some shop about the latest and great technologies you're learning about. Ask them what they've been learning. Swap brain-teasers. Look at the interview as a way to get to know someone, not just as a way to convince them to hire you. Of course, this requires that you have the technical skills to impress the interviewer; you're (probably) not going to steal a job offer just because they like you. But by looking at the interview as something to enjoy instead of fear, you can avoid the nervousness that can eat away at your ability to respond and keep a cool head when asked the difficult questions.