Find your starting point

Pick what you'd like to do next: understand a model, practice for an interview, read research, build something, study one topic, or get ready to apply.

Each route has a starting point and somewhere you can stop for now. Skip what you know and fill in gaps as needed. These notes are closest to ML / LLM learning and MLE / research preparation, not a universal interview syllabus.

Getting started: follow one computation

A little Python is enough to begin. If vectors and gradients are unfamiliar, start with linear models and neural networks. You don't need to finish all the math first.

1. Tokenization: how a sentence becomes model input.
2. Transformer walkthrough: follow a short input through attention, FFNs, and residual connections.
3. Training basics: how a prediction error becomes a parameter update.

A useful stopping point: explain the input, prediction, loss, and update for a short sentence. You don't need every matrix equation memorized. To check your understanding in code, try the PyTorch exercises. Model families, MoE, and distributed training can wait.

Interviews: find the part that needs practice

In Interview prep, pick the area you need. With a background, go straight to the quick review; to build up step by step, use the study plan. The first narrows the scope; the second follows the prerequisites. Both let you start with what you know. Suggested hour budgets are not deadlines.

Start with the job description and any interview information you've received. Two MLE roles may emphasize quite different things. For what to practice first by role, and what to leave when time is short, see the role-based guide. Without a particular interview coming up, try one concept question and one small implementation to see where you get stuck.

1. Hard to explain the idea? Use the ML / LLM questions. Answer without notes, then explain with an example.
2. Understand it but can't implement it? Try ML coding. Check shapes, masks, gradients, and boundary cases.
3. Slow to code or unsure how to approach a problem? Start with Python and algorithm patterns. Practice methods rather than memorizing problem numbers.

A useful stopping point: solve a small problem independently, explain your choices, and test a different input. Add Feed / RAG / Memory design when you need system design, and project preparation for project discussions. One interview isn't a reason to complete every route at once.

Research: work out what actually changed

This route is for readers who know roughly how a Transformer works and want to read model reports or discuss a research project. Research Scientist and Research Engineer requirements vary by team. This is practice in reading and discussing work, not a promise of meeting a role's requirements.

1. Architecture components: identify the component a paper changes, then fill in unfamiliar mechanisms.
2. Model families: compare designs using the same questions rather than collecting version names.
3. Evaluation basics: examine baselines, data, metrics, and ablations to decide what the results support.

A useful stopping point: write one page describing the problem, method, evidence, and something you still aren't sure about. Recalculate an example where possible. If you can't reproduce the full model, state which part you checked. For post-training research, connect the principles to experiment design; you don't need to read every model family first.

Projects: get one path working first

If you haven't built a complete application, start with this site and a reading-list app. No GPU is needed: learn the build and CI/CD process, then connect a page, an API, and a database.

Already comfortable writing programs? Pick the project you want to explore:

• Recommendation: follow a request through retrieval, ranking, filtering, and evaluation.
• A RAG knowledge base: connect document versions and permissions to retrieval, citations, and answer checks.
• Post-training experiments: start with an error to fix, then choose SFT, construct batches, consider multiple GPUs, restore checkpoints, and decide whether to release.

A useful stopping point: run a minimal example, change one condition, and explain the effect. Remove a supporting document, for example, or interrupt and resume training. For a design interview, try a system-design problem first, then use the implementations to challenge your proposal.

Only interested in one topic? Start there

You don't need to follow the routes above first. These are topic entrances, each with its own reading order—not a required syllabus.

For a particular term, use the search button at the top or press /. Try either the Chinese concept or the English term.

Job-search preparation: decide what to work on next

1. What to prepare: allocate effort around the role and your own gaps.
2. An interview retrospective: record specific problems after an interview, then adjust your preparation.

A useful stopping point: pick a near-term goal, identify the gap that matters most, and plan one concrete exercise. For my experience, see the 25–26 internship search and 26–27 new-grad search. They're accounts of a search, not a schedule you need to match.

See the full collection, or come back later

Pick an area for what you need: Foundations explains mechanisms, Interview prep has review and practice, Engineering practice breaks down systems, Tech history follows how the field developed, and Career covers experiences and decisions. A note lives in one place; routes link to it rather than duplicating it.

Use 中文 / EN at the top to switch the same note. Save a note with Save this page under its title, then find it, along with recently opened pages, under My reading. Records stay in this browser; export a backup under Settings before moving devices. The collection is still growing. Coverage and backlog distinguishes what is written from what still needs checking.