System Design: Coding Practice Platform Backend

Watch someone solve the design a coding practice platform problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type
Design a Coding Practice Platform
Interview question
Design a system similar to a well-known competitive programming and interview prep platform. The system must support browsing and filtering problems by difficulty and language, providing an in-browser IDE, submitting code for evaluation, and returning results asynchronously. Stretch goals include supporting large-scale competitions with up to 100,000 simultaneous participants and a real-time leaderboard. Core challenges include securely isolating code execution environments, handling async job processing at scale, and choosing appropriate storage strategies for structured and unstructured data.

Interview Feedback

Feedback about Aerodynamic Lemur (the interviewee)

Advance this person to the next round?
Yes
How were their technical skills?
3/4
How was their problem solving ability?
4/4
What about their communication ability?
3/4

Strengths & what went well
Excellent overall performance for someone who said this was their first system design mock. You immediately identified the async pattern — submitting code, getting a submission ID back, and polling for results via Kafka — without any prompting. That is the single most important architectural decision in this problem and most candidates miss it entirely. Your API design was well-structured with proper REST verbs and clear request/response contracts. You correctly identified the need for secure isolated execution environments (sandboxing with cgroups, resource limits) as a non-functional requirement, which is a critical security consideration that many candidates overlook. Your scale estimation was reasonable and you used the numbers to inform design choices. The competition extension with Redis sorted sets and CDC from Postgres was a strong addition — you picked the right data structure for leaderboard ranking and explained why. The Kubernetes pod orchestration design was well thought through with HPA for autoscaling and health checks for crash recovery. Components were nicely isolated — pods interact only through the queue, not directly with the database, which is a good security boundary.

Areas for improvement
Storage was the weakest area. You defaulted to putting everything in Postgres, including test cases and problem descriptions, which are unstructured data that can be large files. The pattern here is polyglot storage: structured relational data (users, problems, submissions with their relationships) goes in Postgres, while unstructured content (problem descriptions with images, test case files, starter code templates) goes in blob storage like S3 with URL references stored in Postgres. This wasn't something you considered until prompted. The fix is to add an entity design step before jumping into APIs and storage — list your entities (Problem, User, Submission, TestCase), identify their relationships, then ask yourself what kind of data each entity contains. That naturally leads you to the right storage choices. The other gap was queue failover mechanics. You described health checks and retries at a high level but couldn't articulate when exactly messages get removed from the queue, what happens to in-flight messages when a pod crashes, or the difference between consuming-then-processing versus locking-then-processing-then-dequeuing. This matters because your current design ties pod lifecycle to job lifecycle (one pod = one submission), which breaks down at larger scale when you need to consolidate pods for efficiency.

Advice for future interviews
Before drawing any architecture, spend 2-3 minutes on entity design. List your core entities, their relationships (one-to-many, many-to-many), and what kind of data each holds (structured vs unstructured, small vs large). This naturally drives both your API design (entities map to REST resources) and your storage choices (relational for structured joins, blob storage for files). For Canva specifically, storage design matters a lot since their product is fundamentally about managing creative assets — images, templates, designs — which are all unstructured blob data with structured metadata. Showing strong polyglot storage thinking will resonate with their interviewers. Read up on the differences between Kafka and SQS for job queues. Kafka excels at high-throughput event streaming where losing occasional messages is acceptable. SQS is better for task queues where you need visibility timeouts, message locking, and guaranteed processing — which is exactly what code execution needs. Understanding this distinction and being able to justify your choice is strong senior-to-staff signal. Practice explaining queue failover patterns: lock an item so no other consumer picks it up, process it, then delete it only after successful completion. If the lock expires (pod crashed), the item becomes visible again for retry. This is a fundamental distributed systems pattern worth knowing cold.