Hacker News Reader

Comment by partisan | Hacker News Reader

Not really anywhere near enough information to answer the question as it is stated, but in order to provide you with an answer, it could come down to how you identified and/or fixed the bug.

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.

View on HN

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.

Reply on news.ycombinator.com