15 Data Science and Machine Learning Projects for Your Portfolio, by Role

Two candidates apply for the same junior role. The first has twelve repositories: Titanic survival, MNIST digits, house prices, a chatbot that answers questions about a PDF. The second has two. One of them forecasts electricity demand, shows by how much the model beats a simple "same week last year" guess, and lists the weeks where it fails. A reviewer with five minutes can check the second candidate's claims. The first candidate's work looks like everyone else's.

This guide lists 15 data science projects and machine learning projects, three for each of five roles. DataRoot Labs, an AI research and engineering company, wrote it from what practitioners who hire have published and from research into common modeling mistakes, checked in November 2026. We ran no survey of our own, and we found no rigorous survey that measures how much a portfolio weighs in hiring. Where the evidence is one person's experience, we say so.

• Data or product analyst: 1. A real question answered from messy data · 2. An experiment analysis · 3. A funnel or retention analysis
• Data scientist: 4. A predictive model built around a decision · 5. A forecast against naive baselines · 6. A causal estimate
• ML engineer: 7. An end-to-end service · 8. Monitoring and retraining · 9. Faster, cheaper inference
• AI or LLM engineer: 10. Question answering over real documents · 11. Structured extraction · 12. A tool-using agent
• Research scientist or engineer: 13. A replication · 14. A re-implementation from the paper alone · 15. A small original study

Data engineering and analytics engineering are outside this list; they deserve their own.

Chip Huyen, author of O'Reilly's Designing Machine Learning Systems, writes in her book on machine learning interviews that the strongest signal is past experience, and that experience includes projects you do independently and competitions you enter. Eugene Yan, who worked as an applied scientist at Amazon, describes how he interviews ML and AI engineers: he asks candidates how they evaluated a system, what error analysis they did, which trade-offs they made and what they would change.

Our reading of those two accounts: a portfolio can help you past a screen when you have no job history, and it supplies the project an interviewer will ask about. One project you can discuss at that depth serves you better than several you cannot. So choose a small number of projects for one role, and finish them:

1. Pick one target role and read ten to twenty current postings for it.
2. Note the three or four skills that keep recurring.
3. Choose a main project that looks like the daily work of that role.
4. Add one or two projects that cover a different skill from the postings.
5. Decide the metric and the baseline before you train anything. A baseline is the simplest method that could work, such as always predicting the most common class. Your model has to beat it to mean anything.
6. Finish each project to the checklist below, then archive the tutorial notebooks.

Each project names what to build, data you can legally use, what to compare against and a common mistake. Dataset licenses were checked on 12 November 2026; check them again before you publish your own work. None of these needs more than a laptop unless the entry says so.

Data and product analyst projects

Analyst work is mostly querying, joining and cleaning data, then explaining what it means to someone who has to act on it. Each of these projects should end in a recommendation.

1. Answer a real question from messy, multi-source data. Join at least two sources with SQL and write up the answer for a non-technical reader. An example question: which neighborhoods wait longest for a noise complaint to be closed, and does that hold after you account for the number of complaints? New York City's 311 service requests are updated daily and join with other city tables; the city's open-data FAQ says there are no restrictions on the use of Open Data. TidyTuesday publishes a smaller dataset every week with its original source. Compare your answer against the obvious explanation before you offer your own. Common mistake: a dashboard with no question behind it.

2. Analyze an experiment. Take data with a treatment group and a control group, choose the right statistical test, and report the size of the effect with its uncertainty. The Upworthy Research Archive holds 32,487 headline experiments under a CC BY 4.0 license. Its authors reported in June 2024 that they had found possible problems with 22% of the tests, starting from an imbalance in how many readers each version received. Checking for that imbalance is a good first step in your own analysis. ASOS has published a dataset of its online experiments, also under CC BY 4.0. Common mistake: reporting a p-value and stopping there.

3. Analyze a funnel or retention. Work from event-level data to show where users drop off or which groups of users come back. Google's GA4 sample dataset has three months of event data from the Google Merchandise Store. Google says the BigQuery sandbox or free tier is enough to explore it, that the data is obfuscated with placeholder values, and that its internal consistency is limited, so treat odd numbers with suspicion. It states no license of its own. For retention without a cloud account, UCI Online Retail II (CC BY 4.0) has invoices by customer, though no page views or carts. Common mistake: counting events when you need to count users.

Data scientist projects

Yan calls machine learning an empirical discipline: the job is to measure whether something works. Two habits run through all three projects. One is the baseline. The other is avoiding data leakage, which happens when information from the data you test on slips into training and makes the score look better than it is.

4. Build a predictive model around a decision. Frame the model by what someone would do with its output: whom to call, which loan to review, which machine to inspect. With the U.S. Department of Education's College Scorecard, which covers completion, debt and earnings by institution, you could predict which colleges are likely to have low completion rates, for an agency deciding where to look first. UCI Bank Marketing (CC BY 4.0) is common but teaches a useful lesson: its duration column is the length of the last call, which you would not know when deciding whom to call. Using it is leakage. Start with a baseline, choose a metric that reflects the cost of each kind of error, and show where the model fails by segment. Common mistake: reporting accuracy when one class is rare.

5. Forecast a time series against naive baselines. Predict demand, load or traffic, and compare with two simple forecasts: "same as last period" and "same as this period last year" (the seasonal-naive forecast). The U.S. Energy Information Administration publishes hourly electricity data and states that its publications are in the public domain; the API needs a free registration. The Monash Time Series Forecasting Repository collects 30 datasets. Its records carry a CC BY 4.0 license, and the site adds that the datasets are intended for research use. Split by time, with the test period after the training period. Common mistake: a random split, which lets the model see the future.

6. Estimate a causal effect. Use data from an experiment or a well-known observational study, and explain which assumptions your estimate depends on. Tennessee's Project STAR, a randomized class-size experiment, is on Harvard Dataverse under CC0. The LaLonde job-training data, the standard teaching case for comparing experimental and observational estimates, is distributed for non-commercial use with attribution. Compare the simple difference in averages with your adjusted estimate and explain the gap. Common mistake: describing a correlation in causal language.

Machine learning engineer projects

For ML engineers the model is a small part of the work. Google's Rules of Machine Learning put it directly in rule 4: keep the first model simple and get the infrastructure right.

7. Ship an end-to-end service. Build the path from raw data to a prediction API in a container, with tests. An example: an API that takes a photo of a piece of clothing and returns its category. Fashion-MNIST (MIT license) is deliberately ordinary data for this; it trains on a laptop, and the project is judged on its engineering. Run the evaluation automatically on every change, so that a change which hurts the metric fails the build. Made With ML is a useful reference for the standard. Common mistake: a notebook with a Dockerfile added at the end.

8. Monitor a model and retrain it. Train on one period, serve on later ones, detect when the incoming data starts to look different from the training data, and show what retraining recovers. New York's taxi trip records are published monthly and add and change columns over the years. arXiv metadata, which arXiv releases under CC0, lets you classify papers by field and watch the topics shift. Compare against a model that is never retrained. Common mistake: detecting a shift without showing that it affects the metric.

9. Make inference faster or cheaper. Take a pretrained model and reduce the time or memory it needs to make a prediction, for example by storing its numbers at lower precision (quantization) or by training a smaller model to imitate it (distillation). Two Apache-2.0 checkpoints on Hugging Face are small enough to work on without a GPU: a DistilBERT sentiment classifier and ResNet-50. The license covers the model weights, not the data they were trained on. Report the hardware, batch size, input size, warm-up and number of runs, and show the accuracy you gave up. Common mistake: a speed-up figure with no conditions attached.

AI and LLM engineer projects

An application built on a large language model is easy to demo and hard to trust. Hamel Husain, a machine learning engineer who worked at GitHub and now advises companies on LLM products, writes that, in his experience, unsuccessful LLM products almost always share one root cause, the lack of a robust evaluation system. OpenAI's evaluation guide lists "vibe-based evals" among its anti-patterns. Every project here therefore starts with an evaluation set: a list of inputs with the correct outputs, written by you, that you run after every change. These projects call a hosted model, so they cost some money per run; keep the set small at first.

10. Build question answering over real documents. This is usually called retrieval-augmented generation, or RAG: the system first finds relevant passages, then asks the model to answer from them. Choose documents from a field you understand, write your questions and answers before you tune anything, and measure the retrieval step and the answer separately. Legal text has structure you can test against. EUR-Lex allows re-use of EU legal documents for commercial and non-commercial purposes, and U.S. federal documents on GovInfo are generally free to reprint. Compare with plain keyword search and with the model answering alone, and show your types of failure with examples. Common mistake: a chatbot with no question set.

11. Extract structured data from documents. Pull fields from receipts or forms into a fixed schema, and score each field against a set of hand-checked correct answers. CORD (CC BY 4.0) pairs receipt images with field-level labels, which gives you those answers from the start. Compare with a rule-based extractor or a smaller model. Common mistake: checking a handful of outputs by eye.

12. Build an agent that uses tools. Give a model a small set of tools and a set of tasks whose outcome can be checked automatically. tau2-bench (MIT license) provides such tasks in domains like airline and retail, with a simulated user. Report the share of tasks completed, the cost per task and the response time, with the model version and date. Common mistake: showing one successful run.

If you use a model to grade outputs, check its grades against your own on a sample. Husain and the OpenAI guide both recommend calibrating automated scores against human judgment.

Research scientist and research engineer projects

These roles have a different entry bar. Huyen notes that a research scientist role typically requires a PhD or first-author papers at top conferences, while a research engineer role does not, though papers help. For all three projects, choose a paper whose experiments fit the hardware you have.

13. Replicate a recent paper. Start from the authors' code, reproduce the main result, then remove or change one component at a time to see what the result depends on (an ablation). Report what did not reproduce. The journal TMLR accepts replications, and its reproducibility certification requires more than a re-run: added baselines, analysis or ablations. Common mistake: hiding the numbers that fell short.

14. Re-implement a method from the paper alone. Write the method without looking at the official code, then compare your numbers with the published ones over several random seeds. This tests whether you understood the paper; project 13 tests whether the paper holds up. Papers with Code, long the usual index of papers with official code, now redirects to Hugging Face's paper pages, which link arXiv papers to code and models. Common mistake: reporting a single run.

15. Run a small original study. Ask one narrow question, state the hypothesis in advance, and write the result up as a short paper, including a negative result. Openly licensed benchmarks such as MMLU (MIT license) are cheap to score. Many models have probably seen them in training, so measure a difference, such as the effect of prompt format or answer order; a leaderboard number would tell you little. Common mistake: a scope that needs a lab's compute budget.

• Problem framing. Who would use this, what decision it changes, what success means. Basis: Yan's interview questions.
• Data and license. Where the data came from, when, under which license. Basis: our judgment. Licensing information is often missing at the source: an audit of more than 1,800 text datasets found that over 70% omitted some.
• Baseline. A simple result in the same table as the model. Basis: Andrej Karpathy, a founding member of OpenAI and former director of AI at Tesla, calls in his training recipe for an input-independent baseline before any real model.
• Metric. A metric tied to the cost of errors, with the threshold explained. Basis: Google's Rules of Machine Learning, rule 2: define and track metrics before building the system. Tying the metric to the cost of errors is our advice.
• Leakage-safe split. Split first, then prepare the data inside a pipeline; split by time or by customer where needed. Basis: The scikit-learn guide to common pitfalls (split first, prepare inside a pipeline). Splitting by time or customer is our addition.
• Error analysis. Segments where the model fails, with examples. Basis: Yan's interview questions.
• Reproducibility. Listed dependencies, training and evaluation code, and a README with the exact commands that reproduce the results; fixed seeds help too. Basis: The five-item ML Code Completeness Checklist.
• Demo or API. A hosted demo, a container, or a local run that works. Basis: our judgment.
• README. Problem, data, baseline against model, limitations, how to run. Basis: our judgment.
• Evaluation set (LLM projects). Labeled examples, automated checks, results tracked across changes. Basis: Husain; OpenAI's guide.

Tutorial clones. Titanic, Iris and MNIST are fine for learning and poor as the subject of a portfolio project. The authors of Fashion-MNIST proposed their dataset as a replacement because, in their words, MNIST is too easy: convolutional networks reach 99.7% and classic algorithms 97%. A result everyone can reach tells a reviewer nothing about you. Ordinary data is acceptable when the model is not the point, as in project 7.

Data leakage. The scikit-learn documentation has a worked example: on random data, where no model should beat a coin flip, selecting features before splitting the data produces 0.76 accuracy. Splitting first gives the honest 0.5. The same error appears in published science. As of May 2024, Sayash Kapoor and Arvind Narayanan list 41 papers across 30 fields that found such errors, affecting 648 papers in total. In a portfolio it usually takes the form of scaling on all the data, a random split on a time series, or the same customer appearing in both training and test sets.

No baseline. A 2019 study of neural recommendation methods from top conferences could reproduce 7 of 18 with reasonable effort, and 6 of those 7 were often outperformed by simple heuristic methods. If published models lose to simple ones, a score with nothing beside it has not shown much.

Two smaller ones: a side project has no customers, so it cannot claim that it reduced churn by 15%; and a repository without a license file gives no one permission to reuse it.

Kaggle. Competitions give you a hidden test set, which keeps your evaluation honest. A title does less on its own than people expect. Tatiana Gabruseva, a Kaggle Competitions Master, says in a DataTalks.Club interview that the title did not bring her opportunities. A clean repository from one competition, listed on her résumé next to a top-5% result, did: an interviewer read it, and she got an offer. That is one person's account. It suggests writing a competition up as a project.

Open source. A merged contribution has been reviewed by someone else, which a personal project has not. Expect it to be slower than tutorials suggest. The scikit-learn contributing guide says maintainers rarely use the "good first issue" label because such issues often prove harder than expected. It also tells contributors not to open AI-generated pull requests unless they have read the related issues, reviewed every change by hand and can explain their reasoning. Bug reports with a minimal reproduction, documentation fixes and reviews all count as contributions there.

Replications. The ML Reproducibility Challenge began at ICLR 2018, has published through TMLR since 2023, and became an official track at NeurIPS in 2026. A replication is useful for research-track roles even if you never submit it.

Hackathons. They teach you to frame a problem under time pressure. A 2020 study of hackathon projects on Devpost found that about 35% had at least one code commit after the event and about 5% were still being worked on five months later. A hackathon project becomes a portfolio piece if you are in that 5%: add the baseline, the reasoning behind the metric and the limitations. At Plasma Code, a hackathon at Kyiv Polytechnic Institute in October 2026 that DataRoot Labs supported with organization and mentoring, one question among the prize-winning work was how an early-warning model should balance a missed event against a false alarm. A question like that, written down and answered, is the part worth keeping.

Put the result at the top of the README. A reviewer should see what you built, how well it works and against what, without opening a notebook.

# Project name: one line on what it does and for whom

Demo: link, or the command that runs it locally

## Result
| Approach | Metric | Test set |
| -------- | ------ | -------- |
| Baseline | 0.00   | name     |
| Model    | 0.00   | name     |

How the baseline was computed; date and seeds.

## Problem
Who needs this, what decision it supports, what "good" means.

## Data
Source, date retrieved, license, known gaps and biases.

## Approach
What you tried, in order, and why you kept what you kept.

## Where it fails
Segments or examples the model gets wrong, and what you would try next.

## Run it
One command to install, one to train, one to evaluate.

## Scope and license
What this project does not show. The license for your code.

Pin your two or three finished projects on your GitHub profile and archive the rest. Then write one short post about each. Rachel Thomas, co-founder of fast.ai, puts the audience question simply: write for yourself six months ago.

Andrew Ng describes a progression from class projects to personal projects to work that others find valuable, and tells readers not to worry about starting too small. A course capstone sits at the first stage. It becomes a portfolio project when you change something that matters: your own data, a baseline, an error analysis, a write-up.

DataRoot Labs runs DataRoot University, a free online program. The final project of its Data Science Fundamentals course is a machine learning application with a prediction API and a Docker container. The course assumes basic programming and university-level mathematics, so it suits readers who already have that background. The advice in this guide applies whatever course you take.

How many data science projects do I need?

Two or three finished ones for the role you are applying to. We found no study that sets a number; this is our judgment from how interviews use a project. Huyen warns hiring managers that not everyone can afford to contribute to open source or enter competitions. If your time is limited, depth on two projects is a realistic target.

What are good AI projects for beginners?

Before an LLM project, learn the habits every project depends on: a baseline, a split that does not leak, and a look at the errors. Projects 4 and 5 on a small dataset teach all three. Move to project 10 once you can write an evaluation set.

Can I use AI coding assistants for portfolio code?

Yes, if you understand every line. Expect interviewers to ask why you made each choice, and the scikit-learn policy described above shows how one large open-source project treats code its contributors cannot explain.