He solved it by inspection. It's the best way to fix a bug: it requires understanding the code (which you should anyway), and is fast and easy. Using a debugger requires a lot of overhead: recompiling with debugging symbols enabled, starting up the debugger, isolating where in the code the error happens, stepping through the code line-by-line around that point, etc. It's a pain in the ass. If you can skip all that and just look at the code and see "oh, this is obviously causing the problem", fix it and test it, that's a far superior method.
Of course, solving bugs by inspection isn't always viable. At some point, it takes less time to go through the overhead of using the debugger, because it lets you step line-by-line and lets you inspect memory etc., then just staring at the code. If you're highly competent, you know when each approach is the best choice.
It sounds like this stupid company came up with an idiotic example case of a trivial bug to use as an interview exercise, and then rules out people who don't go through the unnecessary step of using the debugger when the bug is obvious to a competent coder just by looking at it.
If they're testing for the ability to use a debugger, they should just come out and say so: "you can probably spot the bug here just by looking at the code, but we're looking for someone who can use a debugger for solving much harder bugs, so please take that approach here and show us how you'd go about finding a bug using a debugger."
I read the code just like reading an English article and then I saw the bug and fixed it right on spot. Then ran successfully. No print statements were added. Existing codes were not changed at all.
To give an example, one of the bug is for (int i = 0; i <= len; i++)
It is obvious so I just change <= to <.