How do you debug a hard bug? At which step do you use AI?

The interviewer wants to hear a process, not a tool. A good answer has clear steps and shows that you verify before you believe.

A process you can describe:

1. Reproduce the bug in the smallest way possible: one command, one script, one test. If you can't reproduce it yet, you shouldn't fix it yet, because you have no way to know you are done.
2. Write down the actual and the expected result. "The total is wrong" is not enough; "the total comes out as 67,000 VND when it should be 35,000" is.
3. Follow the data from where it enters to where it goes wrong: where it is created, which functions it passes through, who shares it. Read the stack trace if there is one, and set a breakpoint instead of sprinkling console.log.
4. Rule things out with evidence: which parts already have green tests, which parts you checked by hand.
5. Fix it, then rerun the reproduction and the whole test suite. Find every place that calls the function you just changed.

About AI, say clearly where you use it and where you don't. AI helps a lot at step 3: reading unfamiliar code, suggesting suspicious spots, explaining an error message. But AI sees only what you give it, so you give it the reproduction, the actual result, the expected result, the files the data passes through and what you have already ruled out. You also ask it to point to the file and line before it proposes a fix, so you can check the cause yourself.

Bonus points: tell about one specific bug, for example one that only appeared when two users acted at the same time, and say what you did so that it can't come back (a test that reproduces exactly that bug).