Ah, but here's the thing. You can be part of all 3 of those groups (and yummyfajitas' 4th group with no github profile), and still have an easy time picking up work. You just need to have something you can point to.
So we can skip all the above and the developer in question can show you several medium to large web applications running in production, all written entirely by him, some combining to pay his rent, one having won its category (technical achievement) at SXSW.
"There. That's what I can do", he says. "And here's my hourly rate."
No complaining necessary. Get yourself provably good, and all this interview silliness goes away forever.
Individual projects don't show how you work on a team though, nor do they show quality of code unless you submit code samples and those can be and are sometimes faked (taken from an open source project or just not written by them).
Pair programming on the other hand is an excellent way to evaluate how an employee deals with other developers and to get a feel for their quality of code.
Of course as many have suggested in other places in this thread you don't need to do new work. When interviewing candidates myself I like to find a feature/problem from the last 6 months that uses the core job skills I'm looking for and have them work through that. Using current development can feel like free work for them and often doesn't demonstrate the full range of skills you are looking for.
So we can skip all the above and the developer in question can show you several medium to large web applications running in production, all written entirely by him, some combining to pay his rent, one having won its category (technical achievement) at SXSW.
"There. That's what I can do", he says. "And here's my hourly rate."
No complaining necessary. Get yourself provably good, and all this interview silliness goes away forever.