LeetCode Run Code vs Submit: When to Debug and When to Finalize

When you have a working draft of a LeetCode solution, the next click is not obvious: Run Code gives you instant feedback on inputs you choose, while Submit sends your code to the hidden judge and records the outcome. The practical rule is to use Run Code for every iteration and reserve Submit for the moment you believe the solution is complete. Run Code is a debugging tool; Submit is an evaluation event that affects your submission history.

Constraints That Shape the Choice

Several problem-specific and account-level constraints determine which button makes sense at a given moment:

• Time and memory limits. Each problem enforces its own limits. Run Code reports runtime and memory for your custom input, but only Submit reveals whether your solution stays within the official limits across the full test set.
• Language availability. Both features support the languages listed for the problem. You can switch languages before either action, but the code you run is the code you submit.
• Custom test cases. Run Code accepts a custom input box; Submit does not. If you need to check a tricky edge case, you must do it before submitting.
• Feedback latency and type. Run Code returns output immediately and is unofficial. Submit may involve a short queue delay, but it provides the official judgment that determines acceptance.
• Submission quota. Submit consumes an attempt and is recorded. Excessive submissions can affect your submission count and may trigger temporary rate limits.

Run Code vs Submit: Feature Comparison

Feature	Run Code	Submit
Feedback	Immediate output, runtime, memory	Official judge result (Accepted / Wrong Answer / etc.)
Custom input	Yes, via the custom test case box	No, uses the hidden test set
Score impact	None	Affects submission count and rating
Language change	Allowed before each run	Allowed before submit

Trade-offs in Practice

Run Code executes only the input you provide. That makes it fast and repeatable, but it cannot reveal failures on inputs you did not think to test. A solution that returns the correct answer for your custom case may still fail on hidden edge cases—empty arrays, maximum-size inputs, duplicate values, or boundary conditions described in the problem statement.

Submit runs the full hidden test suite and returns a definitive verdict. The cost is that it consumes a submission attempt and may take longer to return a result. Because the verdict is official, it is the only signal that tells you whether the solution is accepted by the judge.

Another practical difference is latency. Run Code returns as soon as the sandbox finishes your single input. Submit may sit in a queue, especially during peak hours, before the judge returns a verdict. That delay is usually short, but it means Submit is poorly suited to rapid trial-and-error.

In short, Run Code optimizes for iteration speed; Submit optimizes for correctness certainty. Using Submit as a debugging tool wastes attempts and clutters your record.

Concrete Example: Validating Two Sum

Consider LeetCode problem 1, Two Sum. A Python solution might look like this:

def twoSum(nums, target):
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i
    return []

Before submitting, use the custom test case box in the problem editor and enter the input exactly as the problem statement formats it:

[2,7,11,15],9

Click Run Code. If the logic is correct, the output pane shows [0,1] along with the runtime and memory used for that single execution. This confirms the function handles the basic case. You can then change the input to test edge cases—for example, duplicate values or a target that requires the last two elements—without touching your submission record.

Keep the language selector unchanged between Run Code and Submit. Switching languages after a successful run means the submitted code has not been tested in that language.

When the output is correct for every custom case you consider relevant, click Submit. Wait for the judge to finish. Open the submission details page and confirm the status reads Accepted. Compare the runtime and memory reported by Submit with the numbers you saw during Run Code. Consistency between the two indicates the solution behaves the same way under the official judge as it did locally.

Limitations and How to Check the Result

Run Code is not a correctness oracle. Passing a custom input does not guarantee acceptance. Always read the problem constraints and construct test cases that cover the boundaries they describe.

Custom input must match the exact format the problem expects. A malformed string—missing brackets, incorrect separators, or wrong argument order—can produce a runtime error that reflects the input format, not your algorithm.

If you are unsure whether an edge case matters, encode it as a custom test case before submitting. For example, if the problem states that exactly one valid answer exists, test an input where the complement appears later in the array. This habit reduces the number of Submit attempts spent on avoidable mistakes.

Submit is a state-changing operation. Once recorded, a submission generally cannot be removed from your history. Treat it as a final validation step rather than an exploratory one. If the verdict is Wrong Answer or Time Limit Exceeded, return to Run Code, adjust the solution, and submit again only after local testing passes.

To verify the final state, navigate to the submission details page for the problem. Check that the status is Accepted and note the runtime and memory percentiles if displayed. If the numbers differ significantly from your Run Code measurements, investigate whether the hidden tests exercise a larger input size or a different code path.