Machine Learning
From a messy table to a model you can defend in a meeting.
Most machine learning courses open with the algorithm. That is the wrong end of the problem. In practice you will spend maybe a tenth of your time choosing an estimator and the rest of it deciding what a row actually represents, why four percent of your dates land in the future, and whether the column that predicts everything is in fact leaking the answer you are trying to predict. This path is built around that reality. You start with Python and pandas — not as programming, but as an instrument for interrogating data — and you learn to look before you model, because the plot you did not make is the bug you will ship. Then you build: features, which are the model far more than the estimator ever is, followed by regression and classification with the unglamorous baselines that quietly beat neural networks on tabular data year after year. The final phase is the one that matters most and gets taught least: validation that does not lie to you, and metrics that mean something to the person paying for the model. Ninety-eight percent accuracy on a two percent fraud rate is a model that has learned to say no. You will finish able to take a messy business dataset to a defensible model — and, just as importantly, able to say out loud when there is no model to be had.
What you will learn
Prerequisites
- Basic programming in any language
- High-school algebra; you can read a formula without panic
- Willingness to spend more time on data than on models
Where it leads
- Machine Learning Engineer
- Data Scientist
- Applied Scientist
- Quantitative / risk analyst
Phases
Phase 1 — The data comes first
Learn to interrogate a dataset until it confesses. No modelling until you can describe every column.
Estimated duration · 8-10 weeksPython and pandas as an instrument
You are not learning software engineering here; you are learning to ask a table questions quickly. The dangerous part of pandas is that it rarely errors — a merge with the wrong cardinality silently triples your rows, a chained assignment silently does nothing, and your model trains happily on garbage. You will learn where it lies to you and how to catch it: assert your row counts, check your join keys, and never trust a mean you have not seen a histogram of.
Topics covered
What you will build
- Load a dataset of 1M+ rows and produce a one-page data dictionary: every column, its type, its missing rate, its plausible range
- Take a notebook you wrote last month, restart the kernel and run it top to bottom — fix everything that breaks
- Write five assertions that would have caught a silent join duplication, and prove they fire on a broken merge
Look at the data before you model it
Exploratory analysis is not a decorative phase you rush through to reach the fun part — it is where you find the bugs that would otherwise take three weeks to surface in production. Plot every distribution. Ask why the target rate jumped in a given month. Find out that a column was only populated after a system migration, so it exists for the recent half of your data and is worthless the day you deploy. Every experienced practitioner has a scar from skipping this, and none of them skip it twice.
Topics covered
What you will build
- Produce an EDA report on a real dataset that ends with three concrete findings that change how you would model it
- Find at least one column whose availability changes over time, and document the date it appeared
- Plot the target rate by month for two years and write a paragraph explaining every break in the line
Phase 2 — Features, then models
Build the representation, then let a boring, strong baseline do the work.
Estimated duration · 8-12 weeksFeatures are the model
Swapping estimators buys you a couple of points. Encoding a date as "days since the customer's previous order" instead of a raw timestamp buys you twenty. Feature engineering is where domain knowledge enters the system, and it is why the analyst who understands the business beats the engineer who only understands the library. It is also where leakage is born: the moment you compute a feature using information that did not exist at prediction time, your validation score becomes fiction.
Topics covered
What you will build
- Beat a raw-columns baseline by 10 points on the same estimator, using feature engineering only
- Write a point-in-time check: for each feature, state the timestamp at which it becomes knowable, and delete every feature that fails
- Take one target-encoded feature and demonstrate the leakage it causes when fitted outside the fold
Regression, classification, and the baseline you skipped
Start with predicting the mean, or the majority class. If your sophisticated model does not clearly beat that, you do not have a model, you have a plot. Then learn linear and logistic regression properly — not because they always win, but because they are interpretable enough to tell you when your data is wrong. Then reach for gradient-boosted trees, which remain the honest default on tabular data. Anyone selling you a neural network for a spreadsheet is selling you a neural network.
Topics covered
What you will build
- Ship a table comparing dummy, logistic regression and gradient boosting on the same folds, same features, same metric
- Take your best boosted model and reproduce 90% of its score with a logistic regression plus better features
- Run a hyperparameter search and report honestly how many points it actually gained over defaults
Phase 3 — Validation, metrics and the truth
Make sure the number you report is the number the business will get.
Estimated duration · 8-12 weeksValidation that does not lie
A random train/test split on data that has a time dimension is the most common silent bug in the field, and it is committed daily by people with excellent Kaggle rankings. If tomorrow is what you predict, you validate on tomorrow. If the same customer appears in both folds, your model memorised the customer, not the pattern. Leakage does not announce itself with an error — it announces itself with a suspiciously good score, which is exactly the moment nobody wants to look closer.
Topics covered
What you will build
- Take a model validated with a random split, re-validate it with a temporal split, and report the score you actually lost
- Construct a deliberately leaking pipeline that scores 0.99, then dismantle it and explain each leak in writing
- Build a grouped cross-validation for a dataset with repeated entities and show the gap versus naive k-fold
Metrics, thresholds and the cost of being wrong
Accuracy is the metric of people who have not thought about the problem. On a two percent event rate, always predicting "no" scores ninety-eight and helps nobody. The real question is what a false positive costs versus a false negative, and that is a business conversation, not a maths one. You will learn to pick a metric that maps to money or harm, to set a threshold deliberately rather than accepting 0.5 by default, and to check calibration — because if you say seventy percent, seventy percent of those cases had better happen.
Topics covered
What you will build
- Write a cost matrix with a real stakeholder, then pick the operating threshold it implies and justify it in one page
- Plot a reliability curve for your classifier and fix its calibration; show the before and after
- Simulate three months of drift on a held-out period and state the date at which you would retrain
Questions
Do I need heavy mathematics to do machine learning professionally?
Less than the internet suggests, and more than bootcamps admit. You will not derive anything from scratch on the job, but you will be lost without the intuition behind three things: what a gradient does, why regularisation trades bias for variance, and what a probability actually claims. That is a few weeks of honest work, not a degree. The mathematics that genuinely gates people is statistical thinking — understanding that a difference of two points on eight hundred rows is noise. If you can hold that idea firmly, you will outperform plenty of people who can recite proofs and still validate on a random split.
Why does this path barely mention neural networks?
Because on the tabular data that makes up the overwhelming majority of business problems, gradient-boosted trees are still the right answer, and they train in seconds on a laptop. Deep learning wins on images, audio, and language — on unstructured data where the model must learn its own representation. Teaching neural networks first produces engineers who bring a deep architecture to a churn table, burn three weeks, and lose to a model that fits in a single function call. Once you can do the work described here, deep learning is a natural next path, and you will arrive with the one thing most deep learning practitioners lack: the reflex to check whether the data is telling the truth.
I finished several Kaggle competitions. Is this path redundant for me?
Probably not, and here is the uncomfortable reason. A competition hands you a clean dataset, a fixed metric, and a leaderboard that guarantees no leakage. Every one of those gifts is absent at work. Your real job starts before the data exists: deciding what to predict, whether prediction is even the right intervention, which rows are legitimate, and what the model costs when it is wrong. Competition skill transfers well to phase two of this path and almost not at all to phases one and three, which are the phases that determine whether your model reaches production or dies in a notebook. Skim what you know; do not skip the parts that feel obvious.
Related paths
Want to walk this path with a coach and a cohort?
Discover the 212AY Academy →