How do you debug a hidden test that only reports “Wrong Answer”?

Before asking someone else to inspect the solution, reduce the problem to a minimal failing pattern you can reproduce locally. Re-read the constraints, check special cases, and have another person or a code-analysis tool review the reduced example as a second opinion—not as a substitute for understanding the specification.

Logging can help, but it should be deliberate. Record the input and a few important intermediate values or invariants, then inspect where the result first becomes impossible. In real debugging, you often only get vague logs, so learning to reason backward from the expected constraints and the code’s assumptions is part of the process.

Use a debugger or a local harness to run targeted cases, rather than adding prints everywhere. If possible, compare your result with a slow, obviously correct reference implementation on lots of randomly generated small inputs. The first case where the two outputs differ usually reveals the bug much faster than staring at the main examples.

Start by reviewing the specification line by line and make a checklist of assumptions. Hidden failures often come from zero, negative, empty, duplicate, maximum-size, or already-sorted inputs. Also verify integer limits, exact output formatting, indexing, and whether the input can contain values you silently filtered out. Build small tests specifically designed to challenge each assumption.