A code sample is a pretty efficient way of weeding out candidates - I can judge a code sample in 5 - 10 minutes, but even a phone screen takes 15 minutes and needs scheduling (and isn't terribly useful in weeding out anything but the very bottom of the pile in my experience).
I think the main objections to code samples are two fold, and are easily overcome:
- that requiring a code sample puts up an artificial barrier for some talented developers
Obviously, this is true. Any barrier in the application or hiring process may potentially weed out a desirable candidate. The important thing here is to know your audience - if you have 1000 resumes for your one opening, you can afford some false negatives in service of efficiency. If you have five resumes, you can afford some inefficiencies in the screening process.
What I think most people miss, though, is that interviewing and hiring is basically a game of "find a reason not to hire this person". For any decent job, there's a lot of qualified applicants - the last one standing is usually the one that didn't set off any red flags along the way. It's easy to see the best in people or be non-committal, but that doesn't do you any good in hiring because you'll end up with 10 different candidates that you're comfortable with. That doesn't get you any closer to a decision.
Every tidbit you collect along the way of reviewing, screening, interviewing, etc. could potentially trigger a no-hire decision. You have to balance the sensitivity of your no-hire trigger with your current (and potential future) prospects. If you're in a boring industry, with lots of legacy code, bureaucracy and poor salary (often things out of your control) then your trigger needs to be less sensitive than say, Google. Otherwise, you'll run the risk of never hiring anyone.
Personally, I find the easiest compromise for me has been to request but not require a code sample. If I get one, it's just an additional data point to evaluate the candidate with. Similarly, if I happen to have an acquaintance that has worked with the candidate in the past, I'll attach some weight to that acquaintance's opinions. Not having worked with anyone I know certainly doesn't disqualify any candidates though - it just means that my job in evaluating them is a bit harder (and will probably include a coding exercise if they make it to an interview). If your sample is poor (or my acquaintance bad mouths you), it's pretty much a no-hire. Those that provide a sample may or may not have a small leg up on those that don't in initial screening - depending on the quality and quantity of the resume stack and samples, more information may be better or worse than no information.
- that samples are easily faked
Well, yeah. So are resumes - but we still collect those. Why? For three main reasons - a poor resume or sample is an easy no-hire, being caught faking a resume or sample is an easy no-hire, and they're good conversation topics in an interview. The quicker I can figure out the candidate is a dolt, the better for everyone.
If you're smart enough to plagiarize a good sample without being caught, talk intelligently about it, and get through the interview - I don't particularly have a problem with how you got past the screening. There may be some ethical concerns here, but that's not really my area of expertise, so I'm not going out of my way to evaluate moral character during an interview. To me, it's virtually the same as my boss asking me to interview someone who didn't get through the screening process as a favor. Once you're at the interview stage, it doesn't really matter how you got there since there's so much more and better information that will come out during the interview.
TL;DR - a code sample is a great screening tool, but you should think carefully whether you can do require it or not. Once past screening, weight the interview much higher than a sample.