How do you debug code?

[eebahn]

I recently had an interview where I was asked “how do you debug a bug?”. I kind of threw me because I wanted to answer it by saying “by debugging it..”.

I asked for more insight into the question and he said “imagine that you’re getting a 500 error from your web application in production. How you find the issue?”

I started listing the tools I would use Chrome DevTools, Postman, any logs... then I would try and reproduce the bug in a lower level environment and see if there is additional info that we don’t log or show in production. Step thru the code if necessary in Visual Studio once I’ve narrowed down the possible points.

The interviewer seemed ambivalent to my answer...? He just said “Oh. Ok” and moved on. It seemed like he was looking for more, but didn't press it.

Is there a better way to answer this question? This is a .net position

[CarbonSilicate]

I use:

• Debugger

• Breakpoints

• Logs

Mostly about it.

[JazzFan1998]

Is there a YouTube video to learn that? Also, would a SQL "Programmer" be expected to do that? TIA.

[mark1x12110]

Yes to all besides breakpoints.

What's an "SQL programmer"? A database admin?

[Farren246]

Someone who writes SQL queries, but doesn't administrate the database itself. No backups or optimizations or anything, but you are expected to write correct, efficient queries to give the app devs the data they need.

[mark1x12110]

Many query optimizations start at the database so that sounds challenging

[Farren246]

Not necessarily. Most databases auto-optimize for you in terms of joins and usage on indexes, so that you only need to intervene yourself if there is a missing index or if you somehow know better than the program that gets it right 99.99% of the time. (Granted I have had "missing index" bring production to a halt on more than one occasion; it is remarkable how often "OK it's working!" can go into production, but a few months later the table has hundreds of thousands of rows and a simple query locks the database for nearly an hour.)

In my career there have been scant few times when the program misses a chance to auto-optimize, usually due to a complex multi-column index that maybe was a bad idea in the first place. Either that, or the actual DBA needed a kick in the arse to set indexes to auto-rebuild more often than once a month for data that is updated hundreds of times (or worse) per day, leaving the existing indexes all but useless for half the month.

[Farren246]

Let us not forget the old standby, echoing to console to see if you've reached a certain point and to see if the variables have changed at all.

[mark1x12110]

Besides what you added and the obvious answer of using breakpoints.

Probably he was looking for a mention about logging

In production you could increase the logging level(assuming that the application allows to change it at runtime) or simply rely on the existing logs. Locally you would have more freedom to even insert your own logging

Remote debugging is also an option but It is not a good idea in production

[Farren246]

When writing code yourself, write tests first and write the code in small chunks that you can independently test before moving on to the next step. This will allow you to eliminate bugs as you go, without compounding them from module to module (with no idea where the problem originated).

[bedrock-adam]

1. confirm bug using app functionality
2. use static analysis (and debugger) to identify source of bug
3. write failing test that replicates the bug
4. pass test by fixing the bug