The real problem here isn't coding interviews; its how we (hiring managers) approach the entire question.
The goals of a technical interview should be:
- Confirm the credentials presented aren't complete BS
- Validate they know enough to be immediately helpful
- Assess their long term potential (brains, social skills)
Coding challenges tend to be good at the first two points but very questionable for the third. Incidentally, given that I'm seeing a 50% washout rate from a basic SQL code question (supported by confessions from candidates that they fabricated credentials/experience), you would be silly not to include some form of practical test.
The third point (potential) is best measured by talking with them about a project they really cared about. For those who cannot share work examples, pick a good side project. Don't get hung up on the content - focus on their passion. You'll get a better view of my capabilities if you chat with me about building an ad server, mobile optimization, or SEO analytics (real world projects I care about) than with a contrived example.
As for the github profile of code shrugs why? Seems like a bit of a cult to me. I'm happy to sharing anything that's useful (and do so on my blog) but don't have the free time to spend developing code for the sake of "work samples". My work samples run on production servers as commercial projects, thank you very much..... Suspect many other good candidates are the same.
"you would be silly not to include some form of practical test"
Yes, I'm coming to the realisation that it's idealistic to assume that anyone with N years experience will be at a certain level of ability.
"(potential) is best measured by talking with them about a project they really cared about"
I agree. I've always thought that once you've made sure that a candidate's programming knowledge isn't fabricated, the best way to evaluate them is to get talking about code. Whether that's proprietary code they've written but can't share, or it's on a GitHub profile for all to see shouldn't make a huge difference.
One of the best interviews I 'gave' was when the interview was for a position programming on a topic I knew almost nothing about. I had the person bring their laptop and walk me through their implementation of the topic at hand, then asked how they'd scale/improve it given more cpu/memory/etc and what kind of constraints the larger environment would impose upon the work.
The goals of a technical interview should be: - Confirm the credentials presented aren't complete BS - Validate they know enough to be immediately helpful - Assess their long term potential (brains, social skills)
Coding challenges tend to be good at the first two points but very questionable for the third. Incidentally, given that I'm seeing a 50% washout rate from a basic SQL code question (supported by confessions from candidates that they fabricated credentials/experience), you would be silly not to include some form of practical test.
The third point (potential) is best measured by talking with them about a project they really cared about. For those who cannot share work examples, pick a good side project. Don't get hung up on the content - focus on their passion. You'll get a better view of my capabilities if you chat with me about building an ad server, mobile optimization, or SEO analytics (real world projects I care about) than with a contrived example.
As for the github profile of code shrugs why? Seems like a bit of a cult to me. I'm happy to sharing anything that's useful (and do so on my blog) but don't have the free time to spend developing code for the sake of "work samples". My work samples run on production servers as commercial projects, thank you very much..... Suspect many other good candidates are the same.