Did you put a bunch of print statements all over the place or really, any at all? Did you comment out some lines of code and repeatedly run the sample? Did you make changes of any kind and repeatedly run the sample to understand what was happening?
If you answered Yes to any of the above, then you went about it the hard way. You could have introduced additional errors into the code in a non-trivial case. You could have left debugging/print statements in places they shouldn't be. There are probably other good reasons why you shouldn't do it this way.
To give an example, one of the bug is for (int i = 0; i <= len; i++)
It is obvious so I just change <= to <.
I think the answer as to why this happened is in you. You just have to ask the right questions of yourself and answer honestly. Do some honest root cause analysis.
And then at the end of the day, there are those times where you do incredibly well and all seems as it should be and you don't get an offer. If there is absolutely nothing to learn from the experience, well then shrug and move on.
FWIW. I am a fan of debuggers. But reading and understanding the code, like the asker says he did, is best!
Yes it's tedious, and in real life you fix it and move on, but not all bugs are that simple, and it's an interview so the aim of the game is to demonstrate your ability as a well-rounded developer.
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."
This sounds like when high school students get marked down/fail for "not showing their working" in maths classes.
It doesn't matter that they can "do it in their head" the teacher is testing to see if they actually understand how to solve the problem, not if they can get the right answer.
If your test requires the test-taker to show every minute, trivial step, then your test is a failure.
You - No.
Interviewer - I guess you don't know how to use the debugger and it is required for the job. Have a nice day.