Nobody is reading your GitHub

Whiteboard tests are bad and replacing them with a look at your public repositories is a different bad thing rather than a fix.

Start with how hard the reading actually is. Judging code in a codebase you don’t know is hard even when you’ve all afternoon and understanding what someone’s commits mean requires knowing the project as a whole, the problem space it sits in and the environment it runs against. A hiring manager with forty candidates has none of that for any of them and no realistic way to acquire it so what they end up doing is skimming for a feeling and then calling the feeling a judgement.

Then there’s the spread, which is narrower than people assume. Most public code sits at roughly the same level of not very good, because what people write in their own time for their own fun is rarely commented or tested or documented to the standard they would apply at work. That isn’t laziness. It’s a rational response to nobody else needing to read it. Finding someone with good public code is a real signal and it’s also rare enough that a manager who has looked through a hundred profiles without finding one has fairly concluded the exercise isn’t paying for itself.

The trust problem sits underneath both of those. Cloning a few open projects and quietly taking credit for the work is trivial and nobody screening a stack of applications has the time to verify where it came from on any of it. So even a good profile only counts if you already believe the person, which rather defeats the purpose of using it as evidence about someone you haven’t met.

None of that’s the part that should bother you most though. Treating public code as evidence quietly filters your pipeline by who has spare evenings. People with young children don’t have a weekend of side projects in them. Neither do people with care responsibilities or a second job or a commute that eats two hours a day or simply an absorbing interest in something that isn’t programming. Any of those people can be excellent at the job and none of them will look excellent by this measure and you’ll never find out what you missed because the filter runs before you ever speak to them.

The Max Howell case gets quoted whenever this comes up and it’s usually quoted wrongly. Homebrew is really successful software used by an enormous number of people including, famously, the company that turned him down. It’s also not a proof of the specific computer science that particular interview was testing for, which is Howell’s own reading rather than a defence anyone else has had to construct for him. The story is a good example of a bad process and it isn’t evidence that reading his repositories would have produced a better answer.

What tends to happen in these arguments is that the goalposts move without anyone announcing it. The claim starts as “has code in public” and quietly becomes “has launched or really contributed to a successful open project”, which is a totally different and far more harder thing. Plenty of hiring managers do look well on the second and they’re right to and it describes a very small number of people. Using the first as a proxy for the second is where the reasoning falls apart.

The uncomfortable conclusion is that judging people is hard and none of the cheap signals work. Whiteboard trivia doesn’t work, public code doesn’t work and the length of someone’s commit history doesn’t work. Building a good team is about hiring good people rather than filtering for a particular kind of visible enthusiasm and the methods that get you there are slower and more expensive than looking at a profile page for ninety seconds and forming an impression you’ll later describe as instinct.

What you’re left with is that hiring is expensive and none of the shortcuts work. Talk to people. Give them something close to the actual work and pay them for it if it takes real time. Both of those are slower than a glance at a profile page, and slower is the price of finding out something true.