So hiring in the software field is hard. Years of experience, a nice quantitative measure, doesn't work very well. I interviewed a few years ago for a part time ASP.NET job. I spent the morning before the interview looking over ASP.NET, and given that I've learned about a dozen computer languages and half a dozen frameworks over my programming life (including a bit of VB 6), I thought it would take me longer to learn the company policies than it would for me to figure out ASP.NET. Of course, during the interview they mentioned about 3 times, "Well, you just work on the Mac", and I mentioned three times to them, "Yeah, but it doesn't matter, it's all web stuff anyway, and I've been professionally programming for five full time years, and another 7 before that part time, and learned all these technologies... and really VB helps you to a lot. It doesn't matter that I don't have that experience now, I'll learn Real Fast."

Of course, I didn't get the job. Maybe they hired someone better after all, but we're in the boonies here... the pickings for tech candidates have to be somewhat slim (I'd imagine, anyway). I suspect the lack of actual ASP.NET experience was the nail in my coffin there. But still...

But back to the problem at hand: how do you hire good people: people that might not have the skills you need right now, but people that you know will produce top quality work for you (and pick up the skills on the job)?

Today I ran across this approach: The Naive Approach To Hiring People. It got me thinking: what if for every position you created a rubric, measuring team skills, communication skills, general programming experience "How long have you been programming, what's the neatest thing you've done, etc". Whole range of questions on this, relevant and irrelevant to the position at hand. Create a desired score of the position you are hiring for. Say you have a 100 pt rubric and you're hiring an entry level developer. So you're looking for (say) a 50 to 75 on the rubric. Any less than that and they need more practice on their own. Any more than that and either they are seriously undervaluing themselves, or you won't be able to afford them, or something else fishy. For a senior developer position, the desired range would be higher (maybe 90-100 ??).

While I think the Naive Approach takes this in a Statistics For Teh Win approach, my reason for using it would be more practical: Cover Your Ass.

First, make it clear to the candidate that you're interviewing based on a rubic, to objectively measure if that candidate is a match, and that we're looking for a specific range. (I wouldn't divulge the range nor the actual source rubric at this point).

Secondly, make it clear that these are filed with HR, and that it (and documentation on the desired range) would be kept for (some length of time), and would be available upon request.

Having an objective measure like this, and complete transparency in the process, should (although I'm not a lawyer) allow you to counter any discrimination filing (age. creed, gender, whatever) with the scores, and the score of who you did hire.

The process also has the advantage of letting the talent - even though it's not in the toolset you are using - rise to the top. Then it's just a matter of picking the candidate how scored highest in the range, and giving them an offer (or another interview, depending). And going in descending order if your candidates turn you down.