By the way this is how Rob Pike says you should debug. He is not a fan of debuggers.

FWIW. I am a fan of debuggers. But reading and understanding the code, like the asker says he did, is best!

I always ask debug questions in when I interview candidates, because it's a skill way too many devs simply don't have. in that situation i'd tell them what you thought was the issue and why, then proceed to prove it through the debugger.

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.

I used debugger during the first few years of coding. Then I learned the idea of coding without using debugger. I tried it. It was unnatural at first. But I wanted to see if it is really good or not. Without realizing it, I have done with the last 5 years writing a lot of codes day and night without using debugger. I wrote C, ObjC, Go, Java, C#, JavaScript, PHP. I can write code as soon as I wake up all the way until the moment I need to sleep again. I can read code as natural as I read an English essay. Sure there are some very badly written codes that is hard to understand, as there are badly written English articles too. I fixed trivial bugs (such as edge cases or typo) by reading it, more difficult one by enabling debug logs (much more productive in long run), there are separate tools for memory leak inspection, a hanged process can be inspected by process dump log.

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 <.

Wow. OK. What makes you think this was the exact specific reason? Were there maybe other bugs you did not catch? Maybe there were less obvious things in the code that could have been fixed/changed? Is there any possibility of other factors?

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.

Seems like not a good place to work at, if they didn't even design a proper problem that needs debugger to be solved. And expected you to use debugger.