Finding a good developer is hard.
People constantly complain about how few qualified applicants they receive. They post their job openings to every known listing. They hire recruiters to scour Linkedin. They do all of this in the hopes that a bigger stack of résumés will yield at least one hire who is up to their standards.
The obvious problem with this fire hose strategy is that it doesn’t improve the quality of your applicants, it’s simply playing the numbers. More résumés just ends up meaning more time spent considering people you’ll never ultimately hire. And if you’re like most companies, you don’t have that kind of time.
The best way to hire qualified developers isn’t to hope they come to you, it’s to go out and find them. But as most of us know painfully well, traditional recruiting is broken.
In this article I outline a strategy that I recently recommended to a friend who’s been struggling to find a good front-end engineer. My hope is that it can benefit others too.
The Strategy
Every company I know of prefers employee recommendations to just about any other recruiting method. And for good reason. Referrals are a great option because they eliminate so many unknowns upfront. Somebody on your team vouches for the skill of someone they know, and at that point interviewing is almost just a formality.
The problem is not everyone knows other good developers, and at most companies (especially small ones) you run out of referrals pretty quickly.
The technique I’m recommending aims to capture the best aspects of personal referrals without requiring first-hand knowledge. It seeks to find people whose abilities are already proven.
How? Simple. Look at Github.
Open Source
OK, obviously it’s more complicated than just looking at Github. Github has millions of users, and most of them are probably not for you.
The challenge is narrowing it down.
If you’re a web company, you probably use a lot of open source software in your stack. And given that this software is in your stack, you probably want to hire someone who knows how to use it. Well, here’s where open source shines: not only can you see the source; you can also see the authors. And if you’re using a piece of software in your stack, who better to hire than someone who helped write it?
Now, I’m sure many of you have considered trying to hire the creators of popular open source libraries, but in truth, unless you’re a big name company you probably won’t be able to do it. Guys like John Resig, DHH, Jeremy Ashkenas, etc. are basically off the market. And even if they were looking, they’re probably not going to go work for some company they’ve never heard of.
But the creators aren’t the only people who make open source software. There’s also the contributors — thousands of them!
Think about it. Do you use Node, Rails, or Django on the back-end? Do you use Angular, Ember, or Backbone on the client? If so, why not recruit a contributor to one of those projects? Do you need someone who knows how to handle browser inconsistencies? Find a jQuery, Bootstrap, or Foundation contributor.
No matter what type of person you’re trying to hire, there’s an open source project with plenty of contributors who have those particular skills.
And with Github, finding contributors and seeing exactly what and how much they’ve contributed is easy. In case you’re not sure how to do this, here are the contributor pages for a few of the more popular projects on Github:
Why Contributors?
At first it might seem like contributors aren’t nearly as valuable as the original creators. After all, creators have to be innovative and know the project from end to end. A contributor might have just fixed a bug.
While there’s some truth to this, it’s certainly not the case that contributors don’t possess creator qualities. Furthermore, most companies spend the majority of their time building upon an existing project, not making something new.
In this sense, a prolific open source contributor can actually be more valuable than the creators of libraries they contribute to. After all, anyone who’s made substantial contributions to an open source project has not only demonstrated their ability to write coherent code, but they’ve also demonstrated their ability to read, process, and improve upon the code someone else has written.
That second part is extremely valuable, especially to a big team with an existing codebase.
Being a contributor is essentially what an employee is. It’s what you’re looking for. Yet the ability to contribute is probably one of the hardest qualities to assess during an interview.
Considerations
Obviously this strategy shouldn’t be the only one every company uses from here to the end of time. After all, not everyone is on Github, and not everyone has the time or means to contribute to open source.
A candidate who works multiple jobs to pay the bills should not be penalized or unfairly judged for a lack of open source contributions. That being said, if you’re actively looking for a particular type of developer, it’s impossible to judge people who have nothing to show.
Another downside of this strategy is it doesn’t take location into account. The perfect candidate may well be half a world away with no interest in relocating. If you’re not willing to hire someone remote, this might not work for you.
I don’t want to get into a debate about the merits of telecommuting, but I do want to say that this problem isn’t unique to this strategy. Obviously if you want to hire the best people you’re going to have to make sacrifices, and if you’re not willing to make sacrifices, then you’re implicitly sacrificing quality.
Final Thoughts
Nothing I’ve suggested in this article is particularly novel. I’m sure people have been using open source to hire for years, probably decades.
My main goal was to emphasize two particular facets of leveraging open source when hiring. First, companies should use open source as a recruiting tool rather than simply a vetting tool, and second, while contributors to open source software often go unnoticed, the qualities that make someone a good contributor are essentially the same qualities most companies are looking for.
The creators of open source software are in many ways like rock stars. Sometimes you need a rock star, but most of the time you just want a studio musician.