Stay in this business long enough, and sooner or later you will be called upon to contribute to the interview process for recruiting a programmer to your company or team. As a manager, you may be solely responsible for the hiring decision.

You want to hire someone who will be an asset. Yet you are given a ridiculously small amount of time with the candidates in order to make your selection. How can you be confident that you are hiring the right developer?

I'll level with you. You can't be sure you are choosing the best candidate using traditional interviewing techniques. Some very good developers don't interview well. Sometimes a brilliant developer shows up on an “off” day and doesn't make a good impression. If you ask candidates to bring code samples, you may hire someone on the basis of code he has borrowed from a colleague or downloaded from the Internet. The whole process is fraught with uncertainty.

And the interview – even if you use a two-interview or three-interview process for making your selection – is a ridiculously low-bandwidth way of assessing a candidate's potential contributions.

So what do you do?

I know that it's currently fashionable to require candidates to do some coding, or at least improvise some pseudocode, during the interview. Some companies famously subject potential employees to written tests. I respect the people who use these kinds of quantitative, tangible methods to aid them in making hiring decisions, but I think their reliance on such tests is misguided. We don't know that the skills that help people perform well on tests correlate well with the skills needed to contribute to a team's or company's success.

I think you can determine precisely two things during an interview. And luckily, these are precisely the two things you need to know in order to make a good hiring decision.

First, you can learn what kinds of work the candidate has successfully performed before. Past success is the absolute best predictor of future success. So if you have a job that requires developers to do x, y, and z, ask candidates questions to determine whether they have successfully done x, y, and z in the past.

Second, you can spend enough time in the interview to develop a gut feel for whether or not you like the candidate. We spend more waking hours with our co-workers than with our spouses. It's important that our new hires fit well into the workplace's existing culture and that we like them as people. Developers who like each other make better teammates.

You can ask a lot of other questions, and you can make your candidates solve programming puzzles if you want to, but the data you collect doesn't lead to reliability in making good hiring decisions. If you want your team to prosper, focus on the basics: Has the candidate solved similar problems in the past? And do you like him or her? Everything else is dross.

Web recommendation: If you're like me, you believe that most software developers are nerdy introverts and loners even though this belief doesn't align well with your experience. For years, I thought the joke-telling, musical, movie-loving programmers I knew were atypical because they didn't fit the stereotype. Well guess what? It turns out the stereotype is wrong. A group of programmers in Cuba took the Myers-Briggs Type Inventory in a recent study and landed firmly in the extrovert camp – a good thing, since Agile processes and the like require teammates to work together closely instead of staying in their cubes all day, glued to the screen. You can read the study here: Personality types of Cuban software developers. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.