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

SeniorPrefer not to say

Apr 2026

Summary

System design round at Meta for a software engineer role. The prompt was to design LeetCode with a focus on contest infrastructure and leaderboards, which sounds contained until you get into the weeds on scaling the judge.

Questions Asked (2)

Design a system like LeetCode, with particular emphasis on supporting coding contests and a real-time leaderboard.

System DesignTechnical Trade-offsData Modeling

Author's notes

I went with sandboxed containers for the code execution layer pretty early, which felt like the right call and the interviewer seemed fine with it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying functional and non-functional requirements, then design the core system components: problem repository, code execution service, contest management, and real-time leaderboard. Focus on the unique challenges of contests (e.g., synchronized start, submission validation) and leaderboard (e.g., low-latency updates, ranking at scale).

Pro tip: Emphasize trade-offs between consistency and latency in the leaderboard, and propose a hybrid approach using WebSockets for real-time updates and a distributed cache for ranking. Also, discuss how to handle cheating and ensure fairness during contests.

1. Clarify Requirements

Ask questions to understand scale (e.g., number of users, contests, submissions per second), latency requirements, consistency needs, and features like contest types, scoring rules, and leaderboard visibility.

2. High-Level Design

Outline main components: problem service, submission service, code execution engine, contest service, leaderboard service, and user service. Sketch data flow for a typical contest submission and leaderboard update.

3. Deep Dive into Contests

Detail contest lifecycle: creation, registration, start/end, submission handling, and scoring. Discuss how to ensure all participants see the same problems at the same time and how to handle late submissions.

4. Real-Time Leaderboard

Design leaderboard architecture: use a fast in-memory data store (e.g., Redis sorted sets) for ranking, update on each submission, and push updates to clients via WebSockets. Discuss sharding and caching for scale.

5. Trade-offs and Scalability

Discuss trade-offs: consistency vs. latency, cost of real-time updates, and how to scale each component. Mention monitoring, fault tolerance, and security considerations.

Key Points to Mention

Use of message queues (e.g., Kafka) to decouple submission processing from leaderboard updates.
Code execution sandboxing and security to prevent malicious code.
Leaderboard ranking algorithm: handling ties, dynamic scoring, and efficient updates.
WebSocket or Server-Sent Events for real-time leaderboard updates.
Database choices: SQL for transactional data, NoSQL for scale, Redis for caching/ranking.
Contest fairness: preventing cheating, rate limiting, and ensuring synchronized problem release.

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

How would you scale the code judge infrastructure, and how do you track the state of individual judge instances?

System DesignTechnical Trade-offs

Author's notes

This is where it got uncomfortable.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a scalable architecture that separates submission handling, judging, and state management. Emphasize horizontal scaling of judge workers, a distributed queue for submissions, and a centralized state store (e.g., Redis or a database) for tracking instance health and job status.

Pro tip: Discuss the trade-offs between consistency and availability in state tracking, and how you would handle failures gracefully (e.g., idempotent job processing, heartbeats with timeouts). Also, mention the importance of monitoring and auto-scaling based on queue depth and worker health.

1. Clarify Requirements and Constraints

Ask about expected load (submissions per second, peak times), latency requirements, language support, and security considerations. This ensures your design meets the actual needs.

2. High-Level Architecture

Outline components: API gateway for submissions, a distributed message queue (e.g., Kafka, RabbitMQ) for decoupling, a pool of judge workers that execute code in sandboxes, and a state store for tracking job status and worker health.

3. Scaling the Judge Workers

Explain horizontal scaling by adding more workers, using container orchestration (e.g., Kubernetes) for auto-scaling based on queue depth. Discuss partitioning work by language or problem to optimize resource usage.

4. Tracking Instance State

Describe using heartbeats from workers to a central registry (e.g., etcd, Consul) or a database, with timeouts to detect failures. For job state, use a database or Redis to store status (queued, running, completed, failed) and results.

5. Handling Failures and Trade-offs

Discuss idempotency, retries, and dead-letter queues for failed jobs. Address trade-offs: e.g., strong consistency vs. eventual consistency in state tracking, and cost vs. performance in scaling.

Key Points to Mention

Use of a distributed message queue to decouple submission from execution and enable backpressure.
Sandboxing and isolation for security (e.g., containers, seccomp, cgroups).
Auto-scaling judge workers based on queue length and CPU/memory usage.
Heartbeat mechanism with timeouts to detect and replace unhealthy judge instances.
Centralized state store (e.g., Redis, DynamoDB) for job status and worker registry.
Idempotent job processing and retry logic to handle failures without duplicate execution.

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