[robert_tweed]

This is a format that I've thought for some time would work exceptionally well in technical interviews: rather than ask a bunch of questions, have a small set of problems that start from a working piece of code in need of work.

This removes some of the subjectivity from a completely open-ended coding assignment, as well as reducing the amount of effort required, because you can do a few small problems rather than a single huge one that typically involves working over a weekend.

The only downside is it's a lot more effort to set up than either an open assignment or a standard Q&A-based interview. You don't want to throw anyone into real production problems for a variety of reasons. The initial setup has to be understandable within a few minutes of code review.

[meowface]

Everything I've ever read or heard about technical interviewing in the past 5 years basically says your idea (and other work sample-type things) is the way to go. And it's kind of obvious when you think about it. Seeing how someone works in practice is almost always going to tell you a lot more about their potential effectiveness as an employee compared to only asking them a bunch of questions or having them solve a puzzle or whiteboard a CS algorithm.