Sponsored Link •
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.
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.
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.