TorchLeet: 68 PyTorch Interview Problems with an MCP Tutor

The gap TorchLeet fills between LeetCode and a PyTorch tutorial

Most interview practice sites test algorithmic reasoning in a language-agnostic way. They will ask you to reverse a linked list. They will not ask you to implement grouped query attention, a KV cache, or DPO loss. TorchLeet is aimed at that second category. The README states the problems come from first person reports from real engineer interviews at Google, Meta, Anthropic and others, and the repository tags individual problems with company names, so you can see that LoRA is attributed to Meta, Google, Anthropic and OpenAI while continuous batching is attributed to Perplexity, Together AI and Meta. The intended user is someone who already knows Python and wants to be able to write the mechanism from memory under interview conditions. The README is explicit about the method: fill in the TODOs, then compare against the solution. It also carries a warning against using GPT to produce answers, on the grounds that the struggle is the point.

Notebook layout, question and solution file pairs

The repository is organized as Jupyter notebooks, which is why the primary language is listed as Jupyter Notebook. Each problem directory holds a question file and a separate solution file, and the README shows the convention directly: for LoRA you get v3/alignment-training/lora/lora.ipynb alongside v3/alignment-training/lora/lora_SOLN.ipynb, and for the KV cache you get v3/llm-inference/kv-cache/kv-cache.ipynb alongside kv-cache_SOLN.ipynb. Naming is not perfectly uniform. Some LLM-track files carry a question number, such as attention-q4-Question.ipynb and its counterpart attention-q4.ipynb, and some entries in the README's tables have no link at all, including RMS Norm, KL Divergence Loss and SFT on SmolLM. Treat those as placeholders rather than as available problems. The three tracks are Basics with 24 questions, an LLM Learning Path with 23, and Advanced with 48. The README notes that questions overlap between tracks, so the counts are not additive and you should not read 95 as the number of distinct problems.

The LLM learning path as an ordered build

The most interesting structural choice is that the LLM track is sequenced rather than tagged. The README lays out six stages: foundations (byte pair encoding, sinusoidal embeddings, RoPE, RMS norm, attention), core transformer (multi-head attention, grouped query attention, KV cache, sliding window attention), a full model (SmolLM from scratch), alignment and fine-tuning (KL divergence loss, LoRA, SFT, DPO, PPO for RLHF, GRPO), decoding and inference (temperature, top-k, top-p, speculative decoding, continuous batching, a complete inference engine), and systems. That ordering matters because the later notebooks assume the earlier ones. Implementing DPO loss without having written a log-probability pass in the attention notebook is going to be painful. The trade-off is that the path is opinionated. If your target role is kernel-level work rather than alignment, the Advanced track is where you should start, and the LLM path will spend your time on tokenizers and sampling that may never come up.

The MCP server and what it changes about studying

The newer addition is an MCP server published as torchleet-mcp on npm. The README describes it as giving an AI assistant access to all 68 problems, progressive hints, company prep plans and learning paths, while enforcing a no-spoilers teaching style. Setup is a clone followed by a client-specific registration command: claude mcp add torchleet -- npx -y torchleet-mcp for Claude Code, codex mcp add torchleet -- npx -y torchleet-mcp for Codex, or a JSON block with command npx and args ["-y", "torchleet-mcp"] for Claude Desktop, Cursor and VS Code. Four guides are exposed: torchleet-tutor for progressive hints, torchleet-interview-prep for timed mock interviews by company, torchleet-review for code review, and torchleet-explain for intuition-to-math-to-code walkthroughs. There is a real tension here. The README tells you not to paste problems into an assistant, then ships a server whose purpose is to put an assistant next to the problems. The distinction the project is drawing is that a hint-giving tutor is not the same as an answer generator, but that distinction rests on the tutor's prompt behavior, which is not something you can verify from the README alone.

Getting a notebook running and the grader question

The quick start is short. Install PyTorch from the official get-started page, then run jupyter notebook torch/basic/lin-regression/lin-regression.ipynb, fill in the ... and #TODO blocks, and compare with the solution. That is the whole documented loop. Two things are worth flagging. First, the repository description mentions an auto-grader, but the README excerpt supplied here does not document a grading command, a test runner, or a config key for one, so I cannot describe how it works or how to invoke it. Verify that before you plan a study schedule around it. Second, there is no pinned environment file shown in the material. The LLM track includes Triton-related topics and a full inference engine, and those notebooks may have dependencies beyond a base PyTorch install. The README does not say which.

Where TorchLeet is the wrong tool

The clearest failure mode is treating the solution files as an answer key. The README says the author used GPT to help write some of the initial code but tested and solved every problem personally. That is an honest disclosure, and it also means the solutions are one person's implementations, not a reviewed reference. If a solution is subtly wrong or simply unconventional, nothing in the supplied material indicates a review process that would catch it. A second limitation is scope. This is a set of notebooks, not a course. There are no lectures, no prerequisite checks, and no feedback loop other than comparing your file to the solution file. A third case: if your interviews are classical ML theory or SQL-heavy analytics rounds, the PyTorch focus here is largely orthogonal, and the 24 Basics questions will not cover the statistics depth those loops demand.

How this differs from just reading the reference implementations

The obvious alternative is to read the source of a production implementation, for example a well-known transformer library, and to reproduce a component from it. The approaches differ in what they optimize for. A library source file is battle-tested and handles edge cases you will not think of, but it is written for maintainability and performance, not for a reader who has thirty minutes on a whiteboard. TorchLeet inverts that: the notebooks strip a mechanism down to a fill-in-the-blank exercise, which is closer to what an interview actually asks. The cost is that you get no exposure to the production concerns (numerical stability tricks, distributed paths, dtype handling) that a real codebase encodes. A reasonable split is to work the TorchLeet notebook first for recall, then open a production implementation of the same component and note where it diverges. That second step is not part of the repository's documented workflow; it is something you would add.

Licence, maintenance and what to check before adopting

The repository is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. This is not legal advice; read the LICENSE file in the repository for the operative text. On maintenance, the material shows a last push of 2026-09-08 and no retrieved releases, so there is no tagged version to pin against. That means the notebooks you clone today can change under you, and a solution file you relied on may be edited. The repository is not archived, which suggests it is still being worked on, but the absence of releases makes version-to-version comparison impossible from the outside. If you plan to work through the LLM path over several weeks, clone at a specific commit and keep that copy. Before adopting, check three concrete things: whether the auto-grader mentioned in the repository description is documented anywhere you can find, whether the notebooks in your target track have a requirements file or install cell, and whether the unlinked problems in the README tables (RMS Norm, KL Divergence Loss, SFT on SmolLM) actually exist as files.

Editorial conclusion

Adopt TorchLeet if you are preparing for ML/AI interviews and you want to write PyTorch by hand instead of reading about it. Skip it if you need a graded curriculum with verified answer keys, or if you object to the README's own instruction not to paste the problems into a general assistant. Before committing, open one notebook in a language-model track such as v3/alignment-training/lora/lora.ipynb and confirm that the TODO structure and the _SOLN file match how you actually study.

Official sources

1. Exorust/TorchLeet on GitHub
2. Issues
3. License: MIT
4. Project website
5. README