What the verdict is telling you
Sample tests are written to explain the problem, so they are usually small and friendly. Hidden test cases are written to break solutions, which means they live at the boundaries the samples skip. If the platform shows a verdict for each hidden test, read it before changing anything, because each one points somewhere different.
| Verdict | Usual causes | Where to look |
|---|
| Wrong answer | A missed edge case, overflow, wrong output format | The constraint list below |
| Time limit exceeded | Complexity too high for the maximum n, slow input reading | Nested loops, repeated work |
| Runtime error | Index out of range, empty input, recursion too deep | Boundaries and recursion |
Some platforms show only a count of passed tests. You can still learn from where in the list failures start, because hidden tests often grow in size, though that is not guaranteed.
Build the edge list from the constraints
The constraints block is a description of the hidden test cases, written by the people who wrote them. Hidden test cases are usually built around the extremes those lines allow, so take the block line by line.
| Constraint line | Edge cases it implies |
|---|
1 ≤ n ≤ 10^5 | n = 1, and n = 100,000 |
-10^9 ≤ a[i] ≤ 10^9 | All negative, all zero, the extreme values |
| No statement that values are distinct | Every value equal, many duplicates |
| A string of lowercase letters | Length one, one repeated letter |
| Several test cases per input | State left over from the previous case |
Two of these need arithmetic, not instinct. For overflow, multiply the maximums: 100,000 values of up to 1,000,000,000 sum to as much as 10^14. A signed 32-bit integer stops at 2,147,483,647, roughly 2.1 × 10^9, so a Java or C++ int total is wrong long before the limit. Python integers do not overflow, which is why the same bug can pass in one language and fail in another.
For timeouts, count the work at the maximum size. A pair of nested loops over 100,000 elements is 10^10 steps, which is far too slow for a typical time limit. If your solution is O(n²) and n reaches 10^5, the edge case is simply "the biggest allowed input".
Compare against a brute force
When the list finds nothing, generate edge cases instead of inventing them. Write the simplest correct solution you can, ignore its speed, and run both on thousands of small random inputs.
Here the problem is the maximum sum of a contiguous subarray. The fast version passed the samples, all of which had a positive answer.
Within a few trials it prints an input such as [-3], where the fast version returns 0 and the brute force returns −3. Trace it by hand and the bug explains itself: best started at 0, which is larger than any all-negative answer. Starting best at negative infinity, or at the first element, fixes it. The full problem is covered in maximum sum of a contiguous subarray.
Small inputs and a small value range are deliberate. They make duplicates, zeros and negatives common, and they keep the failing case short enough to trace in your head.
Failures the samples rarely exercise
Some hidden test failures are not about the algorithm at all. When the input holds several test cases, a global list or counter that is not reset between them gives correct answers for the first case and wrong ones after. Output format matters too: a missing newline, an extra space or the wrong number of decimal places can turn a right answer into a wrong one on strict checkers.
Language behaviour catches people as well. Integer division of a negative number floors in Python but truncates towards zero in Java and C++, so −7 divided by 2 gives −4 in one and −3 in the others. Deep recursion on a maximum-size input can exceed CPython's default recursion limit of 1,000 frames and fail as a runtime error.
The weak response is to change something plausible and resubmit, again and again. It burns time, and in an online assessment it may burn attempts if the platform limits them. Worse, a tweak that happens to pass teaches you nothing about whether the solution is right.
The strong response treats hidden test cases as something you can reconstruct. The constraints tell you where they are, the verdict tells you what kind of failure it is, and a brute-force comparison hands you a concrete input. Once you can name that input and explain why your code fails on it, the fix is usually one line.
The constraints describe the hidden tests. Turn each line into an input, and when that is not enough, let a brute force find the input for you.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).