How we use GitHub for hiring

Singly values transparency. Like, a lot. We’ve selected it as a core value of the company, and nearly all of our production code is fully open source and available from our GitHub account. It’s there because we want to help build an ecosystem around data ownership and management that can’t flourish with one player. We want the community to know what we’re up to and how it will affect them, and we want plenty of open channels for feedback and dialogue.


On that profile, you can (today) see 17 repositories. There are 11 you can’t see, of which:

  • 2 should definitely be opened, and are just waiting for keys and things to be cleaned out
  • 2 could probably be opened, but they’re just configuration management and might not be worth sanitizing
  • 4 are irrelevant; either parts of our old infrastructure or functionality that has been merged into open[able] places
  • 3 don’t contain any code

Those last 3 are the interesting ones, at least in existence if not content. Unfortunately, they’re not ultra-secret government deals or magic, proprietary awesomeness. They’re just marketing/outreach plans, general company knowledge, and people we might want to hire. None of it’s really even that sensitive, there’s just no reason to publish the code to our front door or how much we spent on beer and helicopters for our App Challenge.

These repos exist because we like simplicity as much as transparency, everyone was already accustomed to using GitHub Issues, and the system is perfectly capable of tracking tasks irrelevent of whether there’s code behind them.

You’re the Issue

As soon as you apply for a job or we otherwise become aware you’re out there, we create a new issue with your name on it. Résumés are easily uploaded to the repository’s file space, everything we know goes into the description, and as we court you, we leave scheduling notes, feedback and whatever else might be relevant. A picture says roughly 237 words:

As you can see on the left, labels categorize you and track your progress through the flow, as well as add useful flags like “Needs Review” or “Recontact Later”. Employees are assigned when they’re holding the ball, like if they’re scheduling or next up to talk to the candidate. We can use the familiar GitHub API to run stats on when people drop out of the flow (we don’t remove the step, we just tag them Passed/Rejected and close the issue), how noisy a given source is, or anything else we leave in labels or semi-structured data in the comments. Scanning the list, one can even get a light sense of conversion from one step to another or how long it sometimes takes to align schedules as people move through.

The cool parts

The primary win here is that we can use a system everyone’s comfortable with and don’t have to introduce another tool. We avoided adoption/training cost, and maybe saved money, depending on what else we might have used. We’re in GitHub for tasks every day, so it’s not going away and it’s nice to have everything in one spot.

Labels are nice and flexible. It’s easy to evolve our process and a candidate doesn’t necessarily have to go through in the “right” order. Filtering for a task at hand (eg, what résumés need looking at) comes for free.

Email integration, which most trackers finally have nowadays but is a great feature. Though I do wish GitHub would notify you when you become assigned.

We get to use all of GitHub’s perks, like Markdown, easy references to a candidate’s public code and an API for stats and bulk or automatic entry.

The bad interesting parts

One could question the wisdom of putting our hiring database or marketing strategy in the hands of a third party, but if it weren’t GitHub, it would be someone else. Frankly, if you want to hack your way in, make an issue and we’ll be in touch about work soon.

Issues stick around, so a new hire can go read everything we wrote about them. In part, this comes back to transparency and our general forthrightness with feedback, but really, if we hired you, it’s because we had nothing but good things to say. If there’s something on an issue that we wouldn’t want a candidate to see, it’s a solid sign that they shouldn’t join the team.

It’s a hack. There are definitely better/smoother/more specialized tools for this sort of thing, but they all have their own pitfalls as well.

In Conclusion

If you’re already hosting code on GitHub and need a candidate tracker or any other list of things to complete, this’ll do it for you. Our process here will certainly change as we grow or just start thinking differently, but there’s very little reason to get everyone set up with a whole new system. If you’ve got fun ideas or decide to give it a shot, let us know in the comments or hop into IRC. And if you want to try the flow out first-hand, you know where to find us.

One thought on “How we use GitHub for hiring

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s