The Virtual Referral: Mitigating Risk by Hiring Open Source Developersby Brian W. Fitzpatrick, coauthor of Version Control with Subversion
Hiring a new employee is almost always a risk, and hiring the wrong employee is one of the most costly mistakes that a manager can make. As a result, tech companies spend a small fortune recruiting, interviewing, testing, and analyzing candidates in an effort to minimize the risk of selecting a bad hire. The biggest problem with traditional interviewing and evaluation methods is that they are based on limited information about a candidate, such as resume, references, and contrived problem-solving scenarios in interviews. These can be effective evaluation methods, but they too are costly and time consuming, and still carry with them a high risk of making a bad hire.
If, however, you are choosing a candidate from the ever-growing pool of programmers who contribute to open source projects, you can get an inside look at a programmer's work on actual projects with actual team members by examining the open source projects he participates in. A small amount of research here can turn up a ton of real-world data (remember that "the internet never forgets") and may provide you with just the information you need to make the decision to hire or not to hire.
O'Reilly Media and Greenplum Team Up to Unite the Global Geekforce
O'Reilly Media launched the beta version of O'Reilly Connection at its 2005 Open Source Convention. O'Reilly Connection is a tech-centric jobs and networking site for developers and those who want to hire them. The service was conceived and created by Greenplum.
But typically, how do you find candidates who are more than just a resume to you? Obviously, you hire people you know. If you've worked with someone before, then you know what she can and can't do, so there's not much of a risk at all if you think she'll be a good hire. But eventually, you run out of people you know, so you then have to rely on referrals from people you know and trust, typically your existing employees. You have less information about referrals than about people you know, but still have considerably more than you have with someone who walks in off the street.
Eventually, referrals aren't enough, and you need to start looking at resumes and interviewing people that you and your employees don't know. You're forced to rely on a resume that may be chock full of lies. You've got to trust that personal references will make an objective evaluation of your candidate and that corporate references aren't lying just to get the candidate out of their hair (although typically, for legal reasons, a corporate reference will only verify the start and end dates of a candidate's employment).
Brian W. Fitzpatrick
This tutorial covers the details of using Subversion in open source development, including making the transition from CVS, Subversion's differences from CVS, and using Subversion features not found in CVS.
Brian W. Fitzpatrick
This talk reviews best practices for migrating to Subversion, based on case studies of teams that have already made the switch.
O'Reilly Open Source Convention
How do you get more information about these people? You need to have a strenuous interview process, so that you and others in your company can grill a person on what he knows or doesn't know and how he thinks. Still, you're going to be hiring someone based on a series of brief interviews, and that means that you have a limited amount of information. In addition, this interview process is expensive--think about how much an hour of your time costs. Now think about the cost of that plus an hour each from another three or four more engineers at your company--it adds up pretty quickly.
What you need is a way to get even more data about your candidate--a way to be a fly on the wall in your candidate's office to see how she works in her current job. If your candidate is involved in writing open source software, with a little research and resourcefulness, you can be that fly on the wall.
This doesn't mean that all open source participants are amazing programmers who will be a perfect fit for you and your company. What this does mean is that there's a wealth of information about your candidate available to you, because most open source development takes place in public.
If a candidate lists any open source projects on his resume, review his open source work (or assign the task to one of your engineers who you know will be interviewing the candidate). Knowing what projects a candidate has contributed to will enable you to review code that he's written (production code, mind you, not interview problems), review his docs, and even review his individual commits by trolling through the project's mailing archives and version control system. Even more importantly, you can get a firsthand look at how the candidate interacts with others in a team environment by reading the project's development mailing list. You can see how he or she designs new features, triages bugs, and deals with conflict and compromise.
And if that's not enough, keep in mind that most programmers who work on open source projects do so because they love writing software and they're passionate about their work.
This is the kind of information that most hiring managers dream about, and it's yours for the taking. Whether it leads to a hire or a rejection, you're making a well-informed decision without placing all of your trust in just a resume, a referral, and an interview. When your prospective hire is an open source programmer, it means that you have more information about them, less risk involved in hiring them, and ultimately, a better team member.
Thanks to Karl Fogel and Greg Stein for reading drafts of this article.
Brian W. Fitzpatrick is a member of the Apache Software Foundation and currently works for Google. He has been involved with Subversion in one way or another since its inception in early 2000.
Return to ONLamp.com.