04QuestionsLeetCode

04 · Worked prompt

LeetCode

Design secure code execution, sandbox pools, test orchestration, result streaming, and contest bursts.

40 minInterview blueprint

INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

20pts
Scope the problem
0–5 min
Prioritize the core flows, state the scale, and name the non-goals.
15pts
Define contracts
5–10 min
Identify durable entities, APIs, idempotency, and the source of truth.
30pts
Complete the diagram
10–25 min
Trace one write path and one read path. Label the commit boundary and async work.
20pts
Lead one deep dive
25–38 min
Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.
15pts
Prove reliability
38–45 min
Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design secure code execution, sandbox pools, test orchestration, result streaming, and contest bursts.

LeetCode system architecture. Submission state is durable; untrusted execution happens in leased, network-isolated sandboxes. Request path: Candidate browser to Judge API to Submission service to Submission DB. Asynchronous path: Resource-class queues to Runner controller. Read path: Verdict API to Result/log store. External dependency: Sandbox pool. Delivery path: Result stream. — LeetCode · system architecture

DEFEND THE DIAGRAM

Explain every boundary before adding more boxes.

Submission state is durable; untrusted execution happens in leased, network-isolated sandboxes.

INTERVIEW CONTRACT

Design secure code execution, sandbox pools, test orchestration, result streaming, and contest bursts.

CAPACITY QUESTIONS TO QUANTIFY

Untrusted code · bursty contests · CPU/memory caps · deterministic environments. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

End-to-end walkthrough

Trace the architecture in this order.

01
Enter and classify the request
Candidate browser → Judge API
Source, submit, result stream enters over HTTPS / RPC. Judge API handles identity, admission, routing, and request context; it deliberately does not own domain truth.
02
Validate, then cross the commit boundary
Judge API → Submission service → Submission DB
Submission service receives the command, checks invariants and retry identity, then uses create submission to update Submission DB. The user-visible mutation is accepted only after this boundary succeeds.
03
Move replayable work off the request path
Submission service → Resource-class queues → Runner controller → Result/log store
Submission service emits publish after commit; Runner controller uses consume and project / update to build Result/log store. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
04
Serve reads from the right authority
Judge API → Verdict API → Result/log store / Submission DB
Verdict API uses optimized read for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
05
Contain the dependency boundary
Runner controller → Sandbox pool
isolated run crosses into Sandbox pool. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.
06
Deliver without changing the source of truth
Runner controller → Result stream → Candidate browser
Runner controller uses fan-out; Result stream returns updates over SSE. Sequence IDs, reconnect cursors, and backpressure make delivery resumable without turning a socket into durable state.

Ownership ledger

Why each box exists—and what it must defend.

Component	Owns	Why it exists	Interviewer probe
Judge APIAuth, contest quota, size	Identity, admission, routing	Protects the system edge and attaches trusted context before domain work begins.	Timeout budgets, quotas, regional routing
Submission serviceFreeze source + execution plan	Write invariants and retry identity	Serializes or conditionally applies state changes before acknowledging success.	Concurrent writes, deduplication, hot ownership
Submission DBPlan, attempts, verdict	Authoritative durable state	Provides the one record used to resolve disputes, recover, and rebuild projections.	Partition key, replication, consistency
Resource-class queuesLanguage + CPU/memory	Durable asynchronous handoff	Absorbs bursts and lets slow or optional work retry independently of the request.	Ordering key, lag, retention, dead letters
Runner controllerLease + sanitize output	Replayable processing	Runs expensive, fan-out, or side-effecting work with leases and bounded retries.	Idempotency, poison work, autoscaling
Result/log storePer-test output + usage	Rebuildable query state	Shapes data for the dominant reads without weakening the write-side invariant.	Freshness, versioning, rebuild time
Verdict APIStatus + public test results	Read composition and freshness policy	Chooses authoritative or derived state and returns a stable client contract.	Fan-out, cache policy, partial results
Sandbox poolCompile and execute	External capability, not local truth	Keeps a specialized or third-party concern behind a replaceable contract.	Ambiguous timeout, circuit breaking, fallback
Result streamProgress + terminal verdict	Connection and delivery state	Separates open connections and fan-out pressure from durable domain state.	Reconnect, ordering, slow consumers

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage: PostgreSQL stores submissions, manifests, attempts, and verdicts; S3 stores source/logs/artifacts; durable queues feed sandbox runners.
Partitioning / sharding: Hash by submission_id and queue by language/resource class. Give contests isolated shards/pools; key artifacts by submission/attempt digest.
Indexes: Unique idempotency key, (contest_id, created_at), (user_id, problem_id, created_at), lease expiry, and verdict version.
Replication + consistency: Submission/verdict transitions are conditional and replicated. Execution is at least once; only one attempt version becomes the verdict.
Cache, queue + recovery: Leased microVM runners are disposable. Cache immutable test manifests locally; stream logs separately from execution.
Capacity math: Estimate contest burst, compile/run CPU, memory class, log MB/sec, queue age, and sandbox cold start.
Alternative rejected: Executing in the API service is simple but unsafe and not independently scalable; sandbox runners create the required boundary.

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Isolation

Use microVM or hardened container, no ambient network, read-only images, seccomp, cgroups, and outer watchdogs

Limits inside contestant code are not security controls

Fair scheduling

Use contest and user token buckets plus separate heavy-language queues

FIFO alone lets one workload dominate

Determinism

Pin compiler, image, tests, locale, clock policy, and resource model

A judge result must be reproducible enough to appeal

Failure pressure test

Show detection, containment, recovery, and evidence.

Sandbox escape signal

Kill host workload, quarantine node, and rotate credentials

security violations

Runner lost

Retry under a new attempt while retaining the same submission

system-error retry count

Contest surge

Prewarm bounded pools and reject above explicit queue SLO

queue age by language

Before you finish, explicitly cover

Functional requirements and non-goals
Peak traffic, storage, bandwidth, and growth
Entities, APIs, idempotency, and pagination
Source of truth and consistency promise
Partition key, replicas, caches, and hot spots
Retries, backpressure, failover, and reconciliation
Latency, saturation, correctness, and recovery metrics
Security, migration, cost, and multi-region evolution

SAY THIS WHILE YOU DRAW

A four-part talk track

Scope
“I’ll prioritize compile and run multiple languages and execute hidden tests under hard resource limits.”
Scale
“The design changes around untrusted code · bursty contests · cpu/memory caps · deterministic environments.”
Decision
“MicroVMs maximize isolation; containers are cheaper and faster with a tighter security boundary.”
Risk
“The first failure I want to pressure-test is: Fork bombs, escapes, leaked tests, and contest spikes can compromise the fleet.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements

Compile and run multiple languages
Execute hidden tests under hard resource limits
Stream progress and return deterministic verdicts
Handle contest bursts without cross-tenant leakage

LeetCode · state lifecycle

state lifecycle

Each transition must be durable, observable, and safe to retry.

queued

compiling

running

accepted or rejected

system error

02Data model and APIs4 entities · 3 interfaces

Core entities

Submissionsubmission_id, user_id, source_digest, language, stateOwner: Submission service

ExecutionPlanimage_digest, limits, tests_versionOwner: Judge service

TestAttemptsubmission_id, test_id, verdict, usageOwner: Runner

ContestQuotacontest_id, user_id, submissions_leftOwner: Admission service

External interfaces

POST /v1/problems/{id}/submissions

Create an immutable submission

GET /v1/submissions/{id}/events

Stream compile and test verdict events

POST /internal/attempts/{id}/complete

Commit signed runner output

03Deep dives and trade-offsChoose one

Isolation

Use microVM or hardened container, no ambient network, read-only images, seccomp, cgroups, and outer watchdogs

Limits inside contestant code are not security controls

Fair scheduling

Use contest and user token buckets plus separate heavy-language queues

FIFO alone lets one workload dominate

Determinism

Pin compiler, image, tests, locale, clock policy, and resource model

A judge result must be reproducible enough to appeal

04Failures, recovery, and evidence3 scenarios

Sandbox escape signal

Kill host workload, quarantine node, and rotate credentials

security violations

Runner lost

Retry under a new attempt while retaining the same submission

system-error retry count

Contest surge

Prewarm bounded pools and reject above explicit queue SLO

queue age by language

05What makes the answer seniorInterviewer signals

Draw the trust boundary around the runner fleet
Compilation and test execution have different caching opportunities
Do not leak hidden test inputs in logs or failure messages
Primary trade-off: MicroVMs maximize isolation; containers are cheaper and faster with a tighter security boundary.

BEFORE THE NEXT QUESTION

Can you redraw it from memory?

Name the source of truth.
Trace the write and read paths.
Defend one trade-off.
Recover from one failure.

Scope the problem

Define contracts

Complete the diagram

Lead one deep dive

Prove reliability

Write

Propagate

Read

Trace the architecture in this order.

Enter and classify the request

Validate, then cross the commit boundary

Move replayable work off the request path

Serve reads from the right authority

Contain the dependency boundary

Deliver without changing the source of truth

Why each box exists—and what it must defend.

Name the database, shard key, indexes, and guarantees.

Pick one risk and explain the mechanism, alternative, and cost.

Isolation

Fair scheduling

Determinism

Show detection, containment, recovery, and evidence.

Sandbox escape signal

Runner lost

Contest surge

Reference details

Core entities

External interfaces

Isolation

Fair scheduling

Determinism

Sandbox escape signal

Runner lost

Contest surge

Can you redraw it from memory?