I would argue that take-home project-based interviews are one of the better developer interviewing tools I've encountered. They're realistic work-sample tests, they're low pressure, and they are very high-signal.
They do have the flaw that they might not weed out candidates that are really slow (since they can generally take as much time as they want on a take-home project). They also don't weed out candidates who are willing to have someone else help them significantly with the project.
As such, I've found take-home projects useful in addition to an onsite interview. At a previous company, we would follow up a take-home project with an onsite interview involving a couple 1-hour "code this using any tools/resources you want with no one looking over your shoulder" questions to prove that they didn't cheat on the take-home and that they can get things done in a reasonable timeframe. I always felt it was a pretty useful way of evaluating programmer skill without stupid whiteboard coding.
After the work is submitted the following day, if it looks good then call them in for an interview and ask them what were the weak points of the solution. If the developer is good, they will have worked it over in their head for the next day or two, and will have an answer ready.
Asking questions about the work produced is a good way to identify people who cheated. Ask questions about why and what was your intent with this.
Yep; we did that too. The flow was something like:
- Phone screen with our HR rep to figure out if you're even remotely what we're looking for
- Takehome challenge to make sure you can code
- Engineer reviews the challenge and, if good, calls you to discuss the challenge and discuss your experience in depth.
- If good, come onsite to meet the team, do a couple 1-hour use-anything challenges, and answer a few higher level long-form questions.
- Offer.
They do have the flaw that they might not weed out candidates that are really slow (since they can generally take as much time as they want on a take-home project). They also don't weed out candidates who are willing to have someone else help them significantly with the project.
As such, I've found take-home projects useful in addition to an onsite interview. At a previous company, we would follow up a take-home project with an onsite interview involving a couple 1-hour "code this using any tools/resources you want with no one looking over your shoulder" questions to prove that they didn't cheat on the take-home and that they can get things done in a reasonable timeframe. I always felt it was a pretty useful way of evaluating programmer skill without stupid whiteboard coding.