Your solution passes the examples, you submit, and it fails test 47 of 52. The usual response is a small change and another submit, then another. Sometimes it goes green, and you never find out why it failed. That is the part that would have helped in an interview.
Here is a method that works on LeetCode, HackerRank or any judge.
Read the failing case first
Look at the input that failed, what you returned, and what was expected. Before you touch the code, say in one sentence how your output differs: off by one, the wrong element, too many results, or a crash. That sentence narrows the search more than any change you could make blind.
If the verdict is "time limit exceeded" rather than a wrong answer, your logic may be right and your approach too slow. That is a different problem: count the loops before you look for a bug.
Shrink it
Failing inputs are often large. Copy the case into a custom test and cut it down until it is as small as it can be and still fail. A list of ten numbers that fails is far easier to reason about than a list of ten thousand.
If you cannot see the failing input, guess its shape from the problem's constraints and try the edges yourself.
Trace it by hand
With the small input, walk through your code on paper or in comments: the value of each variable after each step. Do it before you add any prints, and write down what you expect at each point. The bug is where reality and your expectation first disagree.
Then add prints to confirm. Most judges show your printed output when you run a custom test, so you can compare it with your trace line by line.
Check the edges
Most hidden failures come from the same short list:
- Empty or single-element input.
- Duplicates and negative numbers.
- The largest values in the constraints: overflow in Java or C++, or recursion that goes too deep.
- Off-by-one boundaries:
<against<=, and the first and last index. - State left over between calls, such as a class field or a global that is not reset.
Run each one as a custom test before you submit again.
Fix the cause, then explain it
Change one thing, the thing your trace pointed to. If the fix works, say why the old code failed in one sentence. If you cannot explain it, you got lucky, and the same bug will come back in a different problem.
This is also the moment to be careful with AI. Asking an assistant for a fixed solution teaches you nothing. Asking it to explain why your version fails on your small input, without giving you code, teaches you a lot.
The free Debugging Is the Skill book teaches this loop on sixteen planted bugs, and our Go and JavaScript DSA guides give you the problems to practise it on.