GitHub for recruiters
“Hi, I found your GitHub profile and it seems like you’d be a great fit for this Software Engineer position at a hot new startup based in San Francisco.”
Most of my professional colleagues have gotten emails like this before; for many it’s a weekly occurrence. GitHub has become second only to LinkedIn when it comes to the sheer volume of recruiting contacts it generates. Most recruiters treat it exactly the same as they do LinkedIn: a giant database of developers roughly indexed on various industry buzzwords.
The goal of this article is show how there’s so much more information made available on GitHub (even for non-technical users!) that can be used to improve the overall quality of interaction between recruiters and the people they’re trying to recruit. Recruiting is a slog for everyone involved; finding ways to make it better is in everyone’s best interest.
Activity
One of the biggest differences between LinkedIn and GitHub is that the latter actually has a reason to exist beyond recruitment. On LinkedIn, a profile only updates if someone specifically decides to go and update it. On the other hand, a GitHub profile updates whenever the user makes changes to a project hosted on the site. It’s all on the Public Activity tab:
This is immensely useful as it shows what a given user is interested in right now. Most people are far more interested in discussing recent projects than something they worked on 5 years ago, even if the old project is also relevant to their job skills. If you’re looking to start a dialogue with an engineer, this is probably one of the better places to start.
Projects and Forking
Another difference between GitHub and LinkedIn is that GitHub shows you what actual projects a user has worked on, in the form of repositories. Not only that, but it also provides even non-technical users some basic metadata about those repositories on the Repositories tab.
“forked from”
Understanding the significance of the “forked from …” note beneath items in the repository listing is important. The first repository for a GitHub project has no “forked from” note because it is created from scratch. Later on when others want to contribute to that project, they fork the original repository which creates a copy as their own workspace for the project. These copies show the “forked from” note to indicate where they came from.
This is useful because it makes it easier to differentiate projects that a given user created themselves from projects on which they collaborate with others. Both are worth discussing, but recruiters should try to pay special attention to projects that are both originally created by the user and popular (which we’ll talk about in a moment), as those projects are likely to involve major components of that user’s expertise.
Stars and forks
Each repository has numbers for both stars and forks displayed next to it in the user’s repository list. Stars indicate people who are interested in this user’s particular copy of the repository. Forks, on the other hand, indicate how many people have their own copy of the repository.
By looking at both of these numbers, you can get a sense of how this user fits into the ecosystem of that particular project:
Repositories with many stars often indicate areas in which the user has a particular niche expertise and/or has been a key contributor. On the other hand, repositories with many forks and not many stars may indicate areas in which the user is giving back to projects other than their own. The strongest developers often have a mix of all four categories in their repository list.
Looking at a repository
Once you’ve identified the projects which are likely important to a user, you probably want to know more. Conveniently, GitHub provides a handful of easy ways to get a little more information about a project.
Language breakdown
In addition to all of the other information about a project, GitHub lists the “primary” language of a project next to its star/fork count in the repository list (for instance, in the snippet of the repository list pictured above, both repositories are primarily Python projects). Some projects, however, involve multiple languages. If you click through to a particular repository, you’ll notice a colored bar near the top. Clicking that bar will result in the language breakdown for the project being displayed:
Now, this doesn’t mean that the user necessarily works in all of those languages, especially once with low percentages—sometimes those are the result of reusing libraries created by other people. What it does do is give a better sense of the makeup of the project and provide possible topics of discussion (“I noticed that you mostly work with Python, but your dotfiles repository also contains some Haskell. Do you work with Haskell too?”).
Commits
The commit list (accessed by clicking on the commit count right above the colored bar) shows all of the changes that have been made to the repository and who made each change. Even if you aren’t a software engineer yourself, you can still use the commit list to get a sense of the tempo of the project — is it something the user works on all the time, or perhaps only every once in a while? Have they worked on it recently? Do they tend to do a lot of work on it at a time, or just make one change every so often? These are all questions the commit list can answer.
If you want to go one step further, you can instead go to the “Graphs” tab on the right-hand side of the repository. This allows you to view aggregated statistics for the repository. As an example, if you view the Punchcard for the repository, you can get a sense of when a user works on a project within each week.
Are the largest circles on evenings and weekends? Chances are the repository is a hobby project. Weekdays during working hours? Probably a project for work, or an open-source project that their current employer supports.
This and many other statistics are available to help you figure out what’s going on with a given user’s activities in a repository.
Using GitHub to recruit
As illustrated above, GitHub can be a gold mine of information about a developer. It allows you to better narrow down candidates that are likely to be interested in the positions you’re looking to fill. Looking to fill a position for a software developer at a company that works primarily with Ruby? Look for people who have recently been working on projects that are primarily Ruby. Is it a senior position? Perhaps prioritize developers with many-star Ruby repositories.
Having this information also allows you to improve the way in which you contact developers. Instead of simply sending an email that says you found someone on GitHub and think they’d match the position, tell them why you think they match. Start a dialogue about a project you found and how it plays into what you’re looking for (if they show interest to the point where you can’t answer a question, try pulling in a hiring manager to help continue the conversation). In a world where the vast majority of recruiters fixate on buzzwords, you can stand out by taking that extra step.
