Earlier quoted context omitted.
To be useful for discriminating between competent candidates, a challenge has to either be hard to complete (pass based on completion) or hard to complete to a high standard of quality (pass based on completion+quality). In other words, it has to be at the limits of what's possible for people you expect to apply for the job. If you give me a 2 hour challenge with a timer so I can't possibly take more than 2 hours, I'…
> To be useful for discriminating between competent candidates, I helped redesign the code challenge at one of the companies I worked for. We (the people across the different technical disciplines we hired for) put a lot of effort into ensuring that: * the challenge could be completed in 4 hours * the challenge resembled the sort of work people would do on the job * the goal of the challenge was to inform a follow up…
Unless your challenge literally stops at, "make X appear onscreen" with no regard for quality, testing, etc. Giving unchecked/unverified time restraints isn't fair. It doesn't matter you're giving more time than it should take to complete. If the task can be done in 2 hours, but you give "6" and Candidate A does it in 3, but Candidate B does it in 32 (but tells you 6) you're ranking two totally different submissions. Candidate B might have a super polished submission, while Candidate A has a baseline submission.
The poster you replied to was suggesting that tests should be either 1) not based on quality of submission and simply rely on difficulty so that only a few candidates can complete them or 2) based on quality and difficulty, but with a checked and verified time to keep the playing field level. However those options are both at odds with "low stress."