Loading…

Design a Coding Practice Platform (LeetCode/HackerRank) - SystemRound

Design a Coding Practice Platform (LeetCode/HackerRank)

hardSystem design50 min5 stagesPro

Asked atMetaGoogleAmazonMicrosoftDatabricksRobloxStripe

Design a platform where users solve programming problems, submit code, run public samples, get judged against hidden tests, join timed contests, and see rankings. The hard parts are sandboxed execution, queue isolation across languages and tenants, hidden test-case secrecy, contest traffic spikes, leaderboard freshness, plagiarism signals, and trustworthy judging results.

Best after a few full reps. Expect follow-up questions, edge cases, and deeper trade-off discussion.

What this problem tests

Submission APICatalog and Contest APIsSecurity and Error SemanticsCore Components and FlowIsolation and SchedulingDataflow Correctness

Round shape

5 stages

Time budget

50 min

Feedback loop

Grade anytime

Guided practice·Primary loop

Guided practice

Workspace-first, hints visible, stage retry available. The cheap, repeatable loop — build the answer shape before you take it under pressure.

Stage-by-stage workspace instead of a blank page.
Grade one stage or the whole answer whenever you want.
Compare your reasoning against reference criteria and model answers.

Solve once, compare against the checklist, then come back to the weak stage instead of starting over.

Mock interview·Pressure test

Mock interview

Strict timer, hints hidden, debrief deferred to the end. Use this once you can already structure a clean answer and want to pressure-test pacing and pushback.

Best once the answer shape is already in your head.
Pressure-test pacing, pushback handling, and communication.
Use diagnosis after the interview for exact misses and next study steps.

Best after one structured rep · timed · focused on pacing and communication.

Requirements

This is the framing pass. A strong answer quickly defines what the system must do, what quality bar it has to hit, and the numbers that will justify the rest of the design.

First 6 min of the round

What must exist

Functional Requirements

5 items

1Users browse problems, read statements, run public samples, and submit code in supported languages.

2The judge returns verdicts: Accepted, Wrong Answer, TLE, MLE, Runtime Error, Compile Error.

3Contests add registration, timed windows, scoring rules, submission freeze, and a live or delayed leaderboard.

4Admins author problems: statements, constraints, sample tests, hidden tests, resource limits, and editorials.

5Submission history and progress are in scope; plagiarism detection is a post-contest or below-the-line workflow.

What good looks like

Non-Functional Requirements

4 items

1Sample runs return p95 under 5 seconds (users wait in the editor); full hidden-test verdicts p95 under 30s normally, under 90s during contests.

2Browse/submit APIs target 99.95% availability, but judge work can queue as long as acknowledged submissions are durable.

3Untrusted code has no network, no host filesystem access, strict CPU/memory/time limits, and per-run isolation.

4Hidden tests are encrypted and never exposed to clients.

Numbers to anchor the design

Scale Estimation

4 items

12M DAU, 500K submissions/day baseline (~6/sec average), 5K submissions/sec during global contests.

2Contests dominate design: 5K submissions/sec x 30 tests x 1s average execution is 150K CPU-sec/sec if every test runs separately.

3We need sharded test execution, aggressive queueing, worker autoscaling, and fair scheduling.

4Submission rows are small, but code/stdout/test artifacts belong in object storage with metadata in SQL.

How the round unfolds

Each stage has a distinct job. Treat them like separate deliverables instead of one giant answer, and the round becomes much easier to navigate.

4 design stages · 40 pts after framing

🔌

Stage 2~7 min10 pts

API Design

Define the contract clearly: the endpoints, auth boundary, error semantics, and the one or two decisions that matter most.

What you should produce

Define the API surface. How do clients fetch problems, run public samples, submit code, poll or stream verdicts, and read contest leaderboards?

Strong answers cover

Submission APICatalog and Contest APIsSecurity and Error Semantics

🏗️

Stage 3~12 min10 pts

High-Level Architecture

Lay out the main components and trace the write path, read path, and any async path cleanly.

What you should walk through

Walk me through the high-level architecture.

Strong answers cover

Core Components and FlowIsolation and SchedulingDataflow Correctness

💾

Stage 4~10 min10 pts

Data Model & Storage

Pick the store, show the schema or key model, and explain why that storage choice fits the access pattern.

What you should lock in

What data model and storage systems would you use for problems, submissions, test cases, judge results, contest standings, and code artifacts?

Strong answers cover

Entity ModelIndexes and PartitioningConsistency and Durability

📈

Stage 5~15 min10 pts

Scaling & Deep Dive

Name the first bottleneck, failure modes, and the trade-offs that keep the system fast and reliable under pressure.

What you should pressure-test

Let us deep dive. How would you handle contest spikes, sandbox security, queue backpressure, leaderboard freshness, plagiarism detection, and opera...

Strong answers cover

Contest and Queue ScalingSandbox and Abuse HandlingCorrectness and Operations

What a strong first rep looks like

Scope clearly

Translate the prompt into concrete requirements, scale, and trade-offs before drawing architecture.

Stay stage-specific

Give APIs in the API stage, data models in the storage stage, and failure modes in scaling. Don't blur them together.

Iterate fast

Grade early, compare to the reference reasoning criteria, fix the biggest misses, and re-submit the weak stage instead of starting over.