On the subject of GitHub work for hiring: thinking about it as strictly positive or uselessly noisy probably means you have an overly simplistic model for evaluating candidates.
I'll share a model that's worked for me in the past.
I'll share a model that's worked for me in the past.
Before you even write the job description, define the 3-7 traits you need to hire against. These can be as fuzzy as "gets shit done" or as specific as "5+ years marketing SaaS to $100k+ accounts" or "is effective at resolving incidents while on-call."
You need to be able to rate people on this. Binary is fine ("yes they can get shit done"). 3-4 levels is good (bad / good / total superstar).
Don't go overboard with granularity: you need to fit this all in your head for a couple candidates at a time when you compare them.
Don't go overboard with granularity: you need to fit this all in your head for a couple candidates at a time when you compare them.
As you go through your process, try to get good information about at least one of these areas at each step.
My favorite thing to do is, between in-person interviews, be able to tee up the next interviewer with "I got mixed signals about communication style. Can you dig in?"
My favorite thing to do is, between in-person interviews, be able to tee up the next interviewer with "I got mixed signals about communication style. Can you dig in?"
When you wrap up, make sure you cover all the boxes. Don't get smitten with a candidate with amazing experience who can code circles around everybody else who's never worked in a 25+ person team (assuming that's what you agreed was important).
When you're ready to make a decision, you now have a reasonable set of trade-offs to make. I tend to create rubrics where solid scores in 3 of 5 categories is a Hire, to allow us to compare different types of candidates.
Ok, back to GitHub.
GitHub can give you VERY STRONG SIGNALS for some of these issues. It's great to be able to know up-front that somebody is comfortable working with teams they don't personally know well (typical in big open-source projects).
GitHub can give you VERY STRONG SIGNALS for some of these issues. It's great to be able to know up-front that somebody is comfortable working with teams they don't personally know well (typical in big open-source projects).
The convese to that is that I generally expect some strong signal up front from any candidate. If not GitHub, give me a respected company on your resume. A recommendation from a mutual friend. A well-written cover letter.
When folks complain about 100s of resumes, it's because the problem is this lack of signal.
An aside: it's on you to allow folks with non-traditional backgrounds to succeed at this step. Write a better job req, or go email likely candidates. Diversity requires multiple ways in.
An aside: it's on you to allow folks with non-traditional backgrounds to succeed at this step. Write a better job req, or go email likely candidates. Diversity requires multiple ways in.
Once you're a bit further, this cuts the other way. If "good communication in pull requests" is important to you, don't spend any time here with candidates who have strong Githubs.
You already have all the data you need. Spend your time elsewhere. There is no extra credit.
You already have all the data you need. Spend your time elsewhere. There is no extra credit.
GitHub can help you a bunch when evaluating candidates, but it's crucial to stay away from this notion that _anything_ during an evaluation that looks like a silver bullet.
You always have to do the work of interviewing well, and it's always specific to your company.
You always have to do the work of interviewing well, and it's always specific to your company.
Finally: if you have a process that allows you to fully evaluate a candidate by reading their public GitHub, you're almost certainly hiring for the wrong things.
unroll pls
