A while back our company switched to the "homework" format for evaluating software engineering proficiency because we felt like it took a lot of stress off of candidates to write code in an unfamiliar environment (or worse, on a whiteboard). And I feel like it's worked out really well. But we have pretty strict criteria for any homework problem: it needs to be a simplified/toy version of something we'd actually ask the person to do if hired, and it needs to be something that a qualified candidate could easily complete in an hour.

The code itself is, of course, valuable for helping us to evaluate, but honestly some of the best signals we get come from the open-ended discussion that results from us talking with the candidate about their code when they are done: "imagine this file you're processing is 100TB instead of 100kb? Would you change anything?" or "What if this clean data you've been given to work with had this or that issue, what might you do?"

My only point of disagreement with this article is that it seems to assume that a homework problem has to be really time-consuming or burdensome, but there's no reason that has to be the case. To me employers who are asking candidates to spend hours or days on homework are of a piece with ones who ask people to solve tricky, unrepresentative computer science problems on a whiteboard: they reveal that they don't really know how to interview people and they don't have much respect for their candidates.