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

SeniorPrefer not to say

Jun 2026

Summary

Meta system design round focused on building a LeetCode-style coding judge platform, which sounds scoped until you realize they want the full thing: sandboxed grading, user profiles, contest infrastructure, and a real-time leaderboard that doesn't fall apart under load. Solid question, took me a while to find my footing.

Questions Asked (1)

Design a coding judge platform like LeetCode, including problem catalog, code submission with sandboxed grading, user profiles, and contest support with real-time leaderboards.

System DesignTechnical Trade-offsAlgorithms & Data Structures

Author's notes

I started with the problem catalog and submission flow, which felt safe, but the interviewer kept nudging toward the contest side and I realized I'd been avoiding it because leaderboards under write pressure are genuinely tricky.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (e.g., number of users, submissions per day, contest frequency) to scope the design. Then propose a high-level architecture covering the main components: problem catalog, submission pipeline with sandboxed execution, user profiles, and contest system with real-time leaderboards. Dive deep into the most challenging parts: sandboxing, scalability, and real-time updates, discussing trade-offs and potential bottlenecks.

Pro tip: Emphasize security and isolation in the code execution sandbox, as it's the most critical and risky component. Also, discuss how you would handle peak loads during contests, such as auto-scaling and queueing, to demonstrate production readiness.

1. Clarify Requirements and Scale

Ask questions to understand functional and non-functional requirements: number of users, problems, submissions per day, contest frequency, expected latency, and consistency needs. This helps prioritize design decisions.

2. High-Level Architecture

Outline the main components: web servers, problem catalog service, submission service, sandboxed execution workers, user profile service, contest service, and leaderboard service. Describe how they interact and the data flow.

3. Deep Dive into Critical Components

Focus on the sandboxed execution environment: how to isolate code (containers, VMs, seccomp), resource limits, and security. Also cover the submission pipeline: queueing, scaling workers, and handling timeouts.

4. Real-Time Leaderboards and Contests

Explain how to achieve real-time leaderboards during contests: use WebSockets or SSE for push updates, and an in-memory data store (e.g., Redis sorted sets) for fast ranking. Discuss consistency vs. latency trade-offs.

5. Scalability, Reliability, and Trade-offs

Discuss how to scale each component (horizontal scaling, sharding, caching), handle failures (retries, idempotency), and trade-offs (e.g., strong vs. eventual consistency for leaderboards, cost vs. performance).

Key Points to Mention

Sandboxing techniques: containers (Docker), VMs, gVisor, seccomp, resource limits (CPU, memory, time).
Submission queue and worker pool: use message queue (e.g., Kafka, RabbitMQ) to decouple submission from execution, auto-scale workers based on load.
Database design: SQL for user profiles and problem catalog, NoSQL for submissions and logs; caching with Redis for hot data.
Real-time leaderboard: Redis sorted sets for ranking, WebSocket for push updates, and strategies for handling high write throughput during contests.
Contest support: scheduling, registration, problem set management, and anti-cheat measures (plagiarism detection, monitoring).
Trade-offs: consistency vs. availability for leaderboards, cost of sandboxing, and latency vs. accuracy in grading.

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