Wow, that's pretty awful. I might posit some rules for good take-home tests: 1. A very loose time limit. Maybe, as a rule of thumb, at least 10x the time you

Wow, that's pretty awful. I might posit some rules for good take-home tests: 1. A very loose time limit. Maybe, as a rule of thumb, at least 10x the time you expect the challenge to take (so, a 1-hour challenge is given a 10-hour limit to turn it in, and a 5-hour challenge is given two days). If you expect it to be done in real time, why they heck don't you just bring the candidate in for a normal interview? 2. If the challenge is expected to take more than, say, 5 hours, the candidate should be paid for their time. Long challenges are going to disincentive candidates with lots of good alternatives to your company, so compensating them as in your own interest if you want good engineers to make it through your process. Plus, it's a strong signal that you value their time. 3. The challenge should be as close as possible to the sort of thing you do day-to-day. This should be obvious, but don't ask math questions or graph traversal questions unless this sort of thing comes up regularly in the job you're hiring for. 4. The candidate should be given an opportunity to discuss their solution. In real-life code, a seemingly stupid decision is may well be totally justifiable, but not obviously so from the code itself. 5. The candidate always gets an explanation of why they were rejected. At one company I worked at, I was in the position of reviewing takehome tests (which were one component of a longer process which involved some on-site coding). I had to write those explanations, and I know it's hard. It's easy to say "your skills are not a good fit at this time", but it's hard to tell someone you don't know what's wrong with something they put a lot of work into. It's still worth doing.