TorchCode: a judged LeetCode for PyTorch operators

Three ways to start, from zero install to local build

The README leads with the zero-install path because it is the fastest way to judge whether the idea is worth anything to you. There is a Hugging Face Spaces deployment that opens a full JupyterLab environment in a browser with nothing installed, and every problem notebook also carries an Open in Colab badge, so you can go from a browser tab to a working cell in a few clicks.

The container path is the documented self-hosted route:

docker run -p 8888:8888 -e PORT=8888 ghcr.io/duoan/torchcode:latest

If that image is not available for your platform, the README says this is the common case on Apple Silicon and arm64, the fallback is a local build:

make run

`make run` tries the prebuilt image first and falls back to a local build automatically, and the result is a JupyterLab at http://localhost:8888. Both Docker and Podman are auto-detected, which matters for anyone on a Mac who does not want Docker Desktop running.

The third path is a standalone web application that does not look like Jupyter at all: a FastAPI backend on port 8000 and a Next.js frontend on port 3000, with a dual-pane layout and integrated IDE. Those are three quite different products built on the same problem set, which is the most interesting structural fact about this repository.

Installing just the judge, for an existing notebook

The most useful piece for a lot of readers is the smallest one. The judge is published to PyPI as `torch-judge`, so if you already have a notebook open somewhere you do not need the platform at all:

!pip install torch-judge

Then four functions are the entire API:

from torch_judge import check, status, hint, reset_progress
status()           # list all problems and your progress
check("relu")      # run tests for the "relu" task
hint("relu")       # show a hint

That is a small enough surface to drop into an existing workflow, and it is the reason the project works as a library rather than only as an application. `status` lists problems and your progress against them, `check` runs the tests for one named task, `hint` gives a nudge, and `reset_progress` clears the slate.

The packaging is correspondingly tidy. `pyproject.toml` declares `requires-python = ">=3.10"`, a single runtime dependency of `torch>=2.0`, and a dynamic version read from `torch_judge._version`. The classifiers cover Python 3.10 through 3.12 and mark the package as Beta. It also excludes the notebook assets from the wheel, listing `labextension`, `scripts`, `templates`, `solutions` and `jupyter_config` as directories to leave out, which is the difference between a library install and a platform install.

What the judge actually checks

The feature table in the README describes the judging behaviour in one line: correctness checks, gradient verification and timing. That combination is what separates this from a set of exercises with unit tests.

Correctness is the obvious part. Gradient verification is the interesting one, because a PyTorch implementation that produces the right forward numbers can still have a wrong backward pass, and that is exactly the bug that a whiteboard interview is trying to catch. Timing closes the loop by measuring whether your implementation is merely right or also reasonable.

Around that core sit the affordances you would expect from something built on competitive programming conventions: coloured pass and fail per test case, hints that nudge without giving the answer away, reference solutions to study afterwards, progress tracking that records what you have solved along with best times and attempt counts, and a one-click reset that returns any notebook to its blank template so you can attempt the same problem repeatedly.

The README also states no cloud, no signup and no GPU needed. For an exercise set built around writing attention and normalisation by hand, the absence of a GPU requirement is a genuine design constraint rather than a marketing claim: these are small tensor shapes, and you are being tested on code you write.

Forty-one problems ranked by interview frequency

The problem set is organised into fundamentals, the category the README calls the bread and butter of ML coding interviews, meaning you are asked to write them without `torch.nn`. The visible entries show the ranking system at work, where frequency is marked with a fire symbol for very likely in interviews, a star for commonly asked, and a bulb for emerging or differentiator topics.

The first problem is ReLU, implementing `relu(x)`, marked easy and very likely. The second is Softmax as `my_softmax(x, dim)`, with numerical stability and the exp and log tricks named as the key concepts, which is the detail that actually matters: a naive softmax overflows and an interviewer's first follow-up question is about it. Problem 16 is Cross-Entropy Loss as `cross_entropy_loss(logits, targets)`, with log-softmax and the logsumexp trick listed. Problem 17 is Dropout.

What is missing from the visible portion is as informative as what is present. The README's own framing names the skills under test as `softmax`, `LayerNorm`, `MultiHeadAttention` and full Transformer blocks, so the later sections clearly cover normalisation, attention and complete architectures. Each problem is a separate numbered notebook in `templates/`, with the matching reference implementation in `solutions/`, and the two directories are kept apart in the repository layout so you are not looking at the answer beside the question.

Three front ends sharing one problem set

The repository tree is the clearest argument for the project's design, because it shows the platform built as separate pieces rather than one application.

`torch_judge/` is the judge package that also ships to PyPI. `templates/` holds the problem notebooks and `solutions/` the references. `labextension/` is a JupyterLab extension, and it is a TypeScript project with its own `package.json`, `yarn` setup and a `torchcode_labext` directory, which is what produces the one-click reset toolbar button described in the README. `jupyter_config/` holds the Jupyter server configuration. `api/` and `web/` are the FastAPI backend and Next.js frontend for the standalone interface, and `scripts/` holds operational helpers. `assets/` contains the UI preview image the README shows.

The `Dockerfile` shows how carefully this is assembled, and it is the most instructive file in the repository. It uses a multi-stage build from `python:3.11-slim` with a `build-base` stage that installs a Node toolchain, then a `judge-builder` stage that builds the `torch_judge` wheel, then a `labext-builder` stage that builds the precompiled JupyterLab extension wheel. The comments explain the optimisations: manifests are copied before sources so dependency installs stay cacheable between edits, and the yarn resolutions reference a local patch for the license webpack plugin that must exist before `jlpm install` runs.

`docker-compose.yml` shows the runtime shape, with the image and a local build both specified, port 8888 published, `PORT=8888` in the environment, and three volumes mounted: `./notebooks`, `./torch_judge` and `./data`. The result is that you can edit the judge source and reload without rebuilding the image.

Where the documentation stops

The README is thorough about getting started and thin about the interesting parts, and the split is worth naming because it affects how you evaluate the project.

What it covers properly: the four install paths, the judge API, the feature table, the problem set with difficulty and frequency markers, and the standalone web app instructions including the exact commands for backend and frontend. That is enough to get running and enough to decide whether the problem set matches what you are being asked in interviews.

What it does not cover: how the tests for each problem are written, what tolerance gradient verification uses, how timing is normalised across machines, or what the reference solutions look like. There is no architecture document, no contribution guide in the tree, and no changelog. The repository also has no published releases, which means there is no version history to read and no upgrade notes, and the container image is referenced as `latest` throughout the README and the compose file.

Two smaller signals are worth noting. The repository declares its primary language as Jupyter Notebook rather than Python, which matches a project whose substance is notebooks. And the project publishes to both GitHub Container Registry and a Hugging Face Space, so the demo environment and the image come from the same author but through different distribution paths. The last push was on 2026-07-31 and the repository is not archived.

Editorial conclusion

TorchCode is doing something unusual for the PyTorch ecosystem: it treats implementing an operator from memory as a skill that can be practised and graded, the same way a coding interview treats parsing a tree. The grading is the part worth trusting, since it checks correctness, verifies gradients and measures timing rather than comparing your code to a reference answer, and the 41 problems are chosen by how often interviewers ask them. Run it with `make run` for the container, `pip install torch-judge` if you already have a notebook open in Colab, or the Next.js front end in `web/` if you want something that does not look like Jupyter. The project had no published releases at the time of writing and was last pushed on 2026-07-31, so pin the image tag you tested rather than tracking latest.

Frequently asked questions

Official sources

1. duoan/TorchCode on GitHub
2. Issues
3. Project website
4. README