Hiring good programmers - Part 1

One thing that I've struggled with, and I know I'm not alone in this, is how to accurately decide if someone will be a good programmer for a company or not.  Traditionally, companies will first screen resumes, looking for particular experience, skills, etc.  They will next have a phone screen to further weed out candidates.  Finally, the candidates will be brought in for a face-to-face interview.  How effective are these methods, and what can we do to be more effective?  In Part 1, I will outline issues with common current methods of evaluation, and in Part 2, I will suggest an alternative.

What about the resume?  Many companies will pre-rank candidates (either explicitly or implicitly) based on the quality of the resume and the information presented on it.  There are a few problems with this.  First, I don't have a reliable source handy, but I recall hearing that 50% of people lie on their resume.  50%!  Couple with the proliferation of sites (such as fakeresume.com) that are intended to give advice to people who want to get away with lying on a resume, and it's tough to know which resumes to trust.  Second, many of your potential employees will have hired a professional resume writer in order to get your attention.  Great resume?  Is it because they are a detailed worker or just hired a great resume writer?

What about a degree?  Most of the jobs posted on the major job sites for programmers ask for some sort of technical bachelor's degree.  This certainly should be a consideration for an entry-level candidate.  However, in observing a number of people in a number of different industries, I've come to the conclusion that the benefits of the quality or type (or even presence) of a degree decreases severely after about 1-3 years of experience.  For experienced candidates, the ability to learn new concepts and apply those concepts in new situations becomes a much more important asset than the quality or source of their original education.  Putting it in another way, does the candidate have 10 years of experience, or 1 year of experience repeated 10 times?  In fact, I might be more inclined to hire the person with the poor quality of education who somehow managed to become a good programmer, since they have the proven ability to learn and apply concepts in less than ideal circumstances.  (Or maybe I just think that because I'm a self-taught programmer.)

What about the interview?  A lot of good information can be gotten from an interview, but a lot of misleading information can be gotten here, too.  I'll speak more about interviews in Part 2, when I actually start talking about methods that can help you find good candidates rather than merely eliminating bad ones, but I will mention here that you should always be aware of the implications of what you are asking even if the legality of questions weren't an issue.  As an extreme example, I read an article on BNET that quoted a hiring manager saying (and I'm paraphrasing) that they hired someone based on the answer to this question: "If you would be a character from 'The Wizard of Oz', which would you be and why?"  What can you learn from the answer, assuming you get one?

1. The interviewee thinks well on his or her feet and handles the unexpected well
2. The interviewee has an active fantasy life and empathizes with characters easily
3. The interviewee is a huge 'Wizard of Oz' fan
4. The interviewee trusts you that you know what you are doing, even though you are asking a question that seemingly gives you no insight into his/her ability to do your job or him/her insight into their fit into your culture, making him/her a likely "yes person"
5. The interviewee does not have the ability to sense when something is or is not a waste of time and would be a poor choice for leadership positions

You could legitimately make a case for any of the five.  #1 is definitely a plus for your company, #2 may or may not be, depending on the position, culture, and point of view, #3 is completely irrelevant, and #4 and #5 would be considered negatives for most positions out there.  I can't see how the interviewer in this case learned anything worth knowing from this question given the uncertainty involved.

Finally, many companies have some sort of programming exercise as a part of the interview processes.  Even a poorly designed exercise will likely separate the completely incompetent from the competent programmers.  For example, what does having the programmer show all the prime numbers from 1 to 100 show about his or her ability?  You may need someone who can think mathematically, but you may not.  Here again, the best designed exercises will have specific goals and will not be some generic problem designed to eliminate the worst programmers.

In Part 2, I will demonstrate some methods for getting at the heart of the job position which will hopefully make it easier to scan resumes, design interview questions, and design programming exercises.