The best interview test I've done was a take-home test with a fixed time window. I was given a working development environment with an existing app and asked to

The best interview test I've done was a take-home test with a fixed time window. I was given a working development environment with an existing app and asked to fix some tests, implement new tests and then implement a few new features with tests. It was good because: 1. There was no faffing about to set up the environment 2. There was some small, easy wins at the beginning which got me engaged and thinking about the task. 3. It was fixed time - I had to specify when I would start and then the test was emailed to me 15 minutes before that time. I then had 4 hours to return it via email. This solved most of the problems I've seen with take-home tests - namely that they take far too long and ask the candidate to do all sorts of pointless admin tasks before they can start coding. Unless the candidate happens to be super familiar the exact environment of the test (including setting up a new project - how often do most people start new projects?), you're either making them waste hours of time before they can start, or disregarding good candidates. Ultimately you want to find candidates who can solve problems and understand software architecture. Unless you're interviewing for a devops position, making them spend hours setting up a build environment seems like testing for the wrong thing.