Part 2 — ML / Applied AI Engineering

Overall strategy

Begin after Part 1's engineering and interview readiness check. Build on that foundation with ML, PyTorch, AI application development and production ML skills.

10 hrs/weekKeep current jobBuild while learning3 serious projects3 buffer weeks + 3 extension weeks~410 hrs in Part 2 — ~380 ML learning + building, ~20 DSA, ~12 ML system design

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 cost and data decisions, and the two 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 ML interview section. 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 25, so committing now would mean deciding with the least information you will ever have. You are building the evidence for the decision in Week 18, once you have shipped Project #1 and know what you actually enjoy. Save the file; you will re-read it then.

Install and configure

Foundation checks after Part 1

Recheck Python and SQL before choosing extension weeks. You have already practised them in Part 1, but not window functions or the idioms data code leans on; pass or repeat based on the artifact, not the calendar. Use the stated conditions below and record results. Missing setup is untested and gets resolved before interpreting the result as a skill gap.

If you pass one, that is how an extension week disappears. Pass Python and SQL and Week 5 is skipped. There is no FastAPI, Docker or CI test: Part 1 built all three (E1, E12), and Weeks 14 and 34 extend them to models. Nothing gets banked to Week 25, 30 or Project #3 — the extension weeks are the honest replacement for a cushion.

Your compute and cost plan — some now, the rest on a date

Week 6 makes your first paid LLM call, Week 17 puts Project #1 at a public URL, and Week 24 fine-tunes a pretrained vision model. Each fails late and expensively if you find out the week you need it. The API budget, storage and secrets are settled now; hosting and GPU are checked on the dates below, each with weeks of slack before the week that depends on it.

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 (5, 12, 22) 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 18 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. The ML practice hours — spend them on catch-up for the current stage before cutting any topic below.
2. Week 13 clustering — read for awareness, build nothing.
3. Week 10 tree internals — Gini versus entropy is not worth a week of slippage; you will still train and tune trees.
4. Week 11 beyond Random Forest and Gradient Boosting — AdaBoost, Extra Trees, stacking to awareness only.
5. Week 3 confidence intervals and sampling theory — know the vocabulary, move on. It sits late in this list because a weak statistics base costs you in Stage 2.
6. Week 24 computer vision — only once you have committed to the text path for Project #2.
7. ML design sessions outside Weeks 31–36 become concept-only — read the concept, skip the practice design. The Project #3 presentations are never cut.

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 20 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 — a fortnightly habit

One hour every other week, Weeks 1–40, including project and extension weeks — about 20 sessions. The coding skills were built in Part 1 Stage I; this hour only keeps them from lapsing. It is not a curriculum, and it does not replace fresh mocks before a search. The other week, the Tuesday hour is an ML practice hour — see Weekly routine.

Each session: re-solve one earlier problem from your Part 1 dsa/solved.md cold, then attempt one unseen problem from the pattern your log shows is weakest. Same rules as Part 1: Python, 35–45 minutes on the new problem, state the complexity, test edge cases, and log assistance honestly in the same file. Rotate through the Part 1 patterns rather than restarting at arrays; add tries or 2-D DP only if your target roles ask for them.

Coding, debugging, system design and behavioral preparation were completed before this part. If fresh mocks show gaps when a search approaches, refresh them using Part 1's application budget and reduce or pause ML hours.

ML system design

The backend designs — URL shortener, rate limiter, notification service — were practised in Part 1 and are not repeated here. This track covers only what is new: systems built around a model. Twelve Wednesday sessions between Week 14 and Week 36, each in the week whose material it draws on. Every other Wednesday from Week 7 is an ML practice hour.

Each session: 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. Refresh the Part 1 backend designs with a mock when a search approaches.

The Week 29 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 5

Focus on the data and maths foundations needed for ML. Use Week 0 results to choose the Python and SQL review depth. The Tuesday hour alternates between DSA and ML practice.

Week 1 — Python for data work

Review lists, dicts, sets, tuples, comprehensions, functions, lambdas, classes, exceptions, context managers, iterators, generators, decorators, modules, packages and type hints; focus on gaps shown by the Week 0 check. Part 1 gave you Python for backend code; this week is 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

Set up notebooks first: pip install ipykernel into the project environment and VS Code runs them directly — no separate Jupyter server. This is the first week that needs them.

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 6

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 30 and 33 exist to teach you exactly why, and in Week 30 you will fork this repository into Project #3 and rebuild it properly.

Stage 2 — Classical Machine Learning

Duration: Weeks 7–18

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

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

Install Scikit-Learn first. 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 8 — 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 9 — 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 5 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 10 — Decision Trees

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

Week 11 — 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 13 — 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 14 — 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. FastAPI and Docker are familiar from Part 1, so spend the time on what a model adds: load the artifact once at startup, validate the features in the request schema, and return the model version with every prediction. The Wednesday design session presents this same endpoint as a design answer — you will be asked about it in exactly that form. Pick the Project #1 hosting platform this week — see the hosting card in Stage 0 — half an hour out of the week's building time.

Week 15 — 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 16–17 — 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 14, 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 18 buffer is not a licence to start stretch goals in Week 17.

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 19–28, including extension Week 22

Week 19 — Neural network fundamentals

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

Week 20 — 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 21 — 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 23 — 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 21 networks; then do one small transfer-learning exercise — freeze a pretrained backbone, train a new head — so that Week 24 or Week 26 is the second time you have done it, not the first.

Week 24 — 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 18 GPU check pays off.

If you chose Applied AI in Week 18, this week is optional. Skim it for vocabulary, take the text path in Weeks 26–27 where you will fine-tune a transformer instead, and move the recovered hours to Week 25 or Week 30. 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 25 — 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 29 onward. You will use all of these constantly in Stage 4 without needing to have trained one.

The remaining hour is the Wednesday ML practice hour, spent this week to choose the Project #2 dataset and target metric, check the licence, and write the baseline down. That is nine hours plus the Tuesday hour — the week is exactly full. If something has to give, it is the two familiarity hours, not the attention hours.

Weeks 26–27 — 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 25. 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 25, 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 29–33

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

Week 29 — 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.

Spend about 2½ of this week's building hours writing the next 30 Project #3 questions — see Week 30.

Week 30 — 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.

Choose the vector store in writing. The Week 6 spike used whatever was simplest; the flagship gets a decision. Default to pgvector in Postgres — one database to run and back up, with metadata filters in plain SQL. Move to a dedicated vector database only for a need you can name: corpus size, a latency you have measured, or filtering and hybrid search pgvector cannot do. Put the choice and its reason in the README; the Week 31 design session will ask.

Week 31 — 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 32 and Week 33's to-do list.

Documents
   ↓
Parser
   ↓
Chunks
   ↓
Embeddings
   ↓
Vector DB

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

Week 32 — 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 33 — Evaluation

Expand the Week 30 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 32. 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 34's CI threshold has to start.

Then check the grader is right, not just consistent. Grade about 20 development-set answers yourself against the rubric without looking at its scores, compare, and record the agreement rate next to the suite. Where you disagree, fix the rubric or the grader prompt and check again before trusting its numbers. About an hour, from this week's building time.

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 34's CI will run.

System-design session 2 on Project #3 happens this week, after the held-out run: the same presentation as Week 31, 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 34–40

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 30.

Week 34 — CI/CD + ML testing

Test data schemas, preprocessing, model loading, prediction shapes, feature ranges, API behavior, and evaluation regressions. Reuse the pipeline you built in Part 1 E12, extend it with these checks, and retrofit it onto Projects #1 and #2 while the material is fresh.

For Project #3, CI runs your Week 33 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 35 — 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 7 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 34 threshold. Do not survey the tooling landscape beyond that.

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

Four weeks at the full rate — about 35 hours: eight in Week 36, where Wednesday is the recorded design session, and nine in each of Weeks 37–39. The fortnightly DSA hour continues throughout; in the other weeks the Tuesday hour goes to the flagship too.

Thirty-five hours does not build a production RAG system. It comfortably hardens one that has existed since Week 30, has been measured since Week 30, 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 36 that grows is far better than an ambitious system still broken in Week 39.

ML interviews — add specialization to Part 1

General software-engineering interview preparation belongs to Part 1 and does not wait for these projects. When you choose to apply for ML/AI roles, refresh that foundation and practise the role-specific topics below.

Roles this roadmap trains you for

Lead with the primary role you chose in Week 18. Refresh the actual postings and interview format before applying; use Part 1's engineering evidence alongside the ML projects.

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 Part 1 backend designs — URL shortener, rate limiter, notification service — refreshed with a mock before the search. The ML designs from this part: training pipelines and retraining, a recommender with its feature and skew problems, batch inference, and monitoring. 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

Refresh the patterns practised in Part 1, including graphs and 1-D DP, using fresh timed mocks. Review runnable code, edge cases and complexity aloud. Use the employer's actual format to choose any additional practice.

Software fundamentals

Part 1 supplies the backend project, debugging, SQL, coding and design evidence. These ML projects add model serving, evaluation and monitoring. Explain what you personally built, measured and changed.

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 16–17

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 14 hosting budget.

Project #2 — Deep Learning Weeks 26–27

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

Project #3 — Applied AI Weeks 30–39

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 30–33 produce it while you learn, Weeks 34–35 supply the production skills, and Weeks 36–39 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

The ML practice hour is where the time saved from Part 1 goes. Redo the week's exercise with the book closed, run it on a second dataset, or do error analysis on the week's model — whichever the week's material most needs. In foundation weeks it goes to that week's topic; in project weeks, to the project.

10 hours, exactly: 3 topic + 1 Tuesday (DSA or ML practice) + 1 Wednesday (maths, ML design or ML practice) + 5 building. The same table runs from Week 0 to Week 40 — 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. Calendar weeks and months below count from Part 2 Week 0, which is set after the Part 1 readiness check.