Saturday, August 16, 2008

Interviewer tips

I have been on the receiving end of a lot of technical interviews, and it surprises me how often companies let their employees do a bad job. I have come up with some suggestions for running such a session based on that experience. I have experienced every one of the problems that the following tips are meant to solve:


Read the resume before the interview - you should not be studying it for the first time with the candidate sitting right in front of you. This is one of my biggest pet peeves. Waiting until the interview to learn about the candidate demonstrates a lack of seriousness and professionalism.

Be prepared. You should know in advance what questions you're going to ask, and think about various ways the conversation could go. The candidate is sacrificing a lot to be there, so don't waste the candidate's time while you struggle to think of something to talk about.

Coordinate with other interviewers so you don't make the candidate repeat himself unnecessarily.

Arranging the Interview

Let the candidate know what the schedule is in advance. The candidate should know:

  1. how long will he need to be on site

  2. how his time be divided

  3. who will be meeting the candidate, and what their jobs are (not just titles)

  4. what each part of the interview is meant to accomplish

Actually, before you tell the candidate all of that, you should make sure you yourself know all of that.

If two people will be sharing a time slot, they need to coordinate their questions so they both get the information they need without conflict.

Don't put a candidate with more than 2 interviewers at a time. For some, it may be intimidating, and it also poses a bit of a coordination challenge to get everyone's questions out of the way.

Minimize the number of on-site visits necessary. For local candidates, you can ask for two visits before making an offer. For candidates traveling more than 40 minutes, find a way to do everything in one visit. If you can't get all the necessary people squeezed in, reschedule, or redefine "necessary." Be mindful of rush hour and other timing concerns. If the candidate travels more than 100 miles, you need to compensate him for expenses. It is fine if you need the candidate to come on-site to sign offer paperwork, and the candidate can come back to if he wants to discuss an offer in person.

Consider weekend interviews. It's less convenient for your interviewers, but chances are the best candidates are very busy people. Being flexible is worth it. You can always offer your interviewing employees an extra day off to make up for it.

When setting up the interview, make sure the candidate has an immediate contact number in case they run into last-minute problems like a flat tire, getting lost, or the like.


Someone needs to take charge of basic logistics: greeting the candidate, getting beverages and/or snacks, getting interviewers to the interview room at the right time, arranging breaks, and showing the candidate out at the end. This can be a recruiter, a hiring manager, or one of the potential co-workers, depending on who is available.

Consider recording interviews. That way, interviewers who aren't in the room for that particular session can still assess the candidate. Of course, you should get permission, and don't penalize candidates who are reluctant to be recorded.

Reserve a clean, quiet room with a whiteboard, a table, lots of paper and pens, enough chairs, and whatever supporting equipment is necessary, before the candidate shows up.

If you're going to keep the candidate in a single room for the duration, pick one with a window.

If you are going to have the candidate write code on a computer, find out in advance what their preferred editor is: emacs, eclipse, vim, netbeans, etc. If it's a common one, have it set up for them. If it's an uncommon one, ask them to bring a USB memory key with the appropriate environment already set up.


Pay attention to the candidate, even if it's a pair interview and the other person is talking. No Blackberries allowed.

Remember that this is a personal interaction like any other, so don't be rude. It is not your opportunity to pontificate on your opinions. Don't be dismissive of what the candidate says.

Be sure to introduce yourself properly; don't just dive in.

Do not bad mouth your company, other companies, former employees, management, the recruiters who work for you, XYZ technology, or really, anything at all.


The candidate should write code. On a whiteboard is acceptable, but some things may be better done on a computer.

It is acceptable to assign "homework," some programming problem that the candidate should do on their own time. Aim for something that would take a good candidate between 45 and 90 minutes. Anything that takes more than 3 hours is too much to ask; anything that takes less than a half hour may be too easy to be useful. In my experience, these problems are usually posed with a blank slate for an answer. I suggest you consider instead giving the candidate existing code and ask them to extend it in some fashion. It is rare in the real world that you write fresh, new code, so your questions should reflect that.

Avoid brain teaser type questions. Too many of them rely on a trick, and it can often seem like you're giving a candidate a hard time just because.

Along with that, make sure it is apparent how a question relates to the qualifications and responsibilities of the job. If it's not apparent, explain the connection.

The following questions tend not to be all that useful, and are probably not worth the time:

  1. What was a project that you worked on that posed a particular challenge?

  2. Where do you see yourself in 5 years?

  3. Why do you want to work here?

  4. Rate yourself in X

Instead of the first one, ask about specific challenges posed by specific items on the resume (you read the resume, right?). Instead of the middle two, ask what the candidate wants to do. The last one is your job.

Don't ask questions that give you no useful information. For example, "what do you do when you have a technical disagreement with a co-worker?" There is only one right answer, and everyone knows what it is. The information content of any answer is zero.

The best questions are open-ended. That does not mean vague. If the candidate doesn't get your meaning, explain yourself using different words, and describe the sort of answer you are looking for.

Have more questions than your candidate has time to answer. Sometimes they've heard your questions before (perhaps even the day before), and you don't want to be caught flat-footed.

In some cases you want to spend the whole time going over just one problem. Choose a deep and subtle problem. That way you see if your candidate thinks deeply and subtly. You don't get as much information as you think from a variety of questions that you only explore shallowly. Nevertheless, as suggested above, make sure you have backup questions, as if your candidate for some reason can't get over the initial hump, you may be spending a very awkward 45 minutes (or however long).

Test your questions on co-workers to make sure they're neither too hard nor too easy. It will also help your delivery; often, candidates will be unable to answer a question not because they're dumb, but because the interviewer asked it badly. In interviews, like anything else, practice is beneficial.

You should always give the candidate the opportunity to ask you questions, but don't use that as an excuse to avoid your duty to inform as well as evaluate. Anticipate common questions and answer those preemptively. Some of these are about the company and only need to be mentioned once. Others are per person, and each interviewer should discuss them. Imagine every candidate asks the following questions:

  1. How big is the company?

  2. What is the breakdown of employees among divisions and roles?

  3. How does the company earn its money? e.g., advertising, subscriptions, licensing fees, etc.

  4. What has growth been like?

  5. What exactly is your role?

  6. How long have you been there?

  7. What do you like about working there?

  8. What don't you like?

  9. Where did you work before?

After the Interview

Hiring decisions should be unanimous. If someone's opinion isn't important enough to block the hire, that person doesn't need to be interviewing. I had hiring manager willing to override his team to hire me a few years back. That is flattering, but I don't think I'd want to work for him.

Always always always contact the candidate after. Never leave anyone hanging. You also want to find out how well your company presented itself. If a candidate is leaving with a bad impression, you want to know it so you can fix it.

Let the candidate know within a week what the next step is. You don't have to commit to an offer, but you do need to let him that you're making progress, and that responding is a priority. A week is the maximum; try to respond within 2 business days.

Labels: ,


Post a Comment

Subscribe to Post Comments [Atom]

<< Home