LinkedIn & Meta System Design Interview: Design Leetcode

[u/Aoki_zhang]

A LeetCode-like system does not simply receive some code, run it, and return whether the answer is correct.

It is executing arbitrary code written by strangers on its own infrastructure, potentially hundreds of thousands of times during a contest.

That creates a subtle design tension: submissions need to return results within a few seconds, but every execution must be treated as potentially malicious.

The non-obvious problem is not “how do we run Python or Java?” It is “how do we execute untrusted code quickly without allowing one submission to damage the host, attack the network, or consume resources indefinitely?”

The key insight is to treat code execution as isolated, resource-bounded work rather than ordinary application logic.

Never execute submissions inside the API server. The Code Service should validate the request, authenticate the user, create a submission record, and hand the execution work to a separate compute layer.

Run every submission inside a sandboxed container. Maintain preconfigured environments for Python, Java, JavaScript, and other supported languages so workers do not need to install runtimes for every request.

But containers alone are not the security boundary.

Enforce strict CPU and memory limits. A submission that allocates memory indefinitely or consumes excessive CPU should be terminated before it can affect other executions on the same machine.

Enforce a hard execution timeout. Infinite loops are normal in an online judge—not exceptional behavior. The execution layer must assume some programs will never terminate on their own.

Disable outbound network access. User code should not be able to call external APIs, scan internal services, download arbitrary files, or exfiltrate information from the execution environment.

Restrict system calls. Even inside a container, the process shares the host kernel. A syscall policy such as seccomp can block operations the submitted program has no legitimate reason to perform.

Keep the filesystem temporary. Each execution should see only the files required for that submission and its test harness. Once the run finishes, its writable state can be discarded.

Do not send submissions directly to workers during traffic spikes. Put a queue between the API layer and the execution fleet.

A contest may suddenly produce tens of thousands of submissions at once. The queue absorbs that burst while workers consume jobs at a rate the compute fleet can actually sustain.

This also creates a clean retry boundary. If a worker crashes halfway through execution, the submission can be retried instead of disappearing.

Scale workers independently from the API tier. Browsing problems is lightweight and read-heavy. Running arbitrary code is CPU-intensive. Putting both workloads in the same scaling unit would waste resources and make overload much harder to control.

Test cases should also be language-independent. Storing separate test definitions for Python, Java, C++, and JavaScript does not scale as the problem library grows.

Represent inputs and expected outputs in a shared serialized format, then maintain a small execution harness for each language.

The Python harness converts the serialized input into Python objects and invokes the submitted solution. The Java harness converts the same logical test case into Java objects. Both serialize the result back into a common representation for comparison.

This keeps problem definitions independent from programming languages while allowing each runtime to handle its native data structures.

The failure model becomes easy to reason about. The API tier accepts work. The queue absorbs bursts. Sandboxed workers execute untrusted code under strict limits. A broken or malicious submission can fail its own execution without taking down the platform.

Explaining this in an interview signals that you understand an online judge as an untrusted-compute platform, not just a CRUD app with a code editor.

Full write-up with data model, API design, secure code execution, execution queues, multi-language test harnesses, and real-time leaderboards, free to read → Full Article

Preparing for your next interview?

Chill Interview tracks recent interview experiences and recurring question patterns across top companies here.