Taro Logo

How to debug in interviews?

Profile picture
Junior Engineer at Taro Community14 days ago

My bottle neck is debugging when you can't run code. When practicing I am able to run code and add prints and trace the code. But often in a real interview you have to debug through pure reasoning which is hard

My performance is getting hit because in DSA I often get an answer 95% correct but the interviewer tells me I have a bug and I find it really really hard to trace the bug especially in recursion problems



  • 2
    Profile picture
    Helpful Tarodactyl
    Taro Community
    14 days ago

    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?

  • 3
    Profile picture
    Software Engineer
    14 days ago

    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.

  • 2
    Profile picture
    Staff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDE
    14 days ago

    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.