why does it have to happen in a high pressure situation with only 45 minutes though? there's no analog to that in professional coding.
That doesn't indict the fact that's the exception and that software programming almost never looks like that.
The real problem is that take home problems are trivially gameable - it's obvious to someone unscrupulous who's not a well-seasoned coder, that it would be well worth paying someone else to do their take-home-interview-homework. (Sure, that would come out eventually, but that's only one of the problems I have with take-home assignments.)
Some places have "open book" interviews, where it's like "here's a laptop, do this thing, and google/stack overflow/devdocs" your way to victory, which is at least better than the older "how much trivia do you remember about this API"-style questions. But I have no idea how to go further and make that unbound by time when an employee is on the other end of the table listening to the interviewee's thought process, if only because it makes it very hard on the interviewer to plan their own time. (Especially considering maker vs manager time.)
In the years I have been doing take-home exercises for candidates, I have yet to see a single instance of a great take home leading to a terrible on-site or hire in terms of technical skill. There have definitely been great take-homes for candidates that we later chose not to hire, but usually due to challenges interacting with the product team, or in some cases too much fixation on technical perfection with no focus on business realities, etc. If there are a large number of candidates paying others to do their take homes for them, they should be asking for refunds.
Second, even if this is a problem, there's a very simple solution. For candidates that do well on the take home, either on a call or on the on-site, do a live code review with the candidate and ask them to explain a bit more about why they wrote the code the way that they did. Ask them questions about other approaches, or what they'd do if they have more time. Candidates will be significantly more comfortable talking about their own code they wrote. It'll be quite clear if the candidate didn't write it themselves.
Anyway, I thought it was robust but not too time-consuming interview process. I think such an interview could use a reasonably-sized open source project for this, instead of their internal code base.