Portfolio  ›  Projects  ›  Coding Challenges
PythonFastAPILocal LLMEdTech

Coding Challenges,
Judge & Interview Platform

Running a learner's code safely is the hard part of any coding platform. This one judges submissions against test cases in a sandbox, then adapts what it asks next based on what the learner actually got wrong.

◆ Live · deployed on this site
Context: Built for BitWithBite  ·  Role: Sole engineer
Versions: two — v1 established the judge, v2 added adaptation and analytics
20API endpoints
3Hint levels
$0API cost
2Versions
🚀 Try the Platform⚙️ How Judging Works
Overview

A judge, and then everything around the judge

At the centre is a code judge: a submission runs against hidden test cases in a sandbox and comes back with a pass or fail per case. Around that sit the parts that make it a learning platform rather than a grader — three escalating hint levels, an AI mentor that guides without handing over the answer, and a visual debugger that traces execution step by step so a learner can see where their reasoning diverged.

Version 2 added adaptation. A skill tree tracks which concepts a learner has demonstrated, difficulty is recommended from their actual history rather than a fixed ladder, and a teacher dashboard surfaces where a cohort is collectively stuck.

The Problem

Telling someone their code is wrong teaches very little

A binary pass/fail tells a learner that something is broken but not what they misunderstood. The useful information is where execution diverged from what they expected — and that is exactly what a plain judge throws away.

Fixed difficulty ladders have the same problem from the other direction: they move at the pace of the curriculum rather than the pace of the learner, so the same sequence bores one person and loses another.

Technical Approach

Execute safely, explain the failure

Submissions run in an isolated execution layer against per-challenge test cases, so a wrong or hostile submission cannot affect the service. Results come back per case rather than as a single verdict.

The debugger records execution as a sequence of steps the learner can walk through. The mentor and code-review features run on a local model and are optional — without one, judging, hints, the skill tree and analytics all still work.

01 SUBMITLearner submits a solution
02 SANDBOXIsolated execution
03 JUDGEPer-test-case results
04 EXPLAINStep trace, hints, AI review
05 ADAPTSkill tree updates, next challenge recommended
Capabilities

What it does

⚙️

Judging

  • Sandboxed code execution
  • Per-test-case results
  • Live timer per challenge
  • XP, badges and streaks
🔍

Understanding

  • Step-by-step visual debugger
  • Three escalating hint levels
  • AI mentor that guides rather than solves
  • AI code review with a score
🌱

Progression

  • Skill tree of demonstrated concepts
  • Adaptive difficulty recommendation
  • Interview mode
  • Teacher dashboard and cohort analytics
Technologies

Actual stack

Service
FastAPIUvicornEmbeddable iframe
Execution
Sandboxed runnerTest-case harness
AI
OllamaLocal LLMOptional — degrades cleanly
Learning
Skill treeAdaptive difficultyAnalytics
Limitations

Scope

⚠️ Python-focused, and not a hosted exam system

The challenge set and judge target Python. Adding another language means adding an execution path for it — the architecture allows it, but it is not built.

Sandboxing is designed for a learning context, not for running untrusted code from the open internet at scale. No claim is made about adversarial resistance under load.

Solve one on this site

The platform is deployed here with the judge, hints and debugger live. Submit a wrong answer deliberately and step through the trace.