How To Read Github Profiles For Recruiters

How To Read Github Profiles For Recruiters
Post Author: Aaron Decker
Date published: October 16, 2019

Github is a place developers can view, share and collaborate on code. It is known for hosting open source projects and being the center of development for essentially the majority of major open source web technologies.

Git is a version control system developed by Linus Torvalds, the creator of Linux. A version control system is a piece of software that helps to manage source code. Git is by far the most popular version control system among web and mobile developers. Git makes it possible for many software engineers to share and review code on a single code base (project) and resolve conflicts that may arise.

What is Open Source?

Open source software means sharing the source code of software you release. It does not necessarily mean the code is free to use in any way you want. There are a lot of different licenses, including the GPL family of licenses that require any software using GPL code must also be open sourced as GPL.

For the most part people are using very permissive licenses like MIT or Apache 2.0 which allow you to use projects with these licenses in any way you want (including consuming in your project and selling it).

Generally, the popular Open Source projects you find on Github are software libraries that are meant just to help facilitate building end products. For example Express.js is an open source project that makes it easy to build REST web servers in node.js, and many paid products will use Express as a foundation in their code base.

Who are open source developers

Any software developer publishing source code to things they build OR people participating in building on other open source projects.

Why would you decide to open source something?

As I mentioned before, for the most part people are open sourcing libraries that would not necessarily stand alone as a product. These are just tools to help other developers build applications better or faster. There are a lot of reasons to release code like this:

  1. you get free bug fixes
  2. you get free testers
  3. you get feedback on feature development
  4. you get publicity
  5. you generate good will

Because of 1-3 you get better, more reliable code. If you are a company, because of 4 and 5 you might get developers wanting to work for you. If you are an individual you get a strong reputation and hiring managers will want you (if they are smart).

If you release code publicly and people start using it, they will start helping you work on it for free. For example you make a library to work with Mailchimp (an email marketing company) and it takes you 40 hours. Well, for the next person who comes along this saves them 40 hours, and then they may decide to contribute 4 or 5 hours to making it better. Multiply this by 100 or 1000 and you can see the enormous benefit everyone in the community gets out of this.

Okay, okay, so how do I look at Github profiles?

Right, that is why you came here. But I had to explain all of that stuff so you can see why it matters.

A developer that is active on Github and is an author or contributor to a major open source project is likely to be highly experienced as a software engineer in the language of the project. So, in theory you can look at somebody with an active profile and see how popular their contributions are and make some basic generalizations about their level of skill.

The inverse is not true, however. Not every engineer has a github, and not everyone is even contractually allowed (per their employer) to participate in open source. So a developer with a strong open source authorship background is a strong signal that you have a very good developer, but a developer with little or no open source work essentially tells you nothing good or bad.

Assuming they are active, what do you look for?

What you are looking for is contributions to major projects. Basically you want to see someone adding code to a repo with a strong reputation in community and you can sometimes use stars as a proxy for reputation. If a repository (a project of source code - β€œrepo” for short) has over 500 stars it is probably popular and reputable.

It is also a neutral sign if a developer is creating their own repositories (not forks - I explain below), and contributing to them regularly but they have no stars and no readme explaining what the code does. You can't really tell what is going on unless you read the code.

Defining some terms

Commit

A commit is a single chunk of work. So it may be a change to one or more files. You can see the author's name and the date, as well as the lines of code changed. This is all public.

Repository (or repo)

This is a single project of source code in git. A repo has a log of commits that have been pushed to it and you can read through this, the information is all there so you can track changes over time. A repo has branches where each can have their own history and lineage. The default and usually main branch is called "master". Typically all finished code is merged into master.

Fork

A fork is a clone of a repository. This is important to understand because you normally fork a repo before contributing to it. So if you see a developer has forked the main React repo it might mean that they are going to contribute to it. It might mean that they already did contribute to it. It DOES NOT mean they wrote React, or they own it. A fork is just a copy. You can tell a fork by the fork Icon:

fork icon

Pull Request

A pull request is the method that a developer who has forked code and edited it on their fork is able to request back to the owner that a change be made. In the pull request you can see the "diff" which is a view of the differences in the code they are adding/removing.

Readme

A readme is a file that you should read first when you open up a code repository. A good open source project usually has a Readme with an explanation of what the project is for, where it is published and some documentation about it's usage. This helps people get started using and sharing the project.

Inspecting history

You can see what people are doing based on their history. It is good if you see a lot of pull requests to popular repos. It is good if you see lots of commits to a repo with a high number of stars. If a developer has pinned a repo to their profile and you go to the "insights" tab of that repo, you might expect to see they listed. At least you can search their profile name and see how much they have actually contributed.

Examples

We can start with my own Github profile:

aarons profile github

You can see the first pinned item is something called target/react-native-svg-parser. You can see it belongs to someone else (it was open sourced by Target while I worked there) so you really need to go look at the repo to see my contributions to it. If you did, you could how much of the code I authored. Each repo has an "insights" tab where you can see this stuff.

Next you can see the other projects that I own, most of them have very few stars. This does not tell you much unless you can read code.

Finally, on the right side you can see some repos I have linked. These are things owned by other people but I have contributed to. But, in truth I have made very few contributions to each of these. You can go look them up. Jasmine has 15k stars but I only made 1 commit to it.

What can you conclude? I am a real developer and I have some experience in JavaScript and React it seems, but you may not be able to make any other conclusions.

Okay, let's look at a very well known open source developer:

Michael Jacksons Github

Note: I blurred out the contact info as a courtesty, but this is all public info. If you have a github account you can see anyone's email

His profile looks similar. Let's look at the first pinned repo. It is owned by someone else but it has about 38k stars. That would mean it is extremely popular and highly regarded.

Okay, let's go check that out.

React Router activity

In the insights tab you can actually see he is the number one contributor. So this is a very strong signal he is well known and well regarded in the industry and is a capable engineer.

Activity History

The activity history is a somewhat decent indicator that a person is an active developer, but again the same caveat apply. It can be a very good tool to spot a junior developer and verify that someone has been active in open source if that is what you are looking for. You can see mine here- basically you can see some activity of me doing things on various open source projects.

github activity aaron

Faking history

I once interviewed a developer who was a bootcamp graduate with a fake github history. He said he had seven years of experience but when we actually sat down to interview him he could not answer basic JavaScript and CSS questions.

You can create and fork repos and write whatever you want into the git history. Git, the version control system that github uses under the hood does not prevent you from changing history and changing dates.

So this guy's history went back years but when you looked at it this was all just junk he had forked and the history was re-written.

This is why I say if a person has activity and projects on their github, it doesn't really mean anything. They only thing that is a useful signal is if a person has commits going into a major open source project. You can't fake this on Github.

Using Profile analyzers

There are some pretty cool open source projects that analyze what languages developers are working in. As a recruiter this can be a useful tool to understand someone's activity in open source.

I'll run this one against my profile. I'll tell you now, mostly I work in JavaScript and Java. I have done a fair amount of other random stuff in other languages too but this should reflect my JavaScript and Java work if it is accurate:

aarons github profile analyze

Look at that, it actually worked pretty well! So if somebody has an active profile, sometimes you really can use this to get an idea of the kind of code they work on.

In Summary

I hope you can see it takes a little bit of effort to really understand what is going on in the Github interface, but it can be well worth it to get a better understanding of candidates.

Also, I think you might be able to see how involved it is to do this research the right way. External recruiters may not have time to do this, but if you are an internal recruiter or a hiring manager it would be well worth your time to go through every candidate's github to understand if it can tell you anything useful.


Want updates?

Want new posts about tech topics emailed to you? Sign up to the list below πŸ‘‡

Also, if you are interested in learning technical topics through a video course specifically created for recruiters, don't forget to check out the courses I offer.

The main course "How to Speak Software Engineering Jargon for Recruiters" is specifically designed to help tech recruiters get up to speed fast on technical topics.


Written By Aaron Decker

I'm currently a co-founder and head of engineering at a venture backed startup called Bounty. I tend to think of myself as a backend engineer that can work up and down the stack in Typescript. Previously, I have worked as a Tech Lead and hired teams, and as a Senior Software Engineer at multiple fortune 500 companies building large products. I also did a brief stint teaching programming courses as an Adjunct Instructor at a local community college, which taught me a lot about breaking down complex things into understandable chunks.