But then they didn't use the first minute to ask clarifying questions, such as what the file format of those files are. I agree that asking clarifying questions is necessary, I don't think the other steps are necessary.
Yes, but that's what I want to see in the first 5 minutes, that you understand the question and have asked clarifying Questions. Step 2 is explaining that you have an approach to the problem before you launch off. A lot of people come up with crazy solutions that won't work like trees based on primes instead of HashMaps. This next 5 minutes helps me understand that they're able to communicate their design and discuss it, and that they've got a plan. Also verifies they really understood the problem. This is where I course correct if needed.
Really, that 2nd 5 minutes is for YOU, the candidate. You can test out if I'm even going to accept your solution, also by talking it through I'm going to give you partial credit even if you have issues coding it as at least you could code it out.
Partial credit isn't a thing to sneeze at, stuff happens in an interview. Network issues, software issues. I've had interviews where many things happened and the interview went sideways or just had to end over the 1k or so interviews I've given.
I had an interview where I was the candidate recently where the system wouldn't log correctly, or log what failed, and wouldn't debug correctly. My code was correct except a flipped check, but the interviewer wanted it to run all the test cases. It took 15 minutes to debug the web ui to even see what test case was failing.
If I was the interviewer in that case, the partial credit for explaining the answer and the 98% code would have been fine and I would have called it the instant the candidate found an issue with the tool, and moved onto other questions.
I've also had interviews where the interviewer admitted they were trying out a new question and couldn't guide me or grade me well, that first 10 minutes counters that. Sure that's not really professional, however it happens.