##### Question Design an online coding practice and judging platform (think LeetCode / HackerRank / Codeforces) where users submit solutions that are compiled and executed against hidden test cases, then graded asynchronously. Walk through the end-to-end architecture, APIs, data models, scaling strategy, and failure handling. Address the following: 1. **User-facing features** – user accounts/auth, problem browsing, full-text search and filtering, and per-user submission history. 2. **Submissions** – multi-language support (e.g., Python, Java, C++), an intake API that returns a submission id, and idempotent handling of duplicate/retried submits. 3. **Secure execution** – compile and run *untrusted* code in sandboxed environments with strict CPU, memory, and wall-clock limits, no outbound network, and isolation strong enough to contain a malicious submission. 4. **Asynchronous grading** – a distributed judge worker fleet pulling from a task queue, per-test execution, result aggregation/verdict computation (AC/WA/TLE/MLE/RE/CE), and live status updates (queued / running / accepted / failed). 5. **Storage** – data models for users, problems, submissions, and per-test results; object storage for source code, compile/run logs, and test-data bundles. 6. **Test-data versioning and re-judging** – immutable, versioned test bundles; pinning the exact version a submission ran against; and re-running cohorts of submissions when tests, checkers, or limits change. 7. **Anti-cheat / plagiarism detection** – scalable code-similarity clustering plus behavioral signals. 8. **Rate limiting and fairness** – per-user/IP submission limits, contest priority, and queue backpressure so contest spikes don't starve regular users. 9. **Caching, observability (metrics/tracing/logging), and security isolation.** 10. **Scaling strategy and failure handling** – how the system scales to contest spikes (e.g., 1k submissions/min) and stays correct when workers crash or the queue redelivers a job. Discuss the key trade-offs you make along the way (e.g., container vs. microVM isolation, managed queue vs. event stream).

A Meta software-engineer onsite system-design question: design an online coding judge (LeetCode/HackerRank-style) that compiles and executes untrusted user submissions against hidden tests and grades them asynchronously. It tests secure sandboxed execution with CPU/memory/time limits, a distributed queue-backed worker fleet, data modeling and APIs, test-data versioning and re-judging, anti-cheat, rate limiting/fairness, caching, observability, and contest-scale failure handling.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Meta.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Meta during technical interviews.

Design an online coding judge | Meta Interview Question

Question

Design an online coding practice and judging platform (think LeetCode / HackerRank / Codeforces) where users submit solutions that are compiled and executed against hidden test cases, then graded asynchronously. Walk through the end-to-end architecture, APIs, data models, scaling strategy, and failure handling.

Address the following:

User-facing features – user accounts/auth, problem browsing, full-text search and filtering, and per-user submission history.
Submissions – multi-language support (e.g., Python, Java, C++), an intake API that returns a submission id, and idempotent handling of duplicate/retried submits.
Secure execution – compile and run untrusted code in sandboxed environments with strict CPU, memory, and wall-clock limits, no outbound network, and isolation strong enough to contain a malicious submission.
Asynchronous grading – a distributed judge worker fleet pulling from a task queue, per-test execution, result aggregation/verdict computation (AC/WA/TLE/MLE/RE/CE), and live status updates (queued / running / accepted / failed).
Storage – data models for users, problems, submissions, and per-test results; object storage for source code, compile/run logs, and test-data bundles.
Test-data versioning and re-judging – immutable, versioned test bundles; pinning the exact version a submission ran against; and re-running cohorts of submissions when tests, checkers, or limits change.
Anti-cheat / plagiarism detection – scalable code-similarity clustering plus behavioral signals.
Rate limiting and fairness – per-user/IP submission limits, contest priority, and queue backpressure so contest spikes don't starve regular users.
Caching, observability (metrics/tracing/logging), and security isolation.
Scaling strategy and failure handling – how the system scales to contest spikes (e.g., 1k submissions/min) and stays correct when workers crash or the queue redelivers a job.

Discuss the key trade-offs you make along the way (e.g., container vs. microVM isolation, managed queue vs. event stream).

Question

Address the following:

User-facing features – user accounts/auth, problem browsing, full-text search and filtering, and per-user submission history.
Submissions – multi-language support (e.g., Python, Java, C++), an intake API that returns a submission id, and idempotent handling of duplicate/retried submits.
Secure execution – compile and run untrusted code in sandboxed environments with strict CPU, memory, and wall-clock limits, no outbound network, and isolation strong enough to contain a malicious submission.
Asynchronous grading – a distributed judge worker fleet pulling from a task queue, per-test execution, result aggregation/verdict computation (AC/WA/TLE/MLE/RE/CE), and live status updates (queued / running / accepted / failed).
Storage – data models for users, problems, submissions, and per-test results; object storage for source code, compile/run logs, and test-data bundles.
Test-data versioning and re-judging – immutable, versioned test bundles; pinning the exact version a submission ran against; and re-running cohorts of submissions when tests, checkers, or limits change.
Anti-cheat / plagiarism detection – scalable code-similarity clustering plus behavioral signals.
Rate limiting and fairness – per-user/IP submission limits, contest priority, and queue backpressure so contest spikes don't starve regular users.
Caching, observability (metrics/tracing/logging), and security isolation.
Scaling strategy and failure handling – how the system scales to contest spikes (e.g., 1k submissions/min) and stays correct when workers crash or the queue redelivers a job.

Discuss the key trade-offs you make along the way (e.g., container vs. microVM isolation, managed queue vs. event stream).

Design an online coding judge

Quick Overview

Question

Solution

Submit Your Answer to Earn 20XP

Design an online coding judge

Quick Overview

Question

Solution

Submit Your Answer to Earn 20XP