Design LeetCode
Design a coding competition/contest platform similar to LeetCode, including features like submissions, leaderboards, and contest management.
Asked at:
Meta
Whatnot
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to browse contests and problems, view problem statements, constraints, and sample tests.
Users should be able to write code in multiple languages and submit solutions.
Users should be able to receive fast feedback on submissions (compile/run results, verdicts, and score).
Users should be able to view a live leaderboard for a contest, including their current rank and a window of nearby ranks.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
Tips: Use per-submission sandboxes (containers or micro-VMs) with a read-only filesystem, no outbound network, seccomp/AppArmor profiles, and explicit CPU/memory/IO limits. Enforce wall-clock timeouts per test and per submission. Pre-warm pools of language runtimes to reduce cold starts, but still treat each execution as ephemeral. Ensure the judge process runs out-of-plane from the API tier with separate blast radius, and log resource usage for auditing and tuning. Favor determinism by pinning compiler/runtime versions and images.
Tips: Maintain a per-contest materialized leaderboard in Redis sorted sets. Encode ranking logic into the score (e.g., primary score plus secondary tie-breakers like earliest solve time via composite scoring or lexicographic ordering) and update atomically at verdict time. Fetch top N with ZREVRANGE and 'around me' with ZRANK then a range around the rank. Cache pages and consider a short polling interval or SSE; full WebSockets are often overkill. Decide on consistency (eventual is fine) and handle late/out-of-order updates with idempotent, monotonic score updates using submissionId and last-updated timestamps.
Tips: Decouple API from execution with a durable queue/stream. Ingest submissions, assign a unique submissionId, persist metadata, then enqueue. Workers auto-scale on CPU/lag, consume with at-least-once semantics, and enforce idempotency when writing results. Apply backpressure and per-user or per-contest rate limits to prevent abuse. Use dead-letter queues for poison messages and worker heartbeats with timeouts for stuck executions. Pre-warm worker pools for popular languages near contest start, and implement basic fairness (e.g., per-user concurrency caps) to avoid starvation.
Relevant Patterns
Relevant patterns that you should know for this question
Submission compilation and execution are CPU-bound and can take seconds; putting them on an asynchronous worker pool with explicit timeouts and progress states prevents API timeouts and keeps the system responsive.
Each submission flows through multiple durable steps—persist, enqueue, compile, run tests, aggregate results, score, update leaderboard—requiring idempotency, retries, and clear state transitions to avoid double-scoring or lost updates.
Leaderboards and verdict notifications benefit from near-real-time updates; a push-lite approach (short polling or SSE) backed by a materialized leaderboard provides low latency without unnecessary complexity.
Relevant Technologies
Relevant technologies that could be used to solve this question
PostgreSQL models users, contests, problems, submissions, and scoring rules with strong consistency and transactional guarantees, making it well-suited for contest windows, constraints, and auditing.
Similar Problems to Practice
Related problems to practice for this question
Both require secure sandboxed execution, verdict pipelines, and contest leaderboards with near-real-time updates and tie-breaking logic.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Computing the leaderboard by querying and sorting the primary database on every poll.
This creates extreme read and sort contention during contests, leading to high latency and DB saturation. A materialized leaderboard (e.g., Redis sorted set) is expected to keep reads cheap and fast.
Running untrusted user code synchronously in the API tier without strong sandboxing.
This risks security breaches, noisy-neighbor outages, and cascading failures. Execution must be isolated in constrained sandboxes, off the request path, with strict time/memory/IO limits.
No idempotency or backpressure in the submission pipeline.
At-least-once processing without deduplication can double-score users; lack of backpressure causes queue blow-ups and missed SLAs under spikes. Use submissionId-based dedup, DLQs, and rate limits.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late August, 2025
Meta
Manager
Late August, 2025
Meta
Staff
Late August, 2025
Meta
Manager
Your account is free and you can post anonymously if you choose.