It is the central problem in the software development community right now that we have no good objective way to measure software quality. Without that measure we can't judge software methodologies (thus the TDD flame wars) and we can't judge software developers (thus the interview flame wars).
So in each case we come up with proxies for this measure. Having done the interview side of the fence a lot, my strong intuition is that nearly everything people try to measure in developer acquisition strategies either don't correlate or negatively correlate to hiring good developers.
At this point, the only advice I give people about this is figure out a repeatable, measurable process for your organization and measure every single filter you use during hiring. Test the measures on just hired applicants, applicants a few months out, and applicants a few years out. It is time consuming and fraught with problems but there is no magic bullet out of this morass.
Yeah I'm completely fed up with this whole GitHub or GTFO mindset. Many good programmers:
A.) Are great in their dayjobs and don't wish to spend their free time writing Open Source. Maybe they have families. Maybe they have non-coding hobbies.
B.) Work on private repos all the time.
Whiteboarding lets me prove raw problem solving IQ without being negatively judged for lack of twitter followers or technical blog posts.
> Whiteboarding lets me prove raw problem solving IQ without being negatively judged for lack of twitter followers or technical blog posts.
Portfolios allow devs to prove raw problem solving IQ without being negatively judged for lack of documentation or a debugger.
There are developers who aren't good at whiteboarding interviews because they don't think that way and work better when they're at a laptop and can refer to other source code and documentation and can run their code continuously as they write it.
With those devs, they may not look impressive in a whiteboard interview, but you can look at their GitHub portfolio and draw conclusions about their programming ability.
An ideal interview should be holistic and include both off-the-cuff code and polished projects.
"without being negatively judged for lack of documentation or a debugger"
A good judge at a whiteboard won't mark you down for uncertainty about interfaces, which partially ameliorates this, for those cases where you have a good judge...
I'm also tempted to say that needing a debugger to lay out a mostly correct solution to a small problem is weird - can you elaborate on how that might be applicable?
In any event, I agree with your ultimate conclusion - holistic is probably a better way to go.
So in each case we come up with proxies for this measure. Having done the interview side of the fence a lot, my strong intuition is that nearly everything people try to measure in developer acquisition strategies either don't correlate or negatively correlate to hiring good developers.
At this point, the only advice I give people about this is figure out a repeatable, measurable process for your organization and measure every single filter you use during hiring. Test the measures on just hired applicants, applicants a few months out, and applicants a few years out. It is time consuming and fraught with problems but there is no magic bullet out of this morass.