With unemployment at essentially ZERO these days, it’s hard finding the best people, especially skilled knowledge workers like programmers.  Every company needs programmers, so the good ones who happen to be looking are few and far between.  By contrast, the mediocre to poor programmers are abundant and available.  Wading through the duds to find the right guy can be a daunting task. 

In-person interviewing is the most expensive part of searching for new employees.  It requires real time from the people in the department.  Each time a candidate is turned away because of an interview, the company has lost time and money.  The trick is to keep the bad candidate from making it to the in-person interview.  I’ve recently employed a few techniques to minimize time spent by my team on interviews.  My goal was to bring a candidate to interview only if I felt we would be making an offer.  Here are the things to do to weed out the folks who are unlikely to make it to the offer stage:

• Do a technical phone screen on every candidate.  Ask basic questions about levels of experience on required technologies and 3rd party libraries.  For instance, if your team uses 3rd party tools like CruiseControl.Net, Resharper, NAnt, NUnit, SVN, NHibernate, Rhino Mocks, etc, then it’s a plus if a candidate has used some of them.  This phone call should also ensure that you aren’t wasting each others’ time.  Make sure the candidate is interested in the kind of team you are running.
• Given them a “take home test”.  Make the questions appropriate for the technology (no insulting trivia).  Good questions are ones that a good programmer could answer easily.  The duds will fail the test, and you will have saved some time.
• Ask for a sample of code including code and SQL.  What they give you is a good indication of the types of things they have worked on and are confident in. 
• Give a coding assignment.  Call it an audition if you wish.  This can be any small coding task, but make it a prerequisite to the interview.  The interview is the most expensive part of the recruiting process.  I like to find a technology the candidate is not familiar with and ask them to produce something with it.  This ensures that the candidate can pick up new things and produce quickly.

I fully recognize that recruiting is not a science.  The worse thing to do, however, is to just talk in the recruiting process.  I’m going to ask my programmer to write complex software, and talking about it is little indication of that aptitude.  I prefer to see some example of the professed ability.  When a candidate easily progresses through all the above steps, it’s pretty certain that the in-person interview will be a “getting to know you” gate that opens easily to an employment offer right away.

[tags: hiring, technical, candidates, recruiting, interview, interviewing, managing, programmer]