I realize that I "should" like code samples, on the going ideology and considering the real problem of non-Fizzbuzzing programmers, but I don't find them useful and only do them when I'm unemployed (which hasn't been an issue for a few years). My problem with them, based on experience, is that they only provide downside. Used a language that the team doesn't like? Too bad. (Once I was told that I shouldn't have used Scala for a code sample, because the company-- a shitty Java Shop-- had recently fired someone who was a Scala advocate.) Didn't test your code using the style that the company implicitly expects? Points off. On the other hand, I've had the experience, in the past, of submitting samples that I was told were among the top 3 the company had ever seen... and still been offered a junior or mid-level role (this was in my mid-20s). So I don't see the upside. Why spend 12 hours of my own time on a code sample, only to get the same junior-level position I could have gotten anywhere else
without homework?
If a kick-ass code sample could have turned a junior-level engineer position at 0.01% into a Director-equivalent (I like being a full-time coder and don't need reports, but I generally prefer that management see me as an equal, so I can get my job done, because a 10x engineer disempowered is a -3x engineer) with above-market compensation and legitimate equity, then I'd say... yeah, these things can spot early talent that nothing else does. But, as far as my experience has led me to think, code samples just provide another reason to reject someone. ("This guy used the TestEase framework instead of EasyTest. What, does he think it's 2013??")
I'm a good technical interviewer. I'll say it: I'm very good at it. The first thing I do is that I explain my methodology, rather than hiding what I'm after, so the candidate is at ease and not surprised by difficult questions. I tend to prefer a "rapid fire" approach to collect as much data as possible, so as soon as she's demonstrated that she knows what she's talking about, I'll move on to another question or topic... and I disclose that this isn't to be rude but so I can get the best read possible. I tell the candidate that, unless she is a 0.1% outlier, I will ask questions where she doesn't know the answers, and that's OK. It's not a percentage-based test where you need to get 80% right or it's a no-go, but it's a binary search on the competence spectrum. Generally I'll take something on her CV that I'm familiar with, research it a little bit, and start with a mid-level question that I'd expect 75% of the people I'd want to hire to get. (Statistically, you get your best results by adaptively asking questions at a level of difficulty where there's a 50% chance of success. But I aim for ~75% because most candidates aren't used to difficult interviews, and I don't want anyone to freak out.) That means that there's a 25% false-negative among good candidates, so if she doesn't know the answer (and it's OK to say "I don't know"; I'm in the top couple percent of my field and still have numerous blind spots) then I'll give her another question, also of moderate-high difficulty. (I don't start giving easy questions unless I've decided on a "No", and that's usually to put the candidate at ease, because I might still be wrong, and I want the next interviewer to get a clean read.) A good interviewing process provides multiple paths to success, not multiple ways to trip up and fail. I prefer to ask hard questions rather than easy ones because, as far as I'm concerned, 5 hard questions is multiple paths to success (if you get 1 or 2, you're solid; 3-4 means you're excellent) whereas 5 easy questions is multiple paths to failure.
I know I come off as an asshole on Hacker News (because it's turning into this festering pit of pro-corporate Wrongness on the Internet, and someone has to do something about it) but I try to be as nice as possible during interviews. I want to be tough, intellectually, but I want the person at ease as much as possible (which is why I explain, ahead of time, that I've been a notoriously difficult interviewer at every company where I've worked) so I don't get a false negative. I generally give a series of hard questions (not all related to each other) that seem relevant to her experience. I might give four, and a candidate who can competently answer one of them, I would generally say is worth considering. If she gets 2-3 out of 4 hard questions right, then she's probably a good hire and I'll recommend her.
I don't think hiring engineers is as hard as people make it out to be. I do like to see code, but I can usually tell the socially adept non-coders and charlatans from people who can actually program, even without looking at a line of code. I tend to prefer to hire for general intelligence than a specialized "hole" that someone is trying to fill, and the main question in my mind isn't, "Did she get all of my questions right?" but "Would I want to work with this person?" and "Would she add something to the team that's not already there?" I won't remember, 90 minutes later, whether she answered every single question right, and if she screwed up and said "Lasso" when she meant "elastic net", that's not terribly important... probably a mistake, and knowing the ideas is more important than the vocabulary. Besides, I care more about hiring the person who has the curiosity and drive to learn new things than hiring the one who already knows what we're "looking for", because the latter changes in most companies by the quarter, while a candidate's general ability doesn't.
Bad hires tend to come from two sources. One is when non-technical people override the technical interviewers, either formally or informally. It's best to have an environment where people can speak freely and, preferably, independently (i.e. each interviewer is on the spot to give feedback before discussing the candidate with others, but also feels safe giving an honest read). The worst thing that can happen is when an executive says, "This person is amazing", before any feedback has been given. In many companies, that means that the decision is already made and the engineers are just there to ratify it. That produces a lot of underqualified hires. The second is stack-ranking, which encourages teams to keep an "insurance incompetent" on hand, so that the middling and top players can safely focus on work, knowing that they won't end up in the bottom pool. In companies with stack-ranking, however, I would generally avoid interviewing as much as possible. (In fact, this may be one reason why companies that use stack-ranking tend to decline.) If stack-ranking is in play, you need to focus solely on (1) your main project, (2) getting credit for what you do (the politics of performance, which is more important than performance itself), and (3) being perceived as a top performer without actually trying to outrun the bear (outrun the other guy, and he gets eaten; outrunning the bear is impossible). If you're in a stack-rank company, then interviewing is that class of work that's good for the company but won't improve your Perf score, so you should avoid doing it as much as possible.