Why GitHub Won't Help with Hiring

I would also check they PR, issue and comments, to get some idea about how they work with stranger; what are important to them when they suggest ideas, contribute to existing code base; how they reply to critic or question from project owner, etc.

Also, just my opinion, most of us - software developers - can't live without OSS. We should contribute back when we could. That's why I usually prefer resume with a non empty Github profile than the others.

Even within a larger organization it's possible to use side-project examples as a demonstration that you're ready to move from a team that uses one discipline/language to an unrelated team. While a large organization might be willing to move a senior developer who's a less-perfect-fit from a different department if they've demonstrated that they can be trained/learn what they need to know, it's a lot easier if they can demonstrate that they're a lot more than a "less-than-perfect fit"

But hiring good people is very time consuming. The reason GitHub as a portfolio makes sense, is that it helps compare potential candidates--that I know nothing about--faster. Biased or not, I have had the best experience with people that are very active publicly. From Battlebots competitors, book authors, to startup founders, etc.

Ivy League Colleges, VCs, even Y-Combinator works very much the same way--trying to make an assessment based on past accomplishments. The more visible, the better. With the caveat being a strong direct reference.

I am sure we all have extra circular activities besides coding, but depending on how strong your experience or professional network is, really depends on how much you need in a portfolio. I have been coding since I was nine and have decades of experience, I still have stuff I hack on that is public, from SlackBots that control GPIO pins to Sonos controllers, etc. I would think the more experience you have, the better chances you would have more stuff you can add to your GitHub (portfolio).

At the end of the day, as a someone hiring, I am going to gravitate to engineers that have more and better examples of their work ability and output vs where they worked on their Resume. Not to say that we should ignore anyone that doesn't have public projects--but they are certainly at a disadvantage against someone that has.

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.

Easier said than done, especially if you're talking about whiteboard interviews.

Nobody can even agree on what this perfect barrage of probing looks like.

Employer's have a limited amount of time and money too, why should they waste those resources having to mine for someone's skill level when there's plenty of candidates out there that will display that on some online site.

That's just outright factually inaccurate. Are you expecting employers to hire on blind faith? If employers are hiring without evidence to support your skill-set, then their hiring process is broken.

> Observe how it worked out for everyone who got a degree because employers won't hire without one, and then they don't get hired regardless of that degree.

I don't have a degree, I got my first job because I walked into the interview with a portfolio; more specifically a fully functional completed piece of software that I live demonstrated. This wasn't an open-source project, but I sent them the code to be reviewed nonetheless (I own the IP).

The reason some people with degrees don't get jobs is because people with portfolio's (irrespective of degrees) can demonstrate their skill-set, where as waving around a piece of paper and having no demonstrable skills makes it extremely difficult for a potential employer to evaluate you.

> It is a slippery slope where we allow employers to dictate uncompensated signaling necessary for a role.

I do somewhat agree with this. However, your portfolio need not be open-source work, it's just common as there's some proof (version control, although not tamper-proof) indicating you did the work you're claiming you've done.

I think the better way of putting that is "Interviewing is broken". Determining that a candidate meets a minimum level of skill-set is possible to do in an interview, however, determining much beyond that is highly elusive. I've had candidates that were incredible "Used Car Salesmen", who the previous interviewers wanted to "skip the technical interview" and just hire the guy outright because he was so convincing only to have his outcome in the technical interview end up being terrible (and I've had candidates get the job where this fact was discovered too late)[0]. I've had candidates that I've had to have a fight nearly come to blows to get a candidate hired because they were so nervous that they completely bombed the interview, and that "accurate portfolio of their skill set" was the only thing, outside of my insistence, that got them hired (out of the few this has happened with, all were good hires, too).

I'm not asking anyone to jump through my hoops (especially now that I'm working at a place where I, thankfully, no longer interview candidates). I don't ask candidates to white-board code (I wouldn't let them if they wanted to), but given a candidate who has a solid portfolio against a candidate who does not -- assuming all other things are equal (or the portfolio is incredible) -- I'm going to hire the one with a portfolio. And I feel it is a personal responsibility of mine to keep that stuff up-to-date. I could do a better job of it, myself, but if I failed to get a job because I lacked in that area, I wouldn't blame anyone but myself.

[0] I blame myself for this one -- he could talk up and down about concepts; was hugely into functional programming at a time when that was less mainstream. He not only knew all of the buzzwords, but he knew the "why"'s behind them. Academically speaking, he was incredibly knowledgeable. It wasn't until he had to actually learn an existing code base and contribute to it that it was discovered he lacked in execution. A manager on his team felt that he "froze up" ... would write something seven different ways and keep coming back to it while writing follow-on features until all he was doing was modifying code he'd already written to yield the same result, just slightly differently. I, arrogantly, assumed he was too good for the half-rate programmers we hired but upon running into someone who worked with him at the company he came from, it was discovered that he was not actually employed by them at the time he was interviewing as he'd been let go a couple of weeks prior ... and he had the same problem there.

It was more important to me that a candidate could reason about the code in question -- even (perhaps especially) if it was an implementation they pulled directly from an SO post. There were occasions where I'd see unique implementations of common tasks (i.e. pulling a value out of a URI string that carried an unusual formatting pattern where simply using the URI parser in .NET wouldn't have worked directly). Having worked with a few different frameworks that use unusual URI formatting, I might ask why a regular expression was used over writing a custom parser tied to the Uri type (or vice-versa) and I was more interested in hearing the argument and reasoning behind it as well as whether or not the candidate could come up with pros/cons for both methods. Sometimes it'd be a custom implementation for something that could be done directly with features available in the framework -- and often the answer was obvious[0].

And a little humility doesn't hurt, either. I remember asking why someone used a regular expression to do some rather involved data extraction from an HTML source versus using something like Angle# and I recall the response was something along the liens of "Well, it started with pulling just URLs for a limited case and exploded into getting some metadata around the link, but it was for something at home and I put a total of ten seconds into thinking about how to do it right and if it stopped working completely, it didn't affect me all that much". Good enough; a lot of developers would go off into tall weeds defending bad code rather than just saying "sometimes the tolerance for error greatly exceeds the availability of time" or "I just didn't care enough" -- especially in an interview where you are hyper-sensitive about looking bad -- and we all have a bunch of very dirty scripts that "work ... mostly". Provided it's not a theme of ambivalence throughout the interview, a little honesty at a time when it's tempting to fluff gave me confidence that when that developer made a mistake, he might actually own up to it.

[0] It's either "I didn't know it could be done that way" or the most common "I wrote it before that method/call existed" -- since I was hiring for .NET positions at a time shortly after Framework 2/3.5, this was a really common situation due to many new ways of doing things arriving with Generics/LINQ. And both were acceptable answers since it took some time for a lot of .NET folks to grok generics/LINQ and understand them well enough to realize the appropriate place for them (outside of just "oh, I can make a List of anything without having to use ArrayList of object types")