[blakecaldwell]

Coding interviews are very stressful, and churn through a lot of really awesome potential hires. I imagine there are tons of false negatives, but it's nearly impossible for a terrible programmer to get through a gauntlet of programming interviews. However, I agree. They don't give a full picture of a developer's abilities.

As a developer, I prefer take-home projects. As an interviewer, I prefer a few coding interviews, followed by a take-home project.

[platform]

I have not tried it. But in my next business venture, I plan to actually do peer programming with the candidate.

This is will allow members of my team (or myself) to get to know the candidate, evaluate the 'wave lengths', and how effective he/she is at finding patterns on the internet/books -- rather than thinking things up.

It also demonstrates to the candidate commitment on our side, and it naturally forces us to find problems of a proper size/effort (as we are spending the effort too).

We would not do it for all applicants, though -- only for once that pass basic screening / competency process (there are no trick questions or exercises there

[quanticle]

    I have not tried it. But in my next business venture, I plan to actually do 
    peer programming with the candidate.

As a candidate, I can highly recommend peer programming. One of the greatest interview experiences I had was interviewing with a local shop where the employee and I reimplemented a Set class using TDD and pair programming. The employee sat at the keyboard, so I didn't have to deal with not knowing keyboard shortcuts or the unfamiliar operating system (OSX), but he was very careful to only write the code that I asked him to write, and to let me make my own mistakes.

It was one of the most enjoyable, and, dare I say it, relaxing interview experiences I've had. Though I didn't get an offer, I wouldn't hesitate to recommend that company to any of my peers who're looking to make a change. Also, like you said, it was a second tier screen; after an initial screen consisting of a more traditional phone interview where I had to write some Javascript.

[blakecaldwell]

Yeah. You can save a lot of your time, and the candidates' time with a simple coding interview - even FizzBuzz will knock out half of the candidates. Then pair up and/or give a take-home, then discuss the solution in a one-on-one session.

[rurban]

As an interviewer I only look at the resume and published open source projects the candidate did. Everything else just a random impression, nothing serious to bother. The questions are for something else.

[autotune]

I like this approach the most. Evaluate code that they've already written, maybe make sure that they can solve a similar problem to make sure they actually understand what they did and didn't pay someone else to do it, and then a personality fit. Chances are if they really wanted to be hired to learn how to program they're aware of the importance of contributing to open source.

[nsxwolf]

This is frustrating for the many engineers who have no open source work. You're shutting out a massive amount of talent that has only worked on proprietary software.

[quanticle]

    I imagine there are tons of false negatives, but it's nearly impossible for 
    a terrible programmer to get through a gauntlet of programming interviews.

Depends on what you mean by "terrible", I suppose. Yes, coding interviews do a good job at screening out the bozos who just can't program, period. The ones who don't understand the difference between a for loop and a while loop, or the ones who can't handle boolean logic.

But I've found that even once you get past the outright bozos, there are quite a few programmers who can program quick one-off things, but have no sense of design or maintainability. They can deliver functionality, but deliver in a way that piles on technical debt and damages the long term health of the codebase. I think the traditional technical interview format ironically encourages this sort of behavior, by encouraging applicants to focus on narrowly solving the problem at hand, as quickly as possible, both in terms of machine time and programmer time, even if that means the code is an unmaintainable mess in the long run.

Put another way, think back to the last time you had to do any sort of whiteboard coding, as part of an interview. Are you proud of the code that you wrote? Would that code pass code review at your current position? If so, then congratulations. You're a better programmer than I. The code I've written on whiteboards has been pretty uniformly terrible. Sure, it met the correct Big-O complexity requirements, and it was correct, insofar as it produced the correct output, given correct input. But there was no error handling. Variable names were single letters. The functionality wasn't broken up into logical functions because writing additional function headers takes more time, and my handwriting is messy enough when I'm not rushing. All in all, it's code that you'd see in a prototype, or a programming contest entry, not a robust system that's usable by customers.

Lately, I've seen more and more such code being produced by new graduates not only in coding interviews, but also as part of day-to-day programming. There's an incipient attitude of, "Well this code would pass in an interview, so it's production ready." I find it deeply troubling, and my concern is that programming interviews are setting up incentives by which this sort of code becomes, if not normal, then certainly more accepted than it was in the past.

This is why I advocate so heavily for take-home projects. When a candidate submits a take-home project, you can be assured that they had enough time to design and code the assignment in a maintainable way. You can see whether they added unit tests. You can see whether they split the code logically into objects and functions, or whether they smushed everything into a 500-line main(). I accept that take-home assignments aren't as scalable, either from the interviewee side or the interviewer side, but I do worry about the long term effects on norms that programming interviews are having.

EDIT: grammar