Having been on the hiring side of that, we spent way more time coming up with and testing the take home project than our applicants ever spent on it. Among other things, we'd beta test a proposed "challenge" on each other to see how well it worked out in real life before springing it on candidate.
It would have been a lot cheaper not to have the take home project, but we decided it was worthwhile anyway.
(Disclosure: our project looked a lot like a story you'd be asked to work on in your first week with us. There was none of that "hiring for a Python backend engineer; here's a Scala data engineering project" nonsense.)
You spent that much time over several dev sprints/cycles/months/whatever. Meticulously designing the expected output and quality expectations(yet not sharing any of that in the spec supplied to the candidate). All that automated testing, manual code review checklist was designed after spending that many man hours worth effort to arrive at. You have the benefit of hindsight, and insights from the process that refined over that much time. Plus you have inputs from several candidates you failed your test.
Yet now the candidate has no luxury of that, and has to guess the assumptions required to not just produce all the features, but also the quality metrics the project will be measured against. All in the deadline given by you. And he is at day 1, and that's all the day they have.
This is really like expecting some one to fix a problem in a day, what the other person spent months solving.
Agreed and what your describing actually happens in a lot of work environments. I've seen a trend in the last few years where middle management is attempting to separate "programmers" from "engineers/architects". In these environments the "programmers" don't really have the luxury of sitting with the business or product teams nor the luxury of taking part in the design process.
What ensues is actually comical. During "grooming" sessions the "programmers" are meant to give accurate estimates of how long (I know time is not meant to be the metric but it always is) a story will take to complete. A story which there are many, many person hours of context baked in that the "programmer" is seeing for the first time.
It would have been a lot cheaper not to have the take home project, but we decided it was worthwhile anyway.
(Disclosure: our project looked a lot like a story you'd be asked to work on in your first week with us. There was none of that "hiring for a Python backend engineer; here's a Scala data engineering project" nonsense.)