For it to work, you obviously need to impose some constraints - it's unreasonable (IMO) to demand too much time and energy out of candidates, but it should also be complex enough to highlight a wide variety of skills.
But what's more important, is how you use it. It's an excellent tool in interviews, because you can pretty much spend an entire (technical) interview just discussing their implementation, and have more low-stress discussions around their choices and strategies.
A good and experienced candidate will both showcase good code, and will be able to discuss quite fluidly and in-depth around their various choices. And if you want them to expand a bit one some technical things, you can just ask them then and there.
But, again, I understand this is a wildly polarized method. Some coders would rather spend xxx hours on leetcode / hacker rank / etc. and learn every problem under the sun, and then tackle some random whiteboard question.
I guess if you're fresh out of academia, that's the method which most resembles your previous experiences with testing. Some are good test-takers and love trivia.
But for me, I'll stick with the take-home problems for now. Both when looking for devs, and when looking for jobs myself. Simply put, you get more data out of such problems. If a candidate cheats by hiring someone to do their work, it'll more likely than not still show up under the interview and questioning.
edit: But as mentioned, it all boils down to how well you design such problems, how they are executed, and how you choose to use them in interviews. There are many ways to effectively render them useless, or even hurt your chances at attracting good devs.