On your first visit, the project route can help you choose a starting point. For a design interview, skip straight to system-design practice; you don't have to build every project first.
Once you can call a model, other questions tend to follow. Where does its data come from? Which computations can run ahead of time? When the result is wrong, did the model fail, or did something go wrong earlier?
If you haven't built a complete small app, start with this site and a reading list. Follow a Markdown edit into a published page, then connect a browser, API, and database. No GPU or frontend framework is required.
The other routes cover recommendation, a RAG knowledge assistant, and post-training experiments. The recommender series draws on public code; the other two use small original projects. Follow the data through a system, then change one condition and see what breaks. Read the explanations first if you prefer; the code is there when you're ready.
Engineering practice includes more than system design. You can start from requirements and propose a design, or follow an existing project through data, components, training, serving, and evaluation. The first develops judgment; the second checks that judgment against an implementation.
Pick a question
| What do you want to understand? | Start here | What to look for |
|---|---|---|
| You know models but not the surrounding product | An ML system end to end | Three timelines, data and service contracts, acceptance, and ownership |
| You've written code but haven't connected a page, server, and automated checks | Build something small | Static hosting, CI/CD, requests, persistence, and useful errors |
| You have requirements but no starting design | System-design exercises | Goals and constraints, then components, cost, and failure handling |
| Useful content wasn't recommended | Inside recommender systems | Missing retrieval, filtering, or a low rank |
| Documents were retrieved, but the answer is wrong | A RAG knowledge assistant | Whether evidence was current, reached the model, and was used correctly |
| Loss fell, but task performance didn't improve | Post-training experiments | A mismatched training objective or gaps in evaluation |
Recommendation, RAG, and post-training all involve data, cost, and evaluation, but the checks differ. No click doesn't necessarily mean dislike in recommendation; missing evidence prevents a knowledge assistant from confidently supporting an answer. Keep those differences in mind as you read.
System design: make the choices yourself
For the overall map, start with data to users: content updates, model training, and live requests are separate paths. Follow data to model through examples, frameworks, checkpoints, and indexes, then serving and feedback. You need not implement every layer, but should understand what each hands over.
Choose a feed, RAG assistant, or long-term memory system. Write down requirements, data scale, and latency budgets. Sketch a minimal design, then change a condition: more frequent updates, a permission change, or a service timeout. What needs to change in your design?
Then read the projects below and see how implementations handle these issues. The exercises have no single standard answer, and a public project's choices depend on its context; neither should be copied unquestioningly.
Recommendation: follow one feed refresh
Begin with 00 · Architecture to separate requests, content updates, and training. Then follow 01 · Requests → 02 · Retrieval → 03 · Ranking → 05 · Evaluation.
Once the flow makes sense, ask why it uses two towers, how to choose components, and how to handle serving failures. Then read newer public architectures and identify which stage a new model changes.
The examples go beyond boxes: allocating slots between sources, handling missing labels, and explaining why an aggregate can rise while every group stays unchanged.
RAG: from finding documents to answering correctly
An event's registration deadline changes from Friday to Wednesday. How does the assistant pick up the change? Data and retrieval handles revisions and access, combines retrieval results, then selects passages within a context limit.
Evidence and evaluation checks the answer itself. A real citation can accompany a misread date. We change dates, remove supporting sentences, and introduce conflicting documents to explain how to test each failure.
Post-training: check what the model is learning
Keep the same assistant: the evidence is correct, but citations are often missing. Data and objectives starts with demonstrations, then checks which tokens contribute to loss, how much weight longer answers receive, and whether related examples have leaked into the test set.
The route also covers the engineering decisions between data and results: SFT, LoRA and framework selection, batch construction, multi-GPU choices, and recovery. Each explains when a tool is needed, its cost, and how to check that it has not changed the intended objective.
Experiments and release compares old and new models on six questions. One more correct answer overall can hide an extra unsupported answer. Inspect the changes before deciding to revise, scale the experiment, or keep the old model.
Run the small examples
Once a model is trained, other people need to use it reliably. A request through the service connects inference mechanics to system design: queueing, long-prompt chunks, cancellation, and the choice between replicas and model partitioning. Use that flow to plan a representative load test rather than starting with a supposedly fastest framework.
From the repository root, without a GPU or API key:
python3 practice/rag/code/evidence_pipeline.py
python3 practice/post-training/code/experiment_checks.py
python3 practice/post-training/code/training_contracts.py
These programs verify small examples and contracts; they are not full-model training or deployment reports. For underlying ideas, return to Foundations. For individual functions, ML questions, or algorithms, use Interview preparation.
Join us!
Share where you got stuck, what you tried, and how you found the cause. An experiment that didn't work as expected can still help someone else. See the contribution guide for how to join in.
This section uses public code, papers, and synthetic data. Public-project behavior, original teaching designs, and actual measurements are distinguished; internal company projects and private datasets stay out.