Design LeetCode
Problem Statement
Design the user-facing product for an online judge. Users browse a catalog of a few thousand coding problems, open one, write a solution in an editor that never loses their work, press Run to check it against the visible sample tests, press Submit to run the full hidden suite and record a verdict in their history, and during a contest watch a leaderboard that reranks while thousands of people are still submitting.
The thesis of the whole design, and the sentence to say early: a user action whose result arrives later needs a durable handle, and the client's job is to hold that handle and keep asking.
This walkthrough follows the Product Architecture framework. That framework scopes you to exactly three layers:
- Client UI: screens, loading and empty and error states, optimistic updates
- Client data layer: query cache, normalized entity store, draft persistence, in-flight job tracking
- API and data model: schema, endpoint contracts, pagination, permissions
Everything below the API contract is one box. For this problem that box is: submissions run in isolated sandboxes behind a job queue, so the submit endpoint returns a job id immediately and results arrive asynchronously. That single sentence is the complete answer at this layer. Sandbox isolation, runner autoscaling, queue partitioning, and language toolchain images belong to the System Design round.
The most common way this question is failed is by spending fifteen minutes designing the execution sandbox. If you catch yourself drawing gVisor, cgroups, or a worker pool unprompted, stop and come back up a layer. If the interviewer asks for it directly, give the sixty-second version at the end of Phase 5 and then steer back. The interesting problem here is that the result of a user action arrives seconds later over a connection that may not survive, and the client has to stay correct through that.
Disclaimer: This is a sample solution to help you get started. Think through the question yourself before reading it. Product Architecture questions are open-ended and several designs are defensible as long as the contracts are complete.
Common Aliases
Interviewers phrase this problem several ways. The core design is the same, but each framing shifts where they want you to spend time.
| Phrasing | What it emphasizes |
|---|---|
| "Design an online judge" | Verdict correctness, hidden test privacy, submission history |
| "Design a coding practice platform like HackerRank" | Catalog browsing at scale, solved-status tracking, editor experience |
| "Design a code execution product" | The async job lifecycle, run vs submit, streaming results back |
| "Design a competitive programming contest site" | Live leaderboards, ranked pagination, the freeze window |
If the interviewer opens with the contest framing, front-load Phase 3 with the leaderboard endpoints. If they open with "coding practice", front-load the problem list and the editor draft story. Ask which one they care about before you start listing endpoints.
Check which round you are in before you scope anything. This is the one prompt in the track with no System Design counterpart, and "design an online judge" is more often a general backend question, where the sandbox and the queue this lesson declares out of scope are the entire point. The client framing is live at developer-tools and code-execution companies, and in Product Architecture rounds where the interviewer says "from the client's perspective." If the opening sounds like throughput, isolation, or how you stop untrusted code from eating the host, ask which round you are in before you declare the sandbox out of scope. Declaring it out of scope in a round that wanted it is the fastest way to fail this question.
Level Calibration
The same design is graded differently depending on the level you are interviewing at. Here is where the bar sits.
| Level | What a complete answer looks like |
|---|---|
| Mid-level | The core endpoints, the 202 plus a follow-up channel, and submission history. Breadth over depth, roughly 80/20. Get all of that right and stop. |
| Senior | All of the above, plus the run-versus-submit justification, drafts with revisions, and one deep dive carried to a conclusion. Roughly 60/40. |
| Staff+ | All of the above, plus the redaction posture as an API property and a defended position on the contest freeze with its cost named. Roughly 40/60. |
Everything below is written at the senior-to-staff bar. A mid-level reader should treat the deep dives as reference material for when the interviewer pulls on something, not as a script to deliver.