Yeah. If I were asking a trickier question and I got an interesting new variant of the solutions I'm aware of, I'd absolutely run it if I had time to type it up and everything. Most solutions are either something I've seen before verbatim or obviously wrong, though.

The interview is a proxy for working with the person. In this case, it's a proxy for pair programming / code review. A good chunk of what the interviewer, ideally, looks for when asking a coding question is communication from the interviewee - can the interviewee communicate what they are doing and why? Can they explain the intent of the thing they've just written? Do they have a clear picture of it in their head, and can they communicate it? When the interviewer spots problems with it, what does the ensuing discussion look like? - how well does the interviewee collaborate in solving them? If the interviewer is wrong, does the interviewee push back? How? Can they understand you, and can they make themselves understood?

Can you work with this person? Can you collaborate to write code, or will it be a daily struggle?

Whether the code actually builds and runs after the hour is up does not help answer these questions; it is arguably the least interesting part of the whole process. The time limit is artificial; if all the other things align but you didn't happen to get it working in one hour, you'll likely have got it in two. If they don't align, you'd likely never have got it.

The problem is it won't run. It was written in google docs without IDE. Everyone who programmed in their lives knows this. You cannot write out a whole algorithm like that and not make any even trivial error.

This is like writing code in notepad and creating a PR without building or running it to test once. What is this testing? There is no real world scenario where you are expected to work like this and for a good reason.