Thoughts on Interviewing a Programmer Candidate
© Conrad Weisert, Information Disciplines, Inc., Chicago
28 October, 2001

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

Given the huge number of unemployed programmers and technical specialists, you're likely to be swamped with résumés the instant you announce an opening. Just doing a preliminary screening to eliminate the obviously unqualified is a daunting task, and you may well still be left with a hundred more-or-less qualified candidates for a single opening. What next? You can't possibly interview them all in person.

Use telephone interviews wisely and sparingly

Some organizations rely on a telephone interview for the next level of candidate elimination. Although an experienced interviewer may be able to infer a great deal over the phone about a candidate's maturity, communication skills, and attitudes, too many organizations instead try to conduct a quiz on various details of a programming language or tool, rather like one of those vendor certification exams.

Not only does such a quiz miss the point (some of the worst programmers I've ever known memorize such details and pass such exams easily), it may also give a negative signal to the most qualified and mature professional. I've had the experience myself in seeking contract work of being interrogated by a junior programmer who couldn't answer my questions about the basic structure of his project, but grilled me on the interpretation of a particular Active-X parameter.

WARNING: (addendum, June, 2006)

Another, even more serious problem with telephone interviews was reported in "The Wrong Man", Infoworld, January 23, 2006, p. 48. How do you know the voice on the telephone is really the candidate? Apparently, unscrupulous brokers and recruiters have been substituting highly qualified and articulate "ringers" for the actual candidate!

Telephone interviews should be conducted by a manager or senior technician, never by a prospective peer or junior staff member. Like face-to-face interviews they should focus on getting the candidate to talk about his or her achievements, goals, and opinions on current issues.

Examine work samples

The most reliable indicators of a candidate's competence and future performance are actual samples of his or her work. Such samples should include not only technical materials such as program code and design diagrams but also English-language reports and documentation.

A well-qualified candidate will be eager to tell you about past achievements and to show you the end products. If the candidate hasn't already volunteered to do so, ask for a package of material that he or she is especially proud of.

An inability or reluctance to submit work samples is a giant warning flag. Sometimes a candidate may claim that everything he or she has written or worked on recently is proprietary or classified and can't legally be copied. Don't accept that. Every computing professional has done something, perhaps back in college, that's unclassified and non-proprietary. If the candidate still stonewalls on submitting actual material, then ask him or her to describe any unique or creative aspects of some major accomplishment: a way of eliciting specifications, an innovative data structure, a time-saving algorithm, or a way of simplifying maintenance. If you can't get work samples or credible descriptions, you can surely eliminate that candidate with no fear of missing a super-performer.

Where should the candidate start?

Unless your organization's policies require initial contact with a Personnel or "Human Resources" department, the first person the candidate should see is the manager to whom he or she would report. Filling out application forms is hardly relevant until mutual interest has been established.

For a senior professional candidate, an off-site meeting can be a good ice breaker. Lunch at a quiet restaurant or club can get a relationship off to a good start. If you meet the candidate in your own office, be sure to start on time and keep yourself free of interruptions. Keeping the candidate sitting in the reception area for a half hour beyond the appointment time sends an ominous message: if that's the way they treat a candidate they're trying to impress, how will they treat me after I'm an employee?

Unless you know in advance that the candidate is extremely well qualified, making the rounds of key people in a half-day or all-day schedule is best left to a second, follow-up interview.

I usually allow an hour for an initial interview, but many of them take less. If you realize right away that the candidate is hopelessly unqualified, then politeness demands a minimum 20-minute investment. If you run out of conversation, a tour of the facility can fill time. Usually, however, you establish a good two-way rapport and an hour passes quickly.

A promising candidate should be introduced to at least one other person during the first interview. If you really want to make a good impression, introduce him or her to your boss. That sends a strong positive signal.

Questions and conversations

Like the telephone interview, a face-to-face interview should avoid quizzes on minute details. I've found that soliciting the candidate's views on important issues like the following not only reveal a lot about the candidate but also establish a friendly rapport between the parties:

  1. A current controversial issue in the field. As of late 2001, so-called "Extreme Programming" (XP) is the hottest topic, but if the candidate hasn't heard of it, you can fall back on such questions as:
  2. Some question that arises in real-world projects, such as:
  3. A professional awareness issue, such as:
  4. A career-directed question such as:

Experience shows that any candidate who draws a blank on most of the above is unlikely to contribute much in the long term, even if he or she has mastered every detail of some current tool, while a candidate who can speak intelligently and persuasively on these topics can easily pick up tool-specific details from reference material.

Last Modified June 16, 2006

Return to IDI Home Page
Return to Management articles