So what if they freeze during those 45 minutes? How representative is that scenario for what most devs do?
Also, most problems are not solved in the 45 minutes and in day to day coding , we generally have a minimum of day to think on the problem and solve it without people looking over our shoulder, google or ask someone :)
And presumably fail said interviews because they froze. Usually "I think I need to think about this for a while, or maybe even sleep on it" isn't the answer that the interviewer requires.
As you note, it's normal to need more than 45 minutes to think about a problem that you haven't seen before. Many leetcode type problems puzzled eminent computer scientists and/or algorists/mathematicians for years before they were solved.
Then there's the psychological aspect of when interviewers try to "help" you by asking questions, providing clues or even the specific clever (or stupid) trick needed to solve the algorithm puzzle but really you're in no condition to understand the hints they might be providing.
If a candidate freezes for 45 minutes in a 45 minute interview, they won't get the job.
... Right?
Clearly thinking on your feet in front of people is what it means to be good at ones profession.
And yes, if I ask you a technical question and you freeze, I don't want you on my team. It doesn't mean you're a bad engineer. It means you're not a good fit.
Pretty much sums up how the hiring process is a gamble. So if you don't like somebody and they could be an asset to the company you would not hire them?
* I confirm that day to day business problems rarely are the sort of problems you find on Leetcode.
* I might ask similar questions in interview. I don't expect the candidate to solve them. As a matter of facts, I don't care if the candidate actually solves them or not. I am observing how the candidate behaves in front of a difficult problem. Will they freeze? Will they jump head in the code? Can they articulate their thoughts and think analytically about it? Can they think on the spot if I challenge their approach? Are they comfortable saying "I don't know"? This sort of things.
In my book, being a "good engineer" is much more about communication, collaboration, familiarity with git/sourcecontrol, clarity of commit messages, pertinent emails, being reliable, being resourceful, etc.
Good grasp of algo is a big plus, of course, but it's not something that all the best engineers excel at.