Wednesday, September 17, 2008

Hiring a Developer for Non-Developers

OK, this won't be definitive guide on the subject for several reasons. First and foremost, it's just going to be a relatively short blog post. Second, I have no experience hiring developers as a non-developer because I am a developer and I was not hiring developers when I wasn't one. Um... yeah, that sentence works. Third, I am not now nor have I ever been a recruiter or HR professional and so I don't know all the other myriad tips and tricks that could be gained having spent a career as one. What I do have is experience as a developer working with recruiters and might be able to give a bit of insight from the development team side of the relationship.

When hiring for a development team, while it is important to know what technologies and methodologies a candidate is familiar with, there is only a little bit more than looking at the alphabet soup on their resume that can be done in that regard. Yes, you must do what you can to make sure the candidate isn't lying. Any help you can give on determining whether or not a candidate really worked with and knows the MAYDEOP framework will help eliminate the individual lying about it before they or their resume gets to the development team. And it will be appreciated. Well, maybe not, but at least the developers won't get frustrated when a dud does get through. Regardless, the development team will still need to drill candidates on all the details that having years of a successful programming career is the only way to really understand.

What is important to remember is that hiring a developer is all about reducing risk. To that end, what I have found more helpful when working with HR or recruiters is to try and explain the indicators that make a good developer, the indicators that signify increased or reduced risk. Do they come from a good school? Do they take an interest in technology outside of work? Do the have interests other than technology (are they well rounded)? What technology publications do they read? What social / technology groups do they participate in? Do they take an active interest in advancing their career? The list can go on for a while and varies from department to department. The idea is that each question has answers that indicate the probability of whether or not a recruit will be more or less successful in a position at a given company.

It is also important to remember that no one answer is necessarily an automatic ding. They may only have gone through "Bob's How to Talk to Computers" training course as far as formal education goes. But if they have five years of experience, have a successful record of completing projects and have every technical certification in the book, it's probably an individual the team should speak to. I'm not saying that an individual that has singlehandedly caused five lawsuits to be leveled against previous employers should be considered regardless of any positive indicators. What I am saying is that in most cases it is the combination of all the answers, the overall package if you will, that needs to be evaluated.

This definitely is not easy to do. It would be nice to think that you could simply scan a resume and match the acronyms up against the job description. Depending on the position though, this is not even a good first step. Some of the best junior developers I have ever been involved with hiring had no experience in the primary technologies used by the teams I was on. Filtering out candidates based on the acronyms in their experience would have eliminated these individuals before the hiring developers ever saw their resumes. True, we wouldn't know we had missed them and thus probably wouldn't be angry about it. But without those successful hires, it would be even more difficult not to get frustrated interviewing dud after dud just because they have "client side programming" listed on their resume.

No comments:

Post a Comment