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.