“A developer’s resume has been replaced by a GitHub account.” You’ve heard someone say this. I’ve probably said it at some point myself without really thinking about what it meant. But it’s bullshit.
A resume and a GitHub account provide different kinds of quantitative data. Replacing one with the other means you’re throwing out good information. They complement each other and work best together, like hot fudge and ice cream. I guess you could eat hot fudge without ice cream, but why would you? Other sources of information on the internet can provide much more qualitative information about people, and these sources should inform one’s opinion more than GitHub does.
GitHub repos show a few quantitative things about a developer. You can look at a GitHub profile and answer: does this person write publicly available code? in what languages do they write that code? do they follow idiomatic principles of that language? do they write unit tests? and other similar kinds of information. That’s good data, but consider how much weight to place on a person’s public code.
Git is relatively new, and GitHub is newer. If a person has written code for only a few years and uses open source software, then a GitHub account might indeed have a significant portion of the work that person has done. For people writing code for a longer period of time, there’s a slim chance any work done prior to ~2009 appears on GitHub. Others may have worked on projects under NDA. It’s easy to think of GitHub as a portfolio, but it may not be a representative sample.
And if you look for entry-level developers, consider new programmers. As a new programmer, I wrote shitty code. That’s probably an understatement; shitty code and its consequences were the crucible that forged my career. I’m glad I didn’t have to put my early code on the internet for all to see and I wouldn’t judge a beginning developer for feeling the same way. Unfortunately the internet has a fair amount of mean-hearted people waiting to tell you your code is the worst fucking code they’ve ever seen. If you’re judging only public code, you might unnecessarily eliminate some candidates.
GitHub lets you check quantitative things in some circumstances. Resumes contain mostly quantitative data as well, providing facts (hopefully) about someone’s career history and perhaps some numbers showing increases in efficiency or bottom-line goals. This quantitative information is sort of like reading the print on a pint of ice cream to make sure you’re not allergic to any ingredients and that the ice cream isn’t expired.
But the search for developers focuses much more on the qualitative; nobody cares about the ingredients list if the ice cream isn’t delicious. GitHub repos and resumes typically don’t show how someone solves problems. They can show you the evolution of a solution and that can provide some insight, but git history can only show you the solution and not the stuff that happened between “I need to solve this problem” and “I think this solution meets my criteria.” For someone very active on GitHub discussions around pull requests and issues can contain a good amount of qualitative data, but for most working developers these conversations don’t happen in public.
And code on GitHub gives no insight into how someone might fit into a company culture. As more and more companies hire for cultural fit over competence the quality of someone’s public code on GitHub might matter less than how well he or she will work with your team.
The best way to figure out how someone’s mind works short of in-person interviews or trial contracts is to read their writing or watch them present complex concepts. A person’s body of work across their portfolio of live projects, personal blog, recommendations from other developers, stackoverflow, and blogs to which he or she has contributed will give you a lot more qualitative information than a resume or GitHub, and that’s vital context for the rest of the data you have about a person.