Architecture note: LeetCode online-judge submission sandbox

You run a solution locally, it returns the right answer, and LeetCode still returns Wrong Answer or Memory Limit Exceeded. The mismatch is usually not the algorithm. It is the sandbox: an isolated execution environment where the judge controls the input, enforces time and memory limits, and compares your program's output against expected results. Treat each submission as a small, bounded program, not a general-purpose script.

Requirements

• Input is supplied by the judge in a platform-specific serialized form, such as [1,null,2,3] for a binary tree. Your code receives deserialized objects through the problem's function signature; it does not read stdin for most LeetCode problems.
• Each problem sets its own time limit and memory limit. Exceeding time produces Time Limit Exceeded; exceeding memory produces Memory Limit Exceeded. Both are distinct from Wrong Answer.
• The judge compares actual output to expected output for visible and hidden test cases. Custom test cases let you supply input and observe actual output before submission.
• Network access, file-system writes outside the sandbox, process spawning, and unsafe reflection are generally restricted. Solutions should rely on in-memory algorithms and language standard libraries.

Smallest suitable design

Design the submission around a single entry point: the class and method the problem declares. Keep the algorithm in-memory, avoid global state that assumes a fresh process per test case, and use only the standard library for the selected language.

Example: maximum depth of a binary tree

For LeetCode problem 104, the judge deserializes input such as [3,9,20,null,null,15,7] into a TreeNode and calls your method. A minimal Python submission looks like this:

# Version assumption: Python 3; exact minor version is shown in the editor.
from typing import Optional

class TreeNode:
    def __init__(self, val: int = 0, left: Optional['TreeNode'] = None, right: Optional['TreeNode'] = None):
        self.val = val
        self.left = left
        self.right = right

class Solution:
    def maxDepth(self, root: Optional[TreeNode]) -> int:
        if root is None:
            return 0
        return 1 + max(self.maxDepth(root.left), self.maxDepth(root.right))

To verify locally before submitting, build a small adapter that deserializes the same list format, calls the method, and prints the result. Run it from a local terminal with no special permissions:

python3 leetcode_104_adapter.py

Expected check: for input [3,9,20,null,null,15,7], the adapter should print 3. Risk: your local deserializer may differ from the judge's, so a local pass does not guarantee an Accepted verdict.

Trust and data boundaries

Boundary	What crosses it	Implication
Code boundary	Your submission enters the sandbox; the judge supplies input and expected output.	Your code cannot influence how input is generated or how output is compared.
Data boundary	Custom test cases are visible to you; hidden judge cases are not.	Passing custom tests only reduces risk; it does not prove correctness on edge cases such as empty input or maximum constraints.
Network boundary	No outbound network or external file access is generally permitted.	Solutions must be self-contained; do not fetch dependencies or call external services.

Operational checks

1. Open the problem in the LeetCode editor and select the language you intend to use. Check the language selector for the compiler or runtime version; versions can change over time.
2. Paste the solution and use the Run or Custom Test panel with a handcrafted input. Compare actual output to expected output before clicking Submit.
3. Reproduce the solution locally using the same language version and problem constraints. Test edge cases: empty input, single-element input, maximum-size input, and values near integer limits.
4. After submission, review the result page for the verdict, execution time, memory usage, and the failing test case if any. Treat percentile rankings as informal, not production performance claims.

Failure modes

• Wrong Answer: output differs from expected. Common causes include off-by-one errors, incorrect handling of null, and mismatched input parsing between your local adapter and the judge.
• Time Limit Exceeded: algorithmic complexity is too high for the constraints, or constant factors are too large.
• Memory Limit Exceeded: recursion depth, large intermediate structures, or duplicated data exceed the memory budget.
• Runtime Error: null dereference, index out of range, division by zero, or uncaught exception in the sandbox.
• Compile Error: syntax or language-version mismatch; compiler flags differ by language.

Conditions that would change the design

• If you need repeatable local verification, replace ad-hoc pasting with a version-controlled adapter harness that mirrors the judge's input format.
• If the selected language runtime changes, retest the solution because standard-library behavior or available features may differ.
• If you move from interview practice to production engineering, do not port LeetCode runtime or memory percentages as performance evidence; they are relative to recent submissions and vary by language and test load.
• If you need to interact with external systems, the sandbox model is the wrong design; use a local environment or CI pipeline instead.

Limitations and verification

This note describes the public web judge, not LeetCode hiring systems or third-party clones. Exact supported languages, runtime versions, and limits change over time. Verify the current editor settings for each problem before relying on them. Avoid automated submission bots, scraping, or bypassing CAPTCHA and rate limits; these can violate terms and trigger account restrictions.

Practical check: submit a trivial solution, such as returning a constant, and confirm the editor accepts it and returns a verdict. Then replace it with your algorithm and compare behavior on the same custom input. No rollback is required because submitting code does not alter production state or your local environment.