[gtolle]

I love this approach. I'm also wondering what you think about giving well-designed work-sample tests over Google Hangout instead.

The candidate shares their screen with you, so you can watch as they solve the problem in their own dev environment. You can understand how they approach problems (quick and dirty, slow and methodical, lots of rewriting, etc), and you can ask questions at the end. You get a good sense for how they work as an engineer even before having to bring them onsite.

This seems to resolve the time asymmetry of take-home tests as well -- the interviewer spends as much time watching as the candidate spends working.

The only downside I can see is that you have to design your problems to take about an hour instead of the 2-5 hours you could imagine for a take-home test. But, you can break them up into multiple rounds, and give additional exercises to the candidates who do well on the first one, for no more total time cost than a collection of onsite interviews.

For what it's worth, I've done this at my startup and hired a great developer, and got very positive feedback about the process from the candidates I didn't end up hiring.

[crzwdjk]

As someone who's had to do a few take home tests as well as coding with someone looking over my shoulder, I am definitely not a fan of the latter. I prefer to sit down and think about a problem, maybe even read it and let it sit in my head for a day or two before I actually start the coding. I also feel like shortening the time and making it synchronous would remove the opportunity to revise and polish the code I've written, which is one of the advantages of the take-home test format.

My ideal interview format would involve a work sample test, followed by a code review of said work sample, and also a reverse code review (candidate is given some code to review). As an added bonus, all of this can easily be done over email without wasting too much of anyone's time, especially compared to an all day in-person interview with lots of whiteboard time.