LeetCode Run Code Verdicts: A Diagnostic Debugging Guide

The Problem: A Verdict Without a Clear Path

You click Run Code or Submit on LeetCode, and instead of Accepted you see Wrong Answer, Time Limit Exceeded, Runtime Error, or Compile Error. The useful takeaway is that these verdicts are not interchangeable: each one isolates a different layer of your solution, and checking them in the right order prevents hours of blind editing.

Verdict-to-Cause Mapping

Before changing code, classify the failure. The table below maps each verdict to its most common causes and the fastest first diagnostic.

Verdict	Likely Causes	First Diagnostic
Wrong Answer (WA)	Off-by-one loop bounds, missing edge cases, wrong variable updated, incorrect return type	Hand-trace the smallest non-trivial input and compare variable states
Time Limit Exceeded (TLE)	Quadratic loops where linear or linearithmic suffices, repeated recomputation, no early exit	Estimate time complexity against the stated constraints
Runtime Error (RE)	Null or None dereference, array index out of bounds, stack overflow from deep recursion	Audit boundary accesses and recursion base cases
Compile Error (CE)	Syntax mistakes, missing imports or headers, public class name mismatch	Read the compiler message; verify class and method signatures

Ordered Checks: Do These Before Editing

1. Confirm input parsing. Re-read the specification. Verify you read the exact data structure (array vs. linked list), indexing convention (0-based vs. 1-based), and delimiter format. LeetCode test harnesses often serialize linked lists as arrays, so your reconstruction logic must match exactly.
2. Trace one tiny case. Pick the smallest input that is not trivial. Write down each variable after every loop iteration or recursive call. A single wrong assignment is easier to spot in a three-line trace than in a full submission.
3. Audit loop bounds and recursion depth. Look for < where <= is needed, i + 1 where i belongs, and missing base cases in recursive functions. Fencepost errors—where a loop runs one time too few or too many—are a frequent source of WA.
4. Estimate complexity. If the constraint is n <= 10^5, an O(n^2) approach will almost certainly TLE. Also check space complexity against the memory limit; storing an unnecessary O(n^2) table can cause a memory-related failure even if time is acceptable.
5. Test edge cases locally. Run empty input, a single element, maximum constraint values, and duplicate values. Sample tests rarely cover these. If the LeetCode editor allows custom test cases, use them before submitting.

Fixes Tied to Findings

Wrong Answer

Add the missing conditional or correct the boundary logic. If the problem asks for a linked list and you return an array, fix the return type. If a carry or remainder is dropped, append the final node. Also check for assignment (=) where comparison (==) was intended.

Time Limit Exceeded

Replace nested loops with a hash map, sorting plus two pointers, or a prefix-sum array. Cache repeated subproblem results with memoization. Add pruning to recursive searches. In Python, prefer built-in optimized methods such as bisect over manual linear scans when the data is sorted.

Runtime Error

Insert bounds checks before every array or pointer access. Use safe iterators. Convert deep recursion to an explicit stack. In Python, deep recursive solutions can hit the default recursion limit; raising it with sys.setrecursionlimit() is a language-specific workaround, but an iterative rewrite is safer for production-grade judges.

Compile Error

Fix spelling. In Java, ensure the public class name matches the expected class name for the problem. In C++, include required headers such as <vector> or <unordered_map>. In Python, import necessary modules like collections or typing.

Concrete Example: A Missing Final Carry

On a problem like Add Two Numbers, where digits are stored in reverse order in linked lists, a recognizable WA pattern is dropping the final carry. The snippet below runs to completion but returns a list that is one node short when the most significant digits sum to 10 or more.

def add_two_numbers(l1, l2):
    dummy = ListNode(0)
    curr = dummy
    carry = 0
    while l1 or l2:
        x = l1.val if l1 else 0
        y = l2.val if l2 else 0
        total = x + y + carry
        carry = total // 10
        curr.next = ListNode(total % 10)
        curr = curr.next
        if l1:
            l1 = l1.next
        if l2:
            l2 = l2.next
    # Bug: missing append for carry > 0
    return dummy.next

This is a pure logic error: the loop terminates before handling the leftover carry. The fix is to append a final node when carry > 0 after the loop. Run this in the LeetCode code editor with the provided sample tests; the expected check is that all visible cases pass, then Submit returns Accepted. The risk is trusting only the samples, which may not include a case that triggers the final carry.

When to Escalate

Stop isolated debugging and seek external input when any of the following apply:

• You have completed two full check cycles—parsing, tracing, bounds, complexity, and edge cases—and the verdict remains WA, TLE, or RE.
• The behavior seems inconsistent with your language version. For example, collection performance or default memory limits can differ between Java 8 and newer versions on the judge.
• You suspect a platform anomaly, such as a timeout that seems far shorter than the stated limit or a memory figure that does not match your allocation.

Before escalating, search the Discuss forum using the problem slug plus the verdict (for example, two-sum wrong-answer). If others report the same issue on your language, the cause may be environmental. If not, file a support ticket with the exact submission ID, your code, the verdict, and the timestamp.

Limitations and How to Verify

Sample tests are insufficient. They are chosen to illustrate the format, not to break boundary logic. A solution that passes all visible samples can still fail hidden tests.

Do not optimize before you have a correct solution. Micro-optimizations often obscure the real logic bug and make the code harder to trace.

Practical verification: After applying a fix and receiving Accepted, deliberately reintroduce the original bug class—remove the final carry node, replace a hash map with a nested loop, or delete a bounds check—and resubmit. If the verdict flips back to the expected WA, TLE, or RE, your diagnostic path is confirmed. Restore the fix and submit again. Repeating this with each verdict type ensures every branch of the guide works for your workflow.