Software Developer → ML / Applied AI Engineer

Overall strategy

Do not restart your career. Build on your software engineering experience and add ML, PyTorch, modern AI application development, and production ML skills.

10 hrs/weekKeep current jobBuild while learning3 serious projects3 buffer weeks + 3 extension weeks~410 hrs — ~345 learning + building, ~40 DSA, ~25 system design

Before the roadmap — a fundamentals gate

Duration: up to two four-week rounds at two hours a week; a 60-minute check opens week one

The roadmap is paused. Before any of it runs, check your backend fundamentals on an app you already have, and spend a small, fixed budget on the highest-priority gap the check finds.

Why this comes first: the roadmap serves an ML career transition. Its SQL week teaches analysis queries, not transactions, constraints or query diagnosis; its DSA hour is Python fluency for future screens; and its timeout, retry and monitoring material never asks you to diagnose an existing application on your own. Those are the fundamentals your day-to-day backend work runs on, and slowing the whole roadmap down would not add them.

Before you start — ten minutes

Choose the app. Get access to a test or local database — with realistic row counts if you can: seeded, or a restored copy if you are allowed to hold that data locally. Fix a weekly two-hour slot, and put the week-four checkpoint in your calendar.

The check — 60 minutes, on the chosen app

Documentation allowed; the first attempt without AI-written solutions. If the app is your employer's code, any later attempt with AI follows the data boundary in Stage 0.

Backups — evidence, not history: when was the last successful restore of this database, by anyone, and what was checked afterwards? If there is no restore evidence that matches the current setup and recovery is your responsibility, schedule a restore into a separate environment — never over the live database — in work hours if the system is your employer's, otherwise inside your weekly budget. This stays on your list even if the check lets you skip the gate: it is reliability work, not study.

Reading the results

• Correct, with checks that work: not the first thing to fix. Move on.
• You know the concept but cannot apply it: a practice gap. Its round goes on small exercises with changed inputs.
• You cannot explain why something works, or how you would investigate a failure: a learning gap. Its round goes on learning the concept first, then the same exercises.
• Untested — the setup was not available (no test data, no database access): not a gap. Fix the setup inside the budget and run that part again. If it cannot be set up by the end of week one, close that area for this gate and write down why.

If all three ran and none shows a gap, skip the gate and make the restart decision now.

Rules

• One area per four-week round, in priority order: database, debugging, data structures. Practice and learning gaps both get a round. Debugging ranks above data structures because timeouts and retries against external APIs come up in your apps more often than data-structure choices.
• At week four, try a new variation of the area without a worked solution. If you can explain it and your check passes, that specific gap no longer needs focused practice — one query or loop does not prove the whole area. If a second round is needed, it goes to the highest-priority gap still open, including one whose variation failed.
• The gate ends after two rounds — eight weeks — at most. Then make the restart decision, and practise any remaining gap through normal work, for example by pairing with a colleague on the next related ticket.
• Infrastructure choices (hosting provider, database service, server sizing): no study now. When a real decision comes up, write down expected traffic and concurrency, acceptable downtime and data loss, operating effort, and cost first — then compare only the options that fit.

First step: once the setup is done, pick one order-related query and check whether a join can inflate its totals.

Stage 0 — Set yourself up

Duration: Week 0

The goal is to make sure you can spend the next several months building without environment problems slowing you down — and to gather the two pieces of information you will need much later, while gathering them is still cheap.

This week is full: ten hours covers the market scan, the installs, the compute and hosting decisions, and the three learn-tests. If installs go badly, the scan and the learn-tests are the parts to protect. Everything else here can be finished in Week 1.

Scan your actual market first

Ninety minutes, before you install anything. Pull 20 real job postings from the market you can actually work in — your city, your country, or remote roles that hire from it — across the titles listed in the job-search block. For each, note the title, the modelling depth asked for, whether cloud, Kubernetes, or an orchestrator appears, whether they want RAG and evaluation or classical ML, and the education line — including whether it says "or equivalent experience." That last phrase is common, and counting how often it appears in your market tells you far more than any general claim about whether degrees matter.

You are not choosing your specialism today. The Applied AI and MLE tracks in this plan are nearly identical until Week 22, so committing now would mean deciding with the least information you will ever have. You are building the evidence for the decision in Week 16, once you have shipped Project #1 and know what you actually enjoy. Save the file; you will re-read it then.

Install and configure

Learn-tests: take them now, expect to fail most of them

The previous version of this plan called these skip-tests and let an experienced developer bank the hours. You are not that developer yet, and the plan no longer assumes you are. Take all three tests in Week 0 anyway — in one sitting, no reference open — and record the result in a file. A fail is not a verdict; it is the schedule telling you which extension week you will use. The artifact for each test is unchanged; what changed is that hours are budgeted to reach it rather than assumed to be saved by it.

If you pass one, that is how an extension week disappears. Pass Python and SQL and Week 4b is skipped. Pass FastAPI + Docker and Week 10b shrinks to a Stage 2 catch-up you can drop if you are on schedule. There is no CI test: Week 31 teaches CI from scratch and nothing in the schedule depends on whether you already know it. Nothing gets banked to Week 22, 27 or Project #3 — the extension weeks are the honest replacement for a cushion.

Decide your compute and cost plan now

Week 21 fine-tunes a pretrained vision model, Week 15 puts Project #1 at a public URL, and Stage 4 calls paid LLM APIs. All three fail late and expensively if you have not decided where they run. Settle this in Week 0, not in Week 15 or 21.

The book is already mapped

Pre-write your cut-list

Three buffer weeks across 41 is roughly 7% slack — thin for nine months alongside a full-time job. The buffers will absorb a bad fortnight; they will not absorb a bad quarter. So decide now, while you are rested and nothing has gone wrong, what gets sacrificed when something does. The extension weeks (4b, 10b, 19b) are not buffers — they are instruction time you have already been told you need. Do not spend them on catch-up and then arrive at Week 16 with both gone.

The rule: if you reach a buffer week already behind, cut from this list rather than extend the schedule. Breadth goes before project quality — the earlier cuts sit in the weeks where a junior candidate is least likely to be interviewed on the detail. In order:

1. Week 11 clustering — read for awareness, build nothing.
2. Week 9 tree internals — Gini versus entropy is not worth a week of slippage; you will still train and tune trees.
3. Week 10 beyond Random Forest and Gradient Boosting — AdaBoost, Extra Trees, stacking to awareness only.
4. Week 3 confidence intervals and sampling theory — know the vocabulary, move on. Later than before, because a rusty statistics base costs you more in Stage 2 than it costs an experienced developer.
5. Week 21 computer vision — only once you have committed to the text path for Project #2.
6. System design drops to a fortnightly concept-only session — never to zero, and never in Weeks 28–33 where the Project #3 presentations live. Recovered as soon as you are back on schedule.

Suggested learning repository

ml-transition/
├── python/
├── numpy/
├── pandas/
├── sql/
├── math/
├── sklearn/
├── pytorch/
├── notebooks/
└── projects/

Materials and resources

This section is the finished version of the Week 0 mapping task. The edition is confirmed, the chapters are assigned, and every week the book does not cover has a named primary source.

The book — edition confirmed

The copy in this folder is the PyTorch edition: 19 chapters plus two appendices (Autodiff; Mixed Precision and Quantization). Chapter 10 is Building Neural Networks with PyTorch and Chapter 15 is Transformers for Natural Language Processing and Chatbots. Stage 3 therefore works exactly as written and you need no substitute PyTorch book — only the official tutorials as a reference.

Chapter map

Chapters 16–19 (vision/multimodal transformers, speeding up transformers, autoencoders and diffusion, reinforcement learning) are the optional tail the plan already flags. Appendix A is worth thirty minutes in Week 18 if autograd does not click.

Weeks the book does not cover

One primary source each. All are first-party or long-stable, and none of them costs anything to read.

Data structures and algorithms — fluency now, the rebuild later

NeetCode 150 (neetcode.io), solved on LeetCode, in Python. These are not alternatives — NeetCode is the curriculum, LeetCode is the platform. Python because it doubles as your ML language, and because as a Go/JS/C++ developer you need the reps in the language you will actually be screened in.

One hour per week, every week from Week 1 to Week 37 — the Tuesday slot. It never pauses inside the roadmap, including project and extension weeks — only the fundamentals gate, which sits outside the 41 weeks, stops it. The purpose during the roadmap is Python fluency: the idioms (dict/set/Counter, slicing, comprehensions, sorting with keys) that ML code leans on, kept warm by one new problem and one re-solve a week. It is not a screen-readiness track, and it is not pretending to be one.

The full rebuild — 2.5 hours a week, graphs and 1-D DP included, timed sets — is deferred to the job-search block, where it runs for the 12 weeks before a search date. The reason is decay: coding-screen pattern recognition is the fastest-decaying skill in this plan, so 80 hours of it a year before any screen would need to be re-done anyway. Doing the reps close to the date is the cheaper path.

What the fluency hour buys you, honestly: roughly one new problem and one re-solve a week, so about 35 problems logged by Week 37, in this order:

Heap, backtracking, graphs, and 1-D DP are not skipped — they are the rebuild block's material, where they get the 2.5 hours a week they need. Skip tries and 2-D DP unless your market scan says otherwise.

Timebox every problem to 25 minutes, then read the solution, understand it, and re-solve it from scratch a few days later. You are acquiring pattern recognition, not proving anything. Keep a log at dsa/solved.md in your learning repo — problem, date, solved-within-timebox yes/no, and the dates of each re-solve. It is the checkpoint artifact and the only honest measure of whether the track is working.

System design — a lightweight but real track

You have never designed a system, and "practise system design" was a one-line mention. From Week 6 to Week 33 it is the Wednesday hour, every week except project weeks (Week 33 keeps its session) and Week 22: one concept, then one small practice design done by you alone — 35 minutes on paper or a whiteboard, phone photo, requirements → estimates → API → data model → high-level components → one deep-dive → bottlenecks. Only then open an AI and paste the photo with this instruction: "You are the interviewer. Ask me the follow-up questions a senior engineer would ask about this design, one at a time. Do not propose a design. At the end, list what I missed." Note the questions you could not answer in system-design/wNN.md and commit it. If the model ever starts designing for you, the session is void — the skill being trained is defending your own diagram under pressure.

The RAG pipeline is your best design material. Nobody else will have built, measured, and hardened the system they are describing; a URL shortener is table stakes, Project #3 is a differentiator. That is why three of the sessions are spent presenting it, and why the third one is recorded — it doubles as the architecture segment of your final walkthrough. The recorded cold walkthroughs of the canonical designs are interview rehearsal, and they now live in the job-search block. The concept track stays here because it is engineering knowledge, not rehearsal, and it does not decay the way problem reps do.

The Week 26 session uses developer.mozilla.org on Server-Sent Events as its source, because LLM token streaming is SSE and it is the one networking topic that is genuinely load-bearing here.

Stage 1 — Foundations

Duration: Weeks 1–4, plus extension Week 4b

Do not spend months preparing before touching ML. Four focused weeks and one consolidation week are enough to start. The DSA fluency hour begins this week too — see the routine; the Tuesday slot is already spoken for.

Week 1 — Python for data work

Learn — not review — lists, dicts, sets, tuples, comprehensions, functions, lambdas, classes, exceptions, context managers, iterators, generators, decorators, modules, packages, and type hints. Your Go, JS and C++ give you the concepts; the week is about the Python spelling of them, and about the idioms (comprehensions, unpacking, enumerate/zip, slicing) that ML code and NeetCode solutions both lean on. This is a learn-test week: the artifact is the Week 0 Python test, rebuilt at the end of the week without notes.

Your target is not clever Python. Your target is being able to read ML code without the language itself slowing you down.

Week 2 — NumPy + Pandas + SQL

Practice on a CSV dataset. Explore missing values, distributions, correlations, outliers, and target balance before training any model. Then load the same dataset into a database and reproduce three of those analyses in SQL.

Week 3 — Statistics

Learn mean, median, variance, standard deviation, percentiles, correlation, probability, conditional probability, independence, random variables, normal distributions, expected value, sampling, population vs sample, bias, variance, confidence intervals, and noise.

Week 4 — Linear algebra + calculus

Focus on scalar, vector, matrix, tensor, vector addition, dot product, matrix multiplication, transpose, dimensions, functions, slope, derivative, partial derivative, gradient, and chain-rule intuition.

prediction
   ↓
calculate loss
   ↓
calculate gradient
   ↓
adjust parameters
   ↓
repeat

Stage 1 mini-project

load data
↓
clean data
↓
basic statistics
↓
plots
↓
written conclusions

Stage 1.5 — Early win: ship a small AI demo

Duration: Week 5

This week is out of sequence on purpose, and it is the most important structural change in the plan.

Your leverage as a working software engineer is application engineering, not model research. That skill needs no ML theory at all — you can call an LLM API and wire up retrieval with the Python you already have. Building it now, before you have "earned" it, gives you three things you would otherwise not have until Month 8:

• Something concrete to show and talk about, months before the flagship project exists.
• A real reason to care about the abstract material in Stages 2 and 3 — you will have already felt the problems that evaluation and retrieval quality solve.
• Proof to yourself that the transition is achievable, at the point in the roadmap where motivation is most fragile.

Scope it aggressively

Nine hours — the whole week, not one weekend. Your routine gives you five hours across Saturday and Sunday; the other four come from the weekday slots, spent reading provider documentation so the weekend is pure building. Load a folder of documents, chunk them naively, embed them, store them in the simplest vector store you can find, and answer questions over them from a command line. No auth, no database, no UI, no tests, no Docker.

your documents
   ↓
naive chunking
   ↓
embeddings
   ↓
simple vector store
   ↓
question → retrieve → LLM → answer

It will be mediocre. That is the point — Weeks 27 and 30 exist to teach you exactly why, and in Week 27 you will fork this repository into Project #3 and rebuild it properly.

Stage 2 — Classical Machine Learning

Duration: Weeks 6–16

This is the core Scikit-Learn stage and the first major section of Géron’s book.

Week 6 — ML landscape + end-to-end workflow

Study supervised vs unsupervised learning, batch vs online learning, overfitting, underfitting, generalization, hyperparameters, validation, and test sets.

Problem
 ↓
Data
 ↓
Quick structural look — shape, dtypes, target balance
 ↓
Choose split strategy → reserve the test set
 ↓
Detailed EDA — training data only
 ↓
Preprocessing
 ↓
Baseline
 ↓
Train models
 ↓
Cross-validation
 ↓
Tune
 ↓
Evaluate on the test set — once
 ↓
Deploy
 ↓
Monitor

Week 7 — Classification

Learn binary and multiclass classification, confusion matrices, accuracy, precision, recall, F1, ROC, AUC, PR-AUC, calibration, and decision thresholds.

Change the decision threshold on a small classifier and observe what happens to precision, recall, and F1.

Week 8 — How models learn

Study linear regression, gradient descent, SGD, polynomial regression, regularization, Ridge, Lasso, Logistic Regression, and learning curves.

Implement a tiny linear regression model once without Scikit-Learn to understand prediction, loss, and optimization. This is the week that pays for the Week 4b chain-rule hours. Then fit a polynomial model to the same data and plot its learning curves against the linear one — that pair of plots is the clearest picture of over- and underfitting you will see all year.

Week 9 — Decision Trees

Study splits, Gini impurity, entropy, depth, overfitting, and regularization. Train trees with different maximum depths and visualize the behavior.

Week 10 — Ensembles

Learn bagging, Random Forests, Gradient Boosting, Histogram Gradient Boosting, and feature importance. Run Extra Trees, AdaBoost, and a simple stacking ensemble once each on the same data so you have seen them behave — they are the first thing on the cut-list after clustering if you slip.

Compare Logistic Regression, Decision Tree, Random Forest, and Gradient Boosting on the same problem. Extra comparisons beyond those four are stretch work, here and in Project #1.

Week 11 — Dimensionality reduction + clustering

Learn PCA, the curse of dimensionality, and K-Means. These two carry almost all of the interview and practical weight in this area. Clustering is one small exercise — cluster something, look at the clusters, write three sentences about whether they mean anything — not a week of it.

Week 12 — Serving: FastAPI + Docker

Moved forward from Stage 5, because Project #1 requires it. Wrap a trained Scikit-Learn model in a FastAPI endpoint with a request/response schema, containerize it, and run the container locally. Keep it minimal — no auth, no database. This is a learn-test week: retake the Week 0 FastAPI + Docker test at the end of it. The Wednesday design session presents this same endpoint as a design answer — you will be asked about it in exactly that form.

Week 13 — Experiment tracking

Track model versions, dataset versions, hyperparameters, metrics, artifacts, and code versions. Use a tool such as MLflow or an equivalent. You want this habit in place before Project #1, not after, so the project produces a real experiment log instead of a folder of forgotten notebook runs. Local SQLite as the tracking backend and local files for artifacts — MLflow's model registry needs a database-backed store, and a file-only setup does not support it — then register one model version and load it back by name. No remote service. The habit is the point; the infrastructure is not.

Weeks 14–15 — Project #1

Choose a structured-data problem such as customer churn, loan default, employee attrition, fraud detection, house prices, insurance claims, or customer conversion.

Mandatory, in this order: data loaded and split, baseline recorded, one trained model compared against it with the result explained either way, honest evaluation on the held-out set exactly once, the FastAPI endpoint from Week 12, a Dockerfile, a README. Stretch, and only once all of that runs: comparison across four algorithms, hyperparameter tuning, feature-importance analysis, calibration plots. A finished small project beats an unfinished thorough one, and the Week 16 buffer is not a licence to start stretch goals in Week 15.

project/
├── data/
├── notebooks/
│   └── exploration.ipynb
├── src/
│   ├── preprocessing.py
│   ├── train.py
│   ├── evaluate.py
│   └── predict.py
├── tests/
├── models/
├── api/
│   └── main.py
├── Dockerfile
├── requirements.txt
└── README.md

Your README should explain the problem, dataset, metric choice, experiments, final result, failure modes, and how to run/deploy the project.

Stage 3 — Deep Learning + PyTorch

Duration: Weeks 17–25, plus extension Week 19b

Week 17 — Neural network fundamentals

Learn neurons, layers, inputs, weights, biases, activation functions, forward pass, loss, backpropagation, epochs, batch size, and learning rate.

Week 18 — PyTorch fundamentals

Learn tensors, nn.Module, autograd, Dataset/DataLoader, model saving/loading, and basic optimization.

for X, y in loader:
    optimizer.zero_grad()
    prediction = model(X)
    loss = criterion(prediction, y)
    loss.backward()
    optimizer.step()

Week 19 — Build small neural networks yourself

Implement a regression neural network, a binary classifier, and a multiclass classifier. Track training loss, validation loss, and useful metrics.

Week 20 — Training deep networks

Study vanishing gradients, initialization, ReLU, normalization, gradient clipping, Adam/AdamW, learning-rate scheduling, dropout, weight decay, and transfer learning. Learn two learning-rate schedules properly (OneCycle and cosine) and compare them on one of your Week 19 networks; then do one small transfer-learning exercise — freeze a pretrained backbone, train a new head — so that Week 21 or Week 23 is the second time you have done it, not the first.

Week 21 — Computer vision

Learn CNNs, convolution, kernels/filters, pooling, feature maps, ResNet, and transfer learning. Fine-tune a pretrained vision model on a small dataset — this is the week your Week 0 GPU decision pays off.

If you chose Applied AI in Week 16, this week is optional. Skim it for vocabulary, take the text path in Weeks 23–24 where you will fine-tune a transformer instead, and move the recovered hours to Week 22 or Week 27. Keep the Wednesday design session either way — an online prediction service is your material regardless of path. If you chose MLE, keep the week in full.

Week 22 — Attention + Transformers

Go deep on (about 6 hours): tokenization, embeddings, attention, and Transformer architecture. Attention is the one idea in this week that interviewers actually probe, and it is the foundation of everything in Stage 4.

Working familiarity only (about 2 hours): load and run a pretrained model through Hugging Face, and know the BERT vs GPT-style distinction. In-context learning and instruction tuning are read, not practised — you will live them from Week 26 onward. You will use all of these constantly in Stage 4 without needing to have trained one.

The remaining hour is the Wednesday slot, given up by the design track this week: choose the Project #2 dataset and target metric, check the licence, and write the baseline down. That is nine hours plus the DSA hour — the week is exactly full. If something has to give, it is the two familiarity hours, not the attention hours.

Weeks 23–24 — Project #2

Two weeks, not one — and never collapsed to one. Build either an image classifier or text classifier with PyTorch. Include a Dataset/DataLoader, training loop, evaluation, experiment tracking, inference API, and an error-analysis section.

The dataset and target metric were chosen in Week 22. Separate mandatory from stretch: a working training loop, honest evaluation, and the error analysis are mandatory; architecture comparisons and hyperparameter sweeps are not. The same reproducibility rules apply — one command, pinned versions, fixed seeds, data provenance, stated limitations.

If you choose the text path, fine-tune a small pretrained transformer rather than training from scratch — this is the fine-tuning exercise deferred from Week 22, and it belongs here where the hours exist.

The error analysis is the part that distinguishes you from a tutorial follower. Look at the examples your model gets wrong, categorize the failures, and write down what you would do next. It is the deliverable that survives every cut.

Stage 4 — Applied AI / LLM Engineering

Duration: Weeks 26–30

You built a naive version of this in Week 5. Now you learn why it was mediocre. The routine does not change here — the same ten hours, the same slots.

Week 26 — LLM APIs

Learn system/user messages, context windows, tokens, temperature, structured outputs, streaming, rate limits, retries, timeouts, caching, and cost modelling. The Wednesday design session is Server-Sent Events and a streaming endpoint — LLM token streaming is SSE, and it is the one networking topic that is load-bearing here.

Caching earns a mention of its own because it decides whether the evaluation suite you are about to build is something you can afford to run on every commit or something you run twice and quietly abandon. Work out the per-run cost of that suite now, and know which lever brings it down — prompt caching, response caching, or a smaller model for iteration.

Week 27 — Embeddings + vector search

Learn embeddings, vector similarity, cosine similarity, semantic search, chunking strategies, vector storage, and reranking.

Reranking is the cheapest large win available in retrieval, so it belongs here rather than nowhere: retrieve generously with vector search, then reorder the candidates with a stronger cross-encoder or model-based scorer before anything reaches the LLM. Measure the difference — it doubles as the clearest proof that your evaluation set actually works. If reranking does not beat the baseline on your documents, that is the result you report; a measured "no improvement" is worth more than an assumed one.

Project #3 starts this week. Fork your tagged v0 demo into a new repository and leave v0 untouched. Everything below lands in the fork.

Week 28 — RAG

Assemble the full pipeline in the Project #3 repository, running the development set as you go. Answer quality now rests on retrieval quality, and you already have numbers for the second.

Then present it. This week's system-design session is Project #3 as a design answer, session 1 — draw the pipeline you just built, alone, then let the AI interviewer attack it (freshness, latency, cost per query, what happens at ten times the documents, what happens when a chunk contains instructions). Write down the questions you could not answer; several of them are Week 29 and Week 30's to-do list.

Documents
   ↓
Parser
   ↓
Chunks
   ↓
Embeddings
   ↓
Vector DB

User question
   ↓
Embed question
   ↓
Retrieve chunks
   ↓
LLM
   ↓
Answer + sources

Week 29 — Tool calling, and the failure modes that matter

Learn tool/function calling, workflow state, retries, tool failures, timeouts, structured-output failures, and human approval boundaries.

Weight this week toward security and failure handling rather than agent frameworks. Spend roughly half of it on prompt injection, untrusted retrieved content, and data leakage. That is not a detour: your system reads documents and hands them to a model that can call tools, so a hostile instruction hidden in a retrieved chunk is precisely the shape of the threat. "What happens if one of your documents tells the assistant to ignore its instructions?" is a question an interviewer can ask about the system you actually built. Generic multi-agent orchestration is not.

Week 30 — Evaluation

Expand the Week 27 development set into a real evaluation suite: cover the failure cases you have hit since, and add cases that exercise both the tool and the injection attempts from Week 29. Track Recall@k and MRR for retrieval, citation correctness (do the cited passages actually support the answer?), faithfulness and hallucination rate, abstention (does it say "not in these documents" when it should, and only then?), task success, tool success, latency, and cost per query.

Grade answers against a written rubric, committed next to the questions: what counts as correct, partially correct, and wrong for each, so that a model-graded score means the same thing next month. Run the grader at temperature zero and pin the model version; then run the whole suite three times on the same commit and record the spread. Three runs give you the observed run-to-run variation — an initial estimate, not a floor. An improvement smaller than that spread is not yet demonstrated, and it is the number that decides how loose Week 31's CI threshold has to start.

Make it runnable as a single command that prints a table of scores. That command is what turns Project #3 from a demo into something you can defend — and it is what Week 31's CI will run.

System-design session 2 on Project #3 happens this week, after the held-out run: the same presentation as Week 28, but now every claim has a number behind it. "How do you know it is good?" is the question most people cannot answer about their own project. You can.

Stage 5 — Production ML + flagship project

Duration: Weeks 31–37

Production skills come before the hardening weeks, so Project #3 can actually apply them instead of promising them. The system itself already exists — you have been building it since Week 27.

Week 31 — CI/CD + ML testing

Test data schemas, preprocessing, model loading, prediction shapes, feature ranges, API behavior, and evaluation regressions. Add CI to GitHub, and retrofit it onto Projects #1 and #2 while the material is fresh.

For Project #3, CI runs your Week 30 evaluation suite and fails the build when a metric regresses past a threshold you set. That one check is the most persuasive thing in the repository: it says you treat retrieval quality as something that can break, rather than something you measured once and hoped about.

Week 32 — Monitoring + drift

Learn service health, latency, error rates, data drift, prediction drift, model degradation, LLM evaluation regressions, and cost monitoring. Produce one drift report with Evidently or equivalent against Project #1's data. If the dataset has a time axis, its earlier and later periods are the reference and current windows. If it is a snapshot with no time axis — which Week 6 allows — build a clearly labelled synthetic shift: copy the test set, move one or two feature distributions in a way you write down, and run the report on that copy against the original. Label it synthetic everywhere it appears; the exercise is reading a drift report, not claiming to have seen drift; wire health, latency, and cost-per-query metrics into Project #3; and add an alert that fires when the nightly evaluation run drops below the Week 31 threshold. Do not survey the tooling landscape beyond that.

Weeks 33–36 — Project #3, hardening the flagship

Four weeks at the full rate — about 35 hours: eight in Week 33, where Wednesday is the recorded design session, and nine in each of Weeks 34–36. The DSA hour continues throughout.

Thirty-five hours does not build a production RAG system. It comfortably hardens one that has existed since Week 27, has been measured since Week 27, and already carries an evaluation suite, one tool, and CI. That is the entire reason Stage 4 committed its work to this repository — do not restart here. Your target:

Documents
   ↓
Parsing / chunking
   ↓
Embeddings
   ↓
Vector database
   ↓
Retrieval + reranking  ←── measured against your eval set
   ↓
LLM  ⇄  filtered-retrieval tool
   ↓
API (answer + sources)
   ↓
Logging + eval suite in CI

Ship at the end of each week. A working narrow system in Week 33 that grows is far better than an ambitious system still broken in Week 36.

Job-search block — keyed to a date, not a week

Start: twelve weeks before a search date you set. Not scheduled inside the 41 weeks. This block exists so that when you do decide, nothing has to be designed — only started.

The countdown

Roles this roadmap trains you for

Lead with the primary role you chose in Week 16 and the fallback alongside it. Your portfolio speaks directly to what they interview on, and your existing software engineering experience is the differentiator rather than the thing you are apologising for.

Adjacent roles — reachable, but not fully covered here

Apply to these too; just know what you are missing so a gap does not surprise you in a screen.

ML interview topics

Bias vs variance, overfitting, regularization, data leakage, cross-validation, feature engineering, class imbalance, model selection, and evaluation metrics.

Algorithm knowledge

Linear Regression, Logistic Regression, Decision Trees, Random Forests, Gradient Boosting, K-Means, PCA, and Neural Networks.

Deep-learning knowledge

Gradient descent, backpropagation, activation functions, loss functions, batch size, learning rate, Adam, dropout, normalization, embeddings, attention, transformers, and fine-tuning.

AI-engineering knowledge

RAG, embeddings, vector search, chunking, reranking, tool calling, agents/workflows, structured outputs, evaluation, hallucinations, latency, cost, caching, and prompt injection.

System design

The three canonical designs you can whiteboard unprompted — URL shortener, rate limiter (single-node and distributed), chat or news feed — plus the concepts behind them: estimation, load balancing, caching, sharding, replication, queues, consistency vs availability, WebSockets/SSE, fan-out. Then the two you built: an online prediction service (Project #1, scaled) and Project #3's RAG pipeline as a design answer — ingestion, chunking, embeddings, vector index, retrieval and reranking, the tool boundary, evaluation in CI, cost, freshness, and prompt injection. Lead with Project #3 whenever the interviewer lets you choose.

Coding screens

NeetCode 150 patterns through graphs and 1-D dynamic programming, in Python, under a timer, explained out loud. This is where a 0–2 year candidate is judged hardest, which is exactly why the rebuild is timed to land just before the screens rather than a year ahead of them.

Software fundamentals

System design is built up across the roadmap; DSA is kept warm during it and rebuilt in the countdown. Databases, APIs, testing, Docker, Git and CI/CD are covered by Weeks 2, 12, 13, 31 and 32 and by the three projects. Your mobile and backend experience is short but real — lead with what you have shipped, and let the portfolio do the rest.

Be ready for "how do you use AI in your own work?" — now a routine question, and one where an experienced engineer stands apart from a bootcamp graduate. The strong answer is specific about the boundary: what you delegate, what you refuse to delegate, and how you review what comes back. You will have lived that boundary for nine months by then; say so concretely rather than in generalities.

Your three-project portfolio

Project #1 — Classical ML Weeks 14–15

Demonstrates Scikit-Learn, EDA, feature engineering, cross-validation, model comparison, metric choice under class imbalance, calibration, pipelines, API design, and Docker.

The only one of the three left running at a public URL — it has no paid LLM call per request, so it is the one to expose; hosting charges remain subject to the selected platform's limits and the Week 0 hosting budget.

Project #2 — Deep Learning Weeks 23–24

Demonstrates PyTorch, Dataset/DataLoader, training loops, transfer learning, evaluation, experiment tracking, error analysis, and inference deployment.

Project #3 — Applied AI Weeks 27–36

Your flagship, and the one that gets the most calendar rather than the least. Demonstrates LLMs, RAG, embeddings, vector databases, reranking, one tool with failure tests, FastAPI, Docker, a runnable evaluation suite with a held-out set, monitoring, tests, and CI/CD.

Built across ten weeks rather than four: Weeks 27–30 produce it while you learn, Weeks 31–32 supply the production skills, and Weeks 33–36 harden it in about 35 hours. Auth, a UI, and a separate application database are cut; caching is in, measured. The measured evaluation suite is what makes the project persuasive — protect those hours ahead of everything else.

Weekly routine

One routine, all 41 weeks

10 hours, exactly: 3 topic + 1 DSA + 1 system design (or maths, before Week 6) + 5 building. The same table runs from Week 0 to Week 37 — there is no reduced-hours phase because there is no parallel job search. The week types differ only in where the hours point:

Anything a week adds — a retake, a dataset choice, a deployment, a README — replaces work inside those ten hours. Nothing sits on top.

The minimum viable week

How to use AI while learning

You attempt it
   ↓
get stuck
   ↓
ask AI
   ↓
understand answer
   ↓
implement
   ↓
modify it yourself

Progress checkpoints

Every checkpoint has an externally verifiable artifact. "I feel like I understand it" is not a checkpoint — at 11pm on a Sunday you will always feel like you understand it.