Having personally used GitHub to aid in hiring developers, I find it to be a
very valuable resource ... provided it's used correctly. The author makes a few points that I would have considered somewhat obvious (i.e. social networking is not a metric that indicates a successful developer) and he's correctly pointing out that using it superficially as a sort-of "metrics engine" for developer candidate quality is going to yield poor results.
Case in point, the candidates I interviewed -- if they had any public Github projects: (1) had maybe one or two projects of their own that were public. (2) They were personal projects of varying levels of "quality", i.e. not their day job. (3) They were the only developer/committer and new commits were somewhat rare. For the most part, just the existence of a profile with some projects was a plus. Most candidates didn't give me a way to see that they could actually write software (fizz/buzz?) -- though there are ways to solve that without resorting to white-board or in-interview programming.
I started using GitHub and "external work" as an interview technique after an experience with one of my best hires. This was a candidate not unlike others that had a pretty dead profile, but there was one project that showed code quality and thought that far exceeded "the typical". It was clearly "That One Project(tm)"; his baby. The code quality was quite good, it had documentation and it had thought put to its design[0]. It had zero stars or forks, but it was obvious this was a tool he wrote for himself and really cared about. His interview started out very badly because he was nervous, but the project saved him. Mainly because I started wondering if he actually wrote the code in that project (because he failed to answer some pretty basic code design questions), I pulled up his project and started asking him specific questions about his code. He went from nervous to excited[1] and was suddenly able to explain things that he had a difficult time with when they were presented simply as abstract concepts.
I used to facilitate many technical interviews, but it's been a little while since I've done one due to a new job/different company, however, I think the method I use is still the one I'd go to. The technique I used after this gentleman was to call the candidate a week in advance of the interview and ask if they have anything public, code wise (blog posts, SO/Github/Gitlab/Bitbucket profiles), that they can point me at or if they could provide some samples[2]. I always explicitly state "This doesn't need to be your best work, or even terribly great code, it just gives me a starting point to discuss development practices" and I recommend they pick something they've done recently since "any code we've written more than 6-months ago might as well have been written by someone else" The technical interviews would then, generally, be that candidate explaining their code, the choices they made, why they made them and what they think improvements would be in order of priority. That has worked really well for me and beats the daylights out of any paper/pencil, whiteboard or even "code this on this laptop while I look over your shoulder"[3]. Assuming you successfully disarm the candidate with the "we're not judging your code (!)" preamble, I've found that people are far more comfortable (and most legitimately enjoy) talking about things they've written -- even critiquing them[4].
[0] In this case, a unit tests covering the right parts of code, documentation, build instructions, logical layout/design -- he cared about this code and it gave a really good insight into
[1] Given his performance in the interview, I would have expected this person to be introverted and not a terribly motivated programmer... goes to show how terrible interviews are at judging people -- this guy ended up being the guy everyone else on the team looks to -- he was passionate in a job that, frankly, wasn't the sexiest programming job.
[2] This last point, to be clear, I expect to never receive proprietary samples. It did happen, once, and I didn't think this was something I had to actually state, but I wouldn't have hired someone who would share code they had agreed to protect since they'd be agreeing to the same thing working on the team they'd be going to.
[3] The difference between a great developer and a great developer who gets anxious during interviews is that the latter might be a little introverted/not good at interviewing -- a personality trait that I've found to be common and for every job I've done interviews for -- not a negative (and can just as much be a positive) for the work I was assisting in hiring for. One of the hardest working people I know -- a guy I'd work with on literally anything because he'll make up for any deficiencies with sheer will and hard work -- has such anxiety in interviews that he actually forgot his middle name in an interview (not completely, he just spaced -- hard -- my boss hired him anyway on my strong recommendation).
[4] A small tip: Complimenting the work is an easy way to get things started smoothly -- it doesn't need to be phony; there's usually some way to point out a few positive things about the work. Start there, ask questions in a manner that simply states a desire to understand the code more, and let things roll from there.