[mdip]

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.

[jadavies]

Interesting, thanks. Do you specifically ask the candidates if the code in their repository is all their own work? One small thing that worries me about relying on GitHub is that I can't be 100% sure that the author actually wrote all of it.

[mdip]

Yes. But mainly only to direct my questions. Whether or not they were the primary author was mostly only important in knowing how well they knew the code in question. If it was written entirely by someone else but they fully understood the code, that worked for me, too.

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")