Study Program: From Zero to Research Scientist / MTS

24 weeks. Built on open primary sources: Stanford CS336, original papers and model technical reports. The topic list and priorities were cross-checked against public lecture notes and an analysis of 57 interviews by an OpenAI researcher (see Resources), plus skills that are missing there but come up in interviews and matter on the job.

Workload: the whole program takes 20–25 hours a week, about 520 hours over 24 weeks. The core of each week takes 10–14 hours: if you only have 10–15 hours a week, do the core and leave the depth for a second pass (the route is in the Program map). Keep the order of the weeks.

Before and after the core. Week 1 is preceded by the entry diagnostic and Module 0 (2–6 weeks, only if the diagnostic showed gaps). After week 22 comes an optional research Capstone of 4–6 weeks.

Every week ends with two blocks. Week outcomes: what you should be able to do. Self-check: 3 to 11 questions (depending on how many topics the week has) that you must answer out loud without peeking. A minute suits a short explanation; derivations and code need more time. On a first pass, the outcomes matching the Core line are required. Track questions and outcomes from Depth separately: they do not block the next step unless its core needs them.

How to tell whether you have learned it

In plain terms. Reading the softmax formula and recognizing it in a quiz is not enough. Take logits [0, 0] and get [0.5, 0.5], then add 1000 to both: the answer must stay the same. Write code, test this property and explain why a direct exp can fail. That is how theory becomes a skill.

For each topic, follow one cycle: small example → explanation in your own words → independent solution → check on another input → error analysis. Try without hints first; after an error, return to the explanation, then solve a similar problem with different numbers the next day.

A core week is complete when you have three kinds of evidence:

Understanding: explain the required idea, its assumptions and a case where it fails.
Action: produce the week's code, calculation or experiment. Tests pass, and you can explain which error each one detects. Add at least one example of your own with a known result.
Transfer: solve a small new variation without hints. For experiments, save the baseline, metric and failure analysis. A negative result is useful too.

Tutor scores help locate gaps but do not replace this evidence. If feedback contradicts a calculation or a primary source, recheck the example; do not memorize an answer just to earn a score. When stuck, revisit the specific prerequisite instead of rereading the whole week.

Stage	Useful result	Check and route back
Foundation	Small program using arrays, a derivative and a data split	F1–F6 exit checks; return to F2 for shapes or F5 for the chain rule
1–4	MLP, backward, optimizer and stable loss	Numerical gradient check, decreasing loss on a tiny example, large logits without NaN
5–10	Your own small language model	Tokenizer round-trip, no access to future tokens, held-out loss and generated samples
11–14	Correct, measured generation	Cached decoding matches a full pass; memory and time estimates compared with measurements on available hardware
15–18	Comparison of a model change with its baseline	Separate train/validation/test, equal budget, a metric with uncertainty; a small experiment is valid without a GPU
19–22	One meaningful architecture or product experiment	RNN/attention or BM25/RRF comparison, fixed data and error analysis; broad reading does not replace an experiment
23–24	Demonstration of skills and an account of your own work	New task variant, recorded explanation and rubric review; timing follows correctness

The stated hours are planning estimates, not a measured guarantee. If the core does not fit in one week, spread it over two; do not replace independent work with more links. Open an extra source to answer a specific question the main text did not resolve.

How a week works

Every week = 1 topic + 5 parallel tracks that run through the entire program.

Track	What	Per week
A. Theory	The week's topic: notes in your own words + deriving formulas on paper	6–8 h
B. ML code from scratch	1 implementation per week, no AI assistant	4–6 h
C. LeetCode	3 problems a week from the Track C list	3 h
D. Math	2 problems a week from Track D	2 h
E. Review	Explain and code the components already studied from memory	3 h

The iron rule: tracks B and E are written with AI completely turned off. Otherwise you will overestimate yourself by exactly as much as you lean on autocomplete.

Core and depth. Under each week's heading there is a line "Core: … · Depth: …" with a time estimate. The core is the topics of the ★ skills from the skill map, the week's main code and track E: without them you will not pass RS/MTS interviews. The depth can wait: the "optional" blocks, the sections of 05-ГЛУБИНА, track D and the second half of the track C problems. "≈ 11 h core / 21 h total" means that the core, together with track E and one or two track C problems, takes about 11 hours, and the whole week with all five tracks about 21.

Weekly ritual:

Mon–Thu: theory + code
Fri: track E, reproduce a component you have studied and explain its tests. Weeks 1–4: MLP, backward, optimizer and stable computations; 5–7: tokenizer, norms and attention. Start the full transformer in week 8. Correctness comes before speed.
Sat: LeetCode + math
Sun: retrospective. Anything you did not understand → goes on the gap list. 1 hour to close one gap.

Module 0

Module 0. Foundations before you startFor those who need the foundations before week 1: the entry diagnostic and six weeks, F1 to F6.

24 core weeks

Phase 1. Foundations

Phase 2. The modern transformer

Phase 3. Inference, GPUs, scaling

Phase 4. Post-training

Phase 5. Expansion

Phase 6. Interview mode

Progress metrics across the program

Track these every week:

[ ] Time to write a transformer from scratch (target: ≤25 min)
[ ] LeetCode problems solved (target: 72, that is, all of Track C)
[ ] Implementations from scratch (target: 24)
[ ] For key papers, record the hypothesis, test and limitation; reproduce at least one result. A paper count does not replace understanding.
[ ] Anki cards in active review
[ ] Mock interviews done

What this program leaves out on purpose

Classical ML (trees, SVMs) beyond the minimum: it rarely comes up in interviews for LLM roles. The minimum (logistic regression, k-means, PCA, a decision tree, metrics) is in Module 0, week F6
Deep optimization theory: the level of "I understand what is going on" is enough
Computer vision beyond what multimodality requires

Why do all this, besides the offer

The main argument for this kind of preparation is not that it helps you pass interviews. Systematically closing the gaps in your foundations has an effect that is worth more than the offer itself: your productivity in your current work goes up. Technical ideas appear that were simply out of reach before, and the range of problems you can think about at all gets wider. Where this conclusion comes from is explained in the "Program map".

Twenty-four weeks seems like too long to endure for the sake of a single interview. But if you count the fact that what changes at the end is the level at which you are able to work, the time frame looks different.