Summary
Recognizing good programmers among job applicants is not easy. This article contains
interview techniques, garnered from a recent summit on writing better code, that can help you
can find the most qualified programmers for your project.

In January 2003, I attended a Writing
Better Code summit in Portland, Oregon, organized by Scott Meyers and Bruce Eckel.
At the three-day summit, 15 people gathered to discuss code quality and how they
could improve it. Throughout this discussion, one theme was clear: good code is
written by good programmers. Therefore, one great way to improve the code quality
within an organization is to hire better programmers. The trouble is, recognizing
a good programmer among a pool of job applicants is not easy.

Finding good programmers is hard because good programming is dependent on much
more than just knowledge of programming language syntax. You need someone who,
despite wearing striped pants with a polka dot shirt, has a good sense of taste in
OO design. You need someone who is creative enough to find innovative solutions to
problems, yet anal retentive enough to always line up their curly braces. You need
someone who is humble enough to be open to suggestions for improvement, but
arrogant enough to stand firm and provide leadership when they are the best person to provide it. How
can you tell all this about a stranger by spending 30 minutes with them in a
conference room?

The final morning of the Writing Better Code summit, Bruce Eckel announced he was
"hijacking" the meeting. Bruce wanted each person at the table to share his or her
interview techniques. He wanted to know how we recognize a good
programmer in an interview. In this article, I highlight some interview techniques
discussed that morning. If you have more ideas or would like to discuss any
techniques presented here, please post a comment to the News & Ideas Forum Topic,
How to Interview a Programmer.

Explore an Area of Expertise

Although various interview methods were tossed about that morning, a few
fundamental techniques emerged from the discussion. For example, rather than
simply look for expertise and experience in the exact area in which the candidate
will work, you should look for general programming talent and ability. One way to
explore and judge a candidate's talents is to explore an area of their
expertise:

Dave Thomas: Hire for talent. One of the biggest mistakes
companies make is to recruit from a shopping list: I need a programmer with six
years Java, three years Oracle, and two years EJBs. The world changes, so you need
to hire folks who change with it. Look for people who know computing, not
necessarily particular narrow niches. Not only will they adapt better in the
future, they're also more likely to be innovative in the present.

Chris Sells: To identify how good the candidates are technically,
I let them choose an area in which they feel they have expertise. I need them to
know something well, and I ask them about that. I ask them why. I want them to
know why something in their area of expertise works the way it does. I'm not
necessarily after an expert in the area I need. If they learned why in the past, I
have confidence they'll learn why in the future.

Have Them Critique Something

Another technique involves the importance of creating a dialog with the candidate.
To get to know the candidate's talents and personality, you can't merely ask
questions that have short factual answers. You have to find a way to engage a
conversation. To stimulate dialog, you can ask the candidate to critique some
technology:

Josh Bloch: I ask candidates to critique a system or platform
that we both have in common, preferably something they will use on the job.
For example, I might ask, "What parts of Java don't you like and why?"

Pete McBreen: I give candidates samples of our current code and
ask them to explain and critique it. This gives me a sense of their skills, but
also lets them know what they can expect.