A lot of people in other comments below are criticizing take-home tasks, but honestly, this sounds nice and balanced. I'd much rather have a couple days to think about a problem and a few hours to implement it over having to take time off work, pay to go all the way to your company at a time that works for both of us, and deal with a white board interview. It's a way bigger investment. So long as it's a small, confined, practical problem and not a full app, this sounds good.
Plus, if your company gives someone what they might think are ridiculous questions or they realize it's just not what they're good at, they can easily reject proceeding any farther with the interview. If someone walks into a crappy whiteboard interview, they feel kind of stuck. Seems to be better for both sides. Less pressure.
Despite having a family not much spare time, I also like the take-home approach.
But any time take-home tasks come up on HN, there are always people here complaining about it and even demanding to be paid for their time.
I get that it doesn't suit everyone, but nothing does. Coming up with an approach that works for the company and candidates is really hard - as evidenced by the many, many threads on this subject here on HN.
Perhaps the best compromise would perhaps be to permit the candidate to perform the task there and then or take it home, but this may require more of a commitment from the interviewer, if they then need to additionally devise tasks to be completed in a shorter time.
I oppose take-home tasks as an interviewer. I don't think employees or prospective employees should be taking work home with them, ever. Instead, collaborating on a problem with the interviewee, discussing the problem and potential solutions, observing how the interviewee recognizes when they go off-track, how they respond to hints and suggestions... these are all better signals than the culmination of some homework task, and easily captured in a 30-45 minute interview.
That's not how developers spend the vast majority of their time. It's a poor signal in my experience. What it selects for is candidates who are immediately comfortable collaborating in real time with someone they have never met. That doesn't mean you aren't getting good candidates. What is means is that I spend far less than you finding good candidates because I also hire people who are great developers and who would fail at your interview.
If you're working on hard problems, 30-45 minutes isn't even enough time to fully context shift and get into flow, let alone in an interview where you are a) stressed, b) trying to impress, c) unfamiliar with the specifics of the organization, d) potentially unfamiliar with the industry entirely. This simply isn't enough time to get a sense for how someone thinks or approaches things that are going to be impactful to a large organization except at the most superficial levels. However, if they have a couple hours at their leisure to approach a problem, it's very easy for them to go over how they approached it and where they got stuck in just a few minutes.
The compromise here is to talk about the employee's past projects. The downside is now the interviewer needs to get up to speed quickly, and won't have all the necessary context of the organization and (potentially) industry. Not to mention the fact that candidates lie a lot about how much of a role they actually had in projects.
We have both elements. The code they wrote is subsequently reviewed live with 3 or more of our engineers and all of these aspects are explored.
I think what gives our approach balance is that we are also committing to making a time investment. Reviews typically last an hour, which means that the 2 hours we ask from the candidate is matched with 3-5 hours of our engineers' time to review and discuss with them.
Plus, if your company gives someone what they might think are ridiculous questions or they realize it's just not what they're good at, they can easily reject proceeding any farther with the interview. If someone walks into a crappy whiteboard interview, they feel kind of stuck. Seems to be better for both sides. Less pressure.