I (and many people who I've hired) don't have time to waste on your startup. I can tell within two minutes if someone can code or not. I've never understood the need to have someone write code (and then nitpickingly critique the code because it doesn't look like my code) when I can just ask them and know if they are lying or not.
And I've hired a LOT of super fantastic programmers.
The only reason I was putting up with them was because of friend inside who had referred me. The thing is they made me right endless code rounds after rounds and I did code pretty well. I solved close to 90% of the problems without the internet. But most of them were coding problems.
During the final rounds, I don't know what got into them. They started going into Core CS areas. And damn then they started the Algo pop quiz. Some how during the last 3-4 rounds they started giving out the perception that they were not happy with some one who did not know the algorithms from the book memorized by heart. And that even good coding skills can't compensate for that.
After that they called me back and told, that some other department from the same company would like to have an another round. I just politely denied and, cut the call.
Oddly enough, when you decline to continue interviewing they often immediately send you a job offer.
I wouldn't have accepted the offer from the company, from the very outlook it looked like bureaucratic jungle where no one is capable of taking a decision/risk until they run through some 20 meetings to decide what to do. And then toss it on to some one else.
For that if this is what you make candidate run through, you are sure to get CareerCup interview questions ebook masters but not good programmers.
Though in our case there wasn't too much structure day-to-day, there was total lack of structure.
Common knowledge is that hiring programmers is insanely difficult. If you have a gift for it, you could make craptonnes of money!
It's everything else that is the problem. Are they lazy? Do disappear for days at a time? Will they not fix bugs in someone else's code? Will they complain NIH at the drop of a hat. Will they care to write all the ugly code we need to ship with, and not just the first 80% of the project?
These are the things that are hard to assess. But just knowing if they can code -- that's pretty easy.
† List exaggerated
It was also a burden on our team to spend all this time with a candidate, so this would often be our last step.
We would next expect someone to invest in us if we did not also invest time on our end.
Our test was not primarily just code quality.
When we brought people in we would look at:
1. Approach. Did they use e.g. an open source pre-existing module or write something themselves? Did they come up with a creative solution?
2. Culture fit. While they were in working with us, how did they interact with the team? Did they enjoy working with us and vice versa?
3. Productivity. How much did they actually get done?
As for culture fit, again, a socially competent interviewer can size these things up reasonably quickly.
I mean, a half-day programming test feels excessive. Are you worried about loosing good candidates that just don't want to deal with the headaches?
I've heard people try to justify insane hiring processes by saying "we want to filter out the people that don't want to work here. We only want people that really want it." But the best programmers -- the ones you want to hire -- are going to be in high demand by companies that look at their github, have a three minute interview, and pull the trigger.
A lot of people about to make a long term commitment to a company also want to make sure the company is right for them. So this was a good way to get to know one another.
I couldn't care less about the problem OR the eventual solution. I couldn't care less if he used an open source module to write some new code last week or if he thinks CouchDB is super amazing.
What I really want to know is how they think.
When you have a programmer who lives in code, he (or she) swim through problems like they are physical objects. They find passion in killing bugs and making code more efficient. I can hire a hundred people who can recite what the Gang of Four is or write a bubble sort. I can't hire guys who care about whether their own code can be improved.
But this is just one way. There are lots of ways to tell.
When I interviewed for previous copmanies, this is actually one of the questions I would use. "What is the hardest bug you've ever worked on?" If you take this question, and keep pressing for more and more details, and expand on that question, you can get a surprising amount of information about someone's experience and understanding. If they can't adequately answer this question, it means they haven't really been deep in code, or don't have a lot of experience, so that sets your expectations relative to the position that you're hiring for. If they claim to have a lot of experience, but can't go into too much depth, it means they're not very excited about getting their hands dirty or they don't understand what really happened, which are both bad signs to me.
I don't care if they can write up a function that can spit out the Fibonacci sequence. I can that they are smart enough to figure out relatively complex issues and can communicate this intelligently.
There are real diminishing returns on technical interviews. If you've got well thought out, well structured questions that cover the key areas for your organisation, unless you're doing something massively complex or specific, you can work out whether someone has the level of competence you're looking for in a couple of hours.
How?
If they don't ask for relevant details, etc, they won't be coming up with a solution no matter how they do it.
If you feel like you even have to ask these questions your candidate selection process is badly broken, but the same approach scales up to all levels.