[lucasgonze]

I am just tabbing over from looking at a github profile of a potential hire. It was somewhat useful as a way of understanding this person's technology style.

I saw PHP, game dev, JSON. I saw that he does do OSS stuff, though not much. I saw that he can write a decent readme.

That's the kind of thing a hiring manager gets from a github profile. It's not a one-dimensional test like how many checkins does the dev have.

[kelnos]

> I saw that he does do OSS stuff, though not much.

GitHub will not even remotely tell you that, though. There are tons of open source projects that are not hosted on GitHub. If you, say, contribute to the Linux kernel, or to Firefox, or perhaps Xfce, nothing will show up on your GitHub profile to give you "credit" for that.

I agree with another poster that GH can be useful to disqualify candidates (say if they've posted something they've plagiarized as their own), and you might find interesting things on a candidate's profile that increases your impression of them, but it's absolutely useless for comparing candidates or getting a full picture of what they've worked on in public.

[ghthor]

If you contribute to any of those large projects then you should have that on your resume/cv with a link to the instructions for pulling down a list of the commits related to your work. Easy Peasy.

[mdip]

> absolutely useless for comparing candidates or getting a full picture of what they've worked on in public.

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.