How to debug in interviews?

Personal anecdote; I have helped people practice DSA, e.g. through mock interviews and pair programming sessions and I've noticed that a lot of people have a strong tendency to hit the run code button, quite often, just to see if the code they have written so far, works.

If you recognize yourself as someone that has the same habit, try refraining from compiling your code often, e.g. during practice problems. You will have to reason to yourself why your code does (or does not) work. This will help you form the habit to check your code for bugs and also get you in the habit of writing compile-able code without using any help, such as an IDE.

This should hopefully reduce the amount of bugs in your code and it should hopefully help you build the skill to check for bugs in your code.

Totally agree. A common method to make debugging easier is to manually perform a stack trace, which will enable you to identify which logic generates the incorrect result. But I also have trouble with producing stack trace when you have a lot of state, especially with recursion or more complex algos like union find or djikstra's. In addition to being easy to mess up, these stack traces are also time consuming to produce. So to add on to the conversation, what strategies do people use to create stack traces quickly and accurately?

Start with test cases. Null input, zero length input, input with no matches of the search but is non-empty, input with trivial match, input with duplicates, whatever. Eliminate as many cases as you can with preconditions. Any edges that still require using the main algorithm should be the first thing you consider/test. Maybe it’s a do-while instead of while, maybe it’s doing a single-element look ahead or behind, but often if you can identify how to handle the edge doesn’t ruin handling happy cases, so it is more generalized.

If you know what you’re testing, it can make tracing easier.

From there, when I am in testing mode, I put comments after each line with the values of all variables before and after the line executes. When it’s a loop, there’s different approaches but regardless it is keeping the loop control and whatever outcome you’re looking for. I also look to comment, in advance, what is expected before/after each “stanza”, ie after this loop I expect all but X to be processed and held in the result buffer. The final step will be Y to process the remainder of the input. Or “the map will have keys that are the unique Ws, the values will be their occurrence count”. When you’re debugging you can validate those conditions are holding.

If you have methods ideally they are simple, and you can “know” what the outcome of a call will be. Walk it through a couple of times, but ideally you can then just say “when X is called, Y is returned”.

I guess also practice? Like do it on paper, do it in a shared editor, whatever. Put a bug in and be sure that the approach you are using surfaces it.