These types of interviews are uncommon but when they do happen, they are usually a pain in the ass.
Since they don't test you on something you can practice religiously for, it's hard to prepare with confidence. And that's why communication and debugging skills are even more important than usual.
Understanding functionality vs refactoring
The interviewer will usually give you a feature you need to implement alongside starter code. Obviously you should understand what it's asking for but also consider what they might ask in the future. For example, question 1: Parse a json file. While many of you can probably do this, simply writing the code "linearly" like its leetcode is not the best idea. Chances are, they will build on top of this and ask to deconstruct the json object and use the data in some way. Or even add more data to the existing json file programmatically. Since you don't know what they might ask (or you do), think long term and write code in a logical and extendible way. Instead of having 3 major operations in a single function, break it down into smaller functions with single responsibility.
Debugging
I bet most students don't do this in school and use print statements most of the time. And honestly, it's ok to use print statements when you're stuck. Looks weird, but it shows you minimally know where and what to look for. Depending on the interviewer or IDE they make you use, standard debugging (adding breakpoints, etc) can be tricky. However, the main underlying skill is being able to read and logically follow the data flow. This means having a mental map of what each variable is and what it might be at certain stages is crucial.
Comments
If you don't comment naturally, you need to practice doing it more. Commenting itself is a skill but it can get too much or too little. Commenting on `tempVar = varA + varB` is absolutely pointless. But commenting on a 10 line function that does something complex is necessary. A general rule I follow is: "is anyone really going to read this next 5-10 lines of code?" — "nah, it's too much work" — slap a comment to summarize it. Now in actual workplace, this is not always true and different teams have different standards/style. But for the sake of interview, just comment every couple of lines — outlining the MAJOR ideas/operations.
"But commenting takes so much time! I'm already explaining as I write" — You should not be commenting so much that it takes longer than just writing the code. You want to comment to keep a mental map of what's happening and also allows the interviewer to follow along and go back if he needs.
Conclusion
Overall, these types of interviews are hard to prepare for. But just like the leetcode-style interviews, have a mental framework. Write down a set of steps you would follow and constantly practice that. During the interview, you will use majority of your mental energy into debugging and communicating effectively.