Yeah, this reminds me of the "interview" I did for SpiderOak. I had built and launched various products by myself by then, so my experience in Web apps was very prominent in my resume. They asked me to spend a few hours implementing a commenting FAQ system or something like that, which was pretty much just some CRUD views with CAPTCHAs etc.

I said I didn't really feel comfortable spending hours of work on something for an interview, but I did it anyway, because it sounded like an interesting company to work for. They took my submission, said something about "we'll see if we can arrange some compensation" and then never emailed me again.

A few weeks later, their FAQ section was updated with pages and a commenting system. Worst interview ever.

This is exactly my worry when asked to do some 'real' work for a company I'm interviewing with. There are many unscrupulous companies out there so you have to be careful. A better way might be to get the candidate to do a task that isn't on company todo list, but instead is something the candidate is interested in. That might even open up a few conversations about the candidate which may help the decision process. Just a thought anyway, no idea if that could actually work. I do know we need something other than the series of pointless brain-teaser style questions companies are asking these days.

The best interviews I've done were ones where we just talked about what technologies we like, where we've used them, etc. You just know you're talking someone who enjoys development as much as you do, and you can share your experiences with stacks you haven't used, etc. My favorite was one (I think I was the one doing the interview) where we talked about CouchDB, its pitfalls, its strengths, etc (the other guy had used it somewhere), and it was just honest chat between two people with the same interests. We ended up hiring the guy and he was great.

Much better than a "spend three hours implementing something we need and send it to us, and we'll never talk to you again" faux-interview.

The problem is that there are some people who are very, very good at bullshitting. They can talk the talk - but not walk the walk.

I've had several occasions where somebody I was sure would ace the coding has fouled up badly. And not "little bit nervous" badly, but "wow - you have put significant effort into learning how to lie during an interview" badly.

One was early in my career, when I didn't do coding tests, and they got hired. It was an expensive mistake. I've encountered enough of 'em to want to stop myself ever making that mistake again. Never hire a juggler without seeing them juggle (http://raganwald.com/2006/07/hiring-juggler_02.html).

Sure, but there's a huge difference between a coding test and writing a CRUD app that's 99% chore, 1% knowledge. The interviewee can demonstrate their knowledge by writing a few simple views of a few lines each, for example.

I like this idea! I think that it makes sense for prospects that are either already contractors, or perhaps the unemployed.

If you already have a job, then I can see some challenges though - I'd imagine a candidate for Google would not be able to accept payment for doing work while being employed by Facebook, for example. Did you ever run into an issue like that?

That particular objection has never come up. If it did I'd do as others have suggested and offer to donate to charity, amazon vouchers, or similar.

The issue that has come up is, as @rubinelli identified, tax hassles. In those instances we've gone the charity route.

(It's interesting actually. Now that I think of it the payment isn't really the issue. It's that we are visibly demonstrating how we value the interviewee's time.)

I can imagine you can just offer to donate to a charity of their choice instead?

Good point. But I suppose you can maybe get round this by, say, giving candidates amazon vouchers or something? (I don't know what the employment contracts stipulate on either companies though with regards to gifts and such)

It is common for large companies to have policies stating employees have to report a gift above a certain value, but that's mostly to prevent outright bribery (which still happens anyway, in most procurement departments).

Paying cash can create some tax complications that vouchers avoid too.

Wow, that's a great idea. You're absolutely right, compared to the total cost of hiring, it's practically nothing. Throw in the fact that you're in about 100x as good a position to evaluate talent, and it seems like a no-brainer. Like scouting football players by watching them play football vs. measuring their broad jump.

I also think this is a good idea. If I was asked to spend an afternoon solving problems that aren't theoretical 'how do you sort an array of a billion integers' type then I wouldn't want to do it for free.

If it gains traction it might reduce the crazy interview only questions from circulation.

How do you handle the tax implications (specifically in the case of non-hires)?

You essentially brought them on as a 1099 contractor for the day, so in January your accountant sends them a 1099-MISC and they report it as earnings.

This is an excellent attitude - and especially in software development where there is often a not insignificant amount of coding done by the candidates. Several interviews I've been to have involved a full day of pair coding with various members of the dev team on current production code - it seems fair to at least offer something for the work.