This is a good lesson in why LC style interviews are so popular. There are generally only one or two correct/optimal answers that an individual could code in 20 minutes. There is limited ambiguity as to the task to be solved for both the interviewer and the interviewee. There is easy calibration across multiple interviewers as a set of boolean progressions points - did they solve the problem? did they need hints? did they present an optimal/correct solution? The edge cases/traps are likewise known to the interviewers for quick calibration.
The alternatives I've see boil down to these trivia style interviews which come down to simply memorizing answers the interviewer deemed important/correct. The most rediculous cases include obscura such as "what would you do if [X debugging tool] stalled [Y application process?" or "what would you do if you saw a server with high IO time?"
There are many versions of correct answer to these, but odds are your interviewer has a specific one in mind. In a real discussion of these events there would likely be back and forth on root cause/severity/solution, but you simply can't have back and forth in an interview situation. The starting impression will always devolve towards "this person doesn't know what they are talking about".