Meta·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jun 2026

Summary

Meta system design round focused entirely on building an online judge from scratch. One big open-ended question for the whole session, which sounds manageable until you realize how many subsystems are hiding inside it.

Questions Asked (1)

Design an online code judging platform where users submit code for a problem and receive a verdict such as Accepted, Wrong Answer, Time Limit Exceeded, Memory Limit Exceeded, Runtime Error, or Compilation Error. Cover problem and test case storage, a submission queue, sandboxed execution workers with resource limits, language runtime management, the full judging pipeline from compile to verdict aggregation, result storage, submission history, leaderboard, anti-abuse mechanisms, and fair resource sharing across users. Also discuss scaling the worker pool, isolating untrusted code, and handling infinite loops or runaway submissions.

System DesignTechnical Trade-offs

Author's notes

I started with the happy path, compile then run then return a verdict, and felt pretty good for the first few minutes.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then sketch a high-level architecture covering submission flow, judging pipeline, and result storage. Dive deep into the critical components: sandboxed execution, queueing, and resource isolation. Finally, discuss scaling, anti-abuse, and trade-offs, emphasizing security and fairness.

Pro tip: Emphasize that the sandbox must enforce strict resource limits (CPU, memory, disk, network) and that the judging pipeline should be idempotent and fault-tolerant. Mention that using containerization with seccomp and cgroups is a practical approach, but also consider lightweight VMs for stronger isolation.

1. Clarify Requirements and Scale

Ask about expected number of users, submissions per second, supported languages, and time/memory limits. Establish non-functional requirements like security, fairness, and low latency.

2. High-Level Architecture

Outline the main components: API gateway, submission service, queue, judge workers, result store, and leaderboard. Explain the flow from submission to verdict.

3. Deep Dive into Critical Components

Detail the sandboxed execution environment, resource limits, language runtime management, and the judging pipeline (compile, run tests, aggregate verdicts). Discuss anti-abuse mechanisms like rate limiting and plagiarism detection.

4. Scaling and Reliability

Explain how to scale the worker pool horizontally, handle infinite loops via timeouts, and ensure fair resource sharing with quotas and priority queues. Discuss fault tolerance and retries.

5. Trade-offs and Wrap-up

Summarize key trade-offs (e.g., isolation strength vs. performance, queue latency vs. throughput) and propose a concrete design that balances them.

Key Points to Mention

Sandboxing techniques: containers (Docker) with seccomp, cgroups, and namespaces; or lightweight VMs (Firecracker) for stronger isolation.
Resource limits: CPU time, memory, disk I/O, network, and process count; enforce via cgroups and timeouts.
Queueing: use a distributed message queue (e.g., Kafka, RabbitMQ) to decouple submission from judging; ensure at-least-once delivery and idempotency.
Language runtime management: pre-built Docker images per language, versioning, and caching to reduce startup latency.
Judging pipeline: compile step (capture compilation errors), run test cases in parallel, aggregate verdicts with priority (e.g., Compilation Error > Runtime Error > TLE > MLE > WA > Accepted).
Anti-abuse: rate limiting, submission quotas, plagiarism detection, and monitoring for malicious code (e.g., fork bombs, network calls).
Fair resource sharing: per-user quotas, priority queues for different user tiers, and fair scheduling algorithms.
Scaling: auto-scaling worker pools based on queue depth, using spot instances for cost efficiency, and sharding by language or problem.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.