Agreed. I prefer testing how well a candidate can dive into other peoples' code, understand it, and make changes to meet a spec. To respect their at-home and in

Agreed. I prefer testing how well a candidate can dive into other peoples' code, understand it, and make changes to meet a spec. To respect their at-home and in-person time, that means sending them a small and straightforward codebase, making them extend it in clearly pass-fail ways, and then when they come in you have them talk about the code and extend it a bit more. The take-home portion serves a few purposes: it filters out uninterested applicants, weeds out non-coders, and lets people prepare in their own time and way (rather than on the spot in an interview). The in-person portion then checks that the candidate can do the work themselves, can communicate about their work, isn't obviously a pain to work with. Most take-homes test the wrong things: whether someone can start a greenfield project, think up interesting new features, or put in more extra hours than their competition. And most in-person interviews test the wrong things too: have you studied interview problems, are you good at coding and problem-solving out loud under time pressure, and how well do you scrawl syntactically correct code on a whiteboard.