Hot take: I like leetcode-style interviews and I've spent a lot of time in them on both sides of the fence (tens of hours as a candidate, hundreds as an interviewer).
> But yet, these interviews quiz me on things that I can easily Google that I may not know off the top of my head. It’s absurd.
I don't work at Google so I'm lucky to have freedom in the way I interview engineers and usually I try to squeeze out the quiz aspect as much as possible.
If a candidate doesn't know the algorithm for a given problem and can't quickly come up with one, I usually proceed to give a detailed explanation for it. In the end the task is reduced to "write between 6 and 10 lines of code that do X in your favorite language" and yet a majority (80-90%) of inbound candidates for software engineering fail at it (for non-inbound sources a picture can be very different of course).
Contrary to a common view, I believe that this approach actually imitates my daily interactions with a developer quite well and the correlation between interview performance and job performance is very strong in my experience.
And interestingly I've seen many people who shine in oral interviews (tell me about your experience) and then fail to produce any code at all, both during the interview and at work. So even if I wanted a good alternative approach to hiring of engineers I haven't seen it so far.