Why GitHub Won't Help with Hiring

While I agree that they're less important, especially if there are commercial products/accomplishments that the candidate can point to, I wouldn't say that they diminish dramatically.

For a candidate that has years of industry experience, a look at a GitHub profile can serve as a solid metric for their growth as a developer. I want to not only know that a developer "has been doing something for a while" but that they're honing that craft. For me, personally, I want to look back on anything that's 6-months old and be able to point out everything that I'd do differently[0].

It can also serve much the same purpose that it does for grads/bootcampers. It gives you an opportunity to show off your knowledge in areas that may not be covered by your professional work -- maybe you're doing mostly back-end/systems and want to demonstrate knowledge in React/TypeScript/Angular/front-end. I knew a guy who's repo is filled with rust projects. Professionally, he was a (very capable) Java developer[1]. His rust-filled repo landed him an interview for a job doing mostly systems work in C/C++ with a hope toward moving things over to rust where it made sense ... and no Java work[1].

> I don't always include it on the resume.

I don't include mine, either. The best advice I received on resume writing was "It's to get you an interview, not a job", so I treat it as marketing copy. My github repos (I have a few github accounts) contain a lot of code that I shared because a few others wanted it and Github was the most convenient way to do it -- but that code was hastily written and was never meant to demonstrate my abilities. Some of it -- were it encountered by someone who doesn't understand that caveat -- would make me look bad. If I get a pre-interview (phone interview), I already have an e-mail ready with links to all of that waiting for a "To" field which includes boilerplate that I've also already casually joked about "I'm happy to send all of these to you to reduce time spent googling, as long as you promise you won't judge the thing I wrote in an hour at 2:00 AM on a Saturday night as a prime example of my coding ability and will at least give me an opportunity to apologize for some of the evil I've unleashed on the world."

[0] I always joke that I don't feel like I'm growing as a developer if code that I wrote 6-months ago doesn't mildly embarrass me.

[1] I learned, by accident, that he hated Java (I asked him if he was interested in putting his resume in for a Java position where I currently work) -- it was his first serious language and he'd since explored Clojure and many others but because he was known as "The Java Guy" where he was at, he wasn't able to get out of that line of work over there.

Some people aren't in the mood for extra curricular activity after working +14h a day. They rather unwind, and be productive the day after in their not-pushing-to-github jobs.

You're absolutely right. Using a single source as a metric, even if that source is as huge as Github, would be terribly misleading. Though a simple google search would likely surface contributions to Linux/Firefox/Xfce, I don't get the sense that was the point you were trying to get at.

The issue is that there isn't a way to get that full picture. But using Github and other sources out there is a lot better than nothing at all.

I'm not terribly convinced there's a ton of value in it pre-interview, but there's been a lot of value -- for me (both on the giving and receiving side) during interviews.

Here's the thing -- at the time I was involved heavily in hiring developers -- I'd get a few hundred resumes and had time to interview about ... 5 (I was usually the last interview for those candidates) for a given position. It was really important to me that those 5 be worth interviewing. I'd with any links in the resume, itself, and I'd google. I'd happen upon Github, SO, blogs, and even HN profiles. I discarded anything that wasn't code-related[0]. If I don't find anything, I pick up the phone and ask if there is anything they can point me to or send directly to me, code-wise (this was for every candidate that got a phone-screen and was being considered for an in-person).

I get, at best, an hour to judge someone. Interviews are terrible -- I'd argue far worse than anything I can glean on Github/SO. However, combining the two ended up being really effective. Start with a bit of code the candidate wrote and -- after some disarming (i.e. "I know this is personal code and won't be up to your typical code quality -- we all have lives outside of work and can't dedicate the time we'd like to our hobby projects" etc) I start asking about choices that were made (why did you opt for a functional pattern there?) and how they'd improve on it. This gets right into how the developer reasons about code and since it's something they've written (hopefully recently), it's less difficult for them to do than if they're given someone else's code to evaluate[1].

And I've used it on the other side, as well. I received a great offer at a company after flatly refusing to do a whiteboard coding session. It was a job I didn't particularly want[2], so when they handed me a whiteboard marker, I (way more flippantly than I intended) said "I could kludge my way through that using the worst IDE in the world and without access Google, but if you want to log in to Bitbucket on your laptop there, I can show you several different implementations of that which I wrote for a backup application I've been working with for a few years". It was in a private repo, but was all my own code -- I was just a little more embarrassed by it than other projects, but it had the code he was looking for. We went an hour over in that interview and spent 1.5 hours talking about my code. I turned the job down, but it was one of my favorite interview experiences.

[0] Partly because I believed it was the right thing to do -- your politics/pet causes, your silliness/rants/divorce are irrelevant ... life is messy. And partly because it could be a problem for me to know certain things (your religious affiliation, sexual orientation, etc). I don't care about any of those things anyway but managing bias never hurts.

[1] I used to work very hard at disarming my candidates. I felt like nerves tended to hide good candidates and anything I could do to reduce those nerves and make the interview feel like a conversation, rather than a "contest"/"judgment", the better.

[2] Generally speaking, my resume is up-to-date and I enjoy interviewing, so if I'm offered an interview, I take it. Even if I have no intention of finding a new job, provided that my current employer isn't going to be notified about the interview, there's nothing to lose by taking an interview -- even if all you get out of it is a little bit of additional practice.