AI-Interview-Code: Hand-Written LLM Interview Problems in Jupyter Notebooks

What AI-Interview-Code Is Trying to Fix

LeetCode-style preparation trains a specific skill: recognizing a pattern and producing an algorithm under time pressure. It does not train writing a Self-Attention block from memory, sizing the KV cache for a decoder, or implementing Group-Query Attention after explaining how it differs from MHA and MQA. Those are the questions this repository collects. The README states the goal directly: these are hand-written interview problems for LLM and AI algorithms, explicitly not LeetCode, and in the author's framing they test broader ability while staying closer to business and fundamentals. The audience is narrow and identifiable. It is candidates interviewing for LLM or recommendation roles where the loop includes a whiteboard or shared-editor coding round on model internals, and it is interviewers who need a reference implementation to compare a candidate's answer against. The repository also carries a separate table titled, in Chinese, problems that are generally not asked, which contains LoRA. That split is itself informative: the author distinguishes between components an interviewer expects you to reproduce and components that are useful to understand but rarely demanded live.

The Problem Table Is the Actual Product

The repository's organising structure is a markdown table with four columns: problem, difficulty, knowledge point, written explanation and video explanation. Difficulty runs from two to five stars. Self-Attention, Multi-Head Self-Attention and Group-Query Attention are all rated three stars. The Transformer Decoder for causal language modeling is four stars. Computing the parameter count of a decoder model is three stars. Estimating training and inference memory for an LLM is four stars. AUC is two stars, and KMeans, linear regression, BPE tokenization, LayerNorm, BatchNorm and Softmax are all rated five stars. That last group is worth pausing on. A five-star rating for Softmax or LayerNorm signals that the difficulty rating reflects the awkwardness of writing the operation correctly under interview conditions, including numerical stability and the backward pass, rather than the conceptual depth of the operation. Reading the table as a study order would be a mistake; it is closer to a checklist of what a given interviewer might put in front of you.

Which Entries Actually Have Material Behind Them

This is the part a reader needs before investing time. The table's written-explanation column is populated for Self-Attention, Multi-Head Self-Attention, Group-Query Attention, Transformer Decoder and memory estimation. The remaining rows, including AUC, KMeans, linear regression, BPE, LayerNorm, BatchNorm, Softmax and decoder parameter counting, point to a literal TODO. Video links exist for more rows than written explanations do: Self-Attention, Multi-Head Self-Attention, Group-Query Attention, Transformer Decoder, parameter counting and LoRA all carry Bilibili and YouTube links, while AUC, KMeans, linear regression, BPE, LayerNorm, BatchNorm and Softmax have no video column entry at all. The practical consequence is that roughly half the advertised problem list is currently a title with no accompanying content. That is not a criticism of the author, who is publishing incrementally, but it does determine whether the repository is useful to you today. Check the row you need before cloning.

How the Attention Material Is Structured

The written explanations live on the author's blog, not inside the repository, and the table links out to them. The Self-Attention and Multi-Head Self-Attention entries both point to the same page, whose anchor targets a section the README labels, in Chinese, as the interview version with full comments. The GQA entry points to a page described as walking from MHA to MQA to GQA. This is a deliberate progression: the same attention mechanism is presented at increasing levels of production relevance, ending at the variant used in current decoder models to shrink the KV cache. The README characterises the Self-Attention write-up as covering four levels, and the anchor link suggests the last level is the one intended for interview reproduction. The repository itself is listed as Jupyter Notebook, and the LoRA entry links to a runnable notebook hosted on an external platform, which tells you the intended workflow: read the explanation, then type the implementation yourself in a notebook cell rather than reading a finished file.

Getting the Material and Running the Notebooks

There are no releases listed for this repository, so installation means cloning the default branch. The default branch is master. A standard clone is the only documented path: git clone https://github.com/bbruceyuan/AI-Interview-Code.git followed by cd AI-Interview-Code. The README does not document a requirements file, a Python version, a virtual environment step, a Makefile or any test command, so nothing beyond the clone can be verified from the supplied material. For the LoRA notebook specifically, the table links to an externally hosted runnable notebook rather than a local path, which means the environment for that one is provided by the hosting platform, not by this repository. If you want to run any notebook locally you will have to determine the dependencies yourself from the imports, because the repository does not state them. That absence is the single biggest friction point for a reader who wants to execute rather than read.

Where This Repository Falls Short

The TODO rows are the obvious limitation, but there is a second one that matters more for interview preparation: there is no test suite, no expected output and no grading rubric anywhere in the material described. A candidate who writes a Self-Attention implementation has no way to check it against a reference within this repository. The blog posts may contain reference code, but that lives outside the repository and is linked, not vendored. There is also no stated target framework version. Attention implementations differ between PyTorch versions in small but interview-relevant ways, and nothing in the README pins a version. Finally, the video links point to Bilibili and YouTube, which is fine for a Chinese-speaking audience and less convenient for others; the written blog posts are the more portable resource, and they are in Chinese. If you need English-language explanations of these same components, this repository will not serve you without translation.

How It Compares to Practising on LeetCode or Reading a Model Repository

The realistic alternatives are different in kind rather than better or worse. LeetCode gives you a judge: you submit, it runs hidden tests, and you get a pass or fail. That feedback loop is exactly what this repository lacks, and for algorithm-pattern practice it remains the stronger tool. Reading a production model repository, for example a published implementation of a decoder-only architecture, gives you correct, optimised, battle-tested code, but it does not tell you what an interviewer will ask you to reproduce from memory, and production code is often written for throughput rather than for clarity. This repository sits between the two: it tells you which components are asked about and at what difficulty, and it points to explanations aimed at the interview version rather than the production version. The trade-off is that you lose the judge and you lose the guarantee that every listed problem has an answer behind it.

Licence and Maintenance Expectations

The repository is Apache-2.0. That permits commercial and private use, modification and redistribution, with the usual conditions around preserving notices and stating changes, and it includes a patent grant. This is not legal advice; read the licence text if you plan to reuse the material inside a company's internal interview bank. On maintenance, the last push recorded is 2026-05-04, and the repository is not archived. The README's own TODO markers are the clearest signal about direction: the author is filling in the table over time, and the blog is described as the place where content appears first, with the repository following. That ordering means the repository can lag the blog. If you are tracking a specific problem, the blog index at yuanchaofa.com/hands-on-code/ is the more current surface, and the repository is the index of what exists. Treat the two as one resource rather than assuming the repository is self-contained.

Editorial conclusion

Adopt this if you are preparing for or running interviews that ask candidates to write Self-Attention, GQA or a causal Transformer decoder from scratch, and you want a worked reference rather than a blank editor. Skip it if you need a graded exercise bank with solutions for every topic: seven of the thirteen listed problems are still TODO, and the repository is a set of notebooks and blog links, not a test harness. Before relying on it, open the notebook for the specific problem you care about and check whether the text write-up exists, since the table links some entries to a blog post and others to nothing.

Official sources

1. bbruceyuan/AI-Interview-Code on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README