Maybe.. the hypothesis is whether these algorithm problem solving whiteboard interviews test and predict job performance. Plenty of people have argued that they don't. The anecdotal evidence is that they don't.. because the people who fail these interviews are still gainfully employed elsewhere in tech jobs. Google should have some evidence that they do, or else it's a waste of time (although not necessarily for all jobs). I don't disagree with these whiteboard problem solving interviews because they test basically whether you can think like a computer scientist which may be the primary skill they want. There must be a correlation between thinks like a computer scientist and can program. But I think there are plenty of folks who can program even though they don't think like a computer scientist.

I don't think whiteboard interviews do show one can "think like a computer scientist." What they might show is that one can recognize that a toy problem can be solved by some algorithm that was research paper-worthy some years ago. Do you think the authors of those papers wrote them, or came up with the fundamental algorithms in 45 minutes?

Regardless, what companies should be looking for is "can this person do the job." "Can this person think like a computer scientist" is a poor proxy for most jobs. It would be more appropriate to want to find out "can this person think like a software engineer," but, instead, we get "can this person regurgitate problem 257 from LeetCode."

I would argue that the negative signal is probably pretty high from this style of interview. That is, you're unlikely to have someone who's capable of writing down a nontrivial piece of code who can't actually write any code. But, the positive signal, the "can this person do the job" signal, is very very low.

I'll give you an example of a question I've been asked multiple times in a 45-60 minute interview: implement a text-based connect 4 game.

This is a totally valid programming task. That's why it's an assignment in some beginning CS classes. Without such tight time pressure and scrutiny as an interview implies, I would expect any working software engineer to be able to come up with working code in a fairly short period of time. Under interview conditions, where one has to not only come up with working code, but chatter constantly while doing so, it becomes a lot harder, simply because one has to multitask a little. Writing code and talking about it simultaneously is hard, and it's not a skill that's necessary to the vast majority of software engineer positions. Writing down tricky algorithms on a whiteboard without notes is not a skill that's necessary to any occupation as far as I can tell.