21 September 2026 · careersprojects

What ML projects actually get you hired in 2026?

The machine learning projects that help in hiring are the ones you cared enough about to finish, measure, and defend. This post covers how to pick one, what a reviewer checks, five projects worth building, how to present it, and how to answer when an interviewer asks why you didn't do it another way.

A machine learning project helps you get hired when it shows that you can take a real question, get data for it, train something, measure it against a simple baseline, and explain the choices you made. The topic and the model matter less than that. Most applicants now have a degree or a certificate, so the project is often the only place a reviewer can see how you work.

Start with a problem you care about

The projects that come across well in interviews are usually about something the person wanted solved: an itch of their own, or a pain point a friend or family member has. A parent who sorts hundreds of supplier invoices by hand. A climbing gym whose route grades feel inconsistent. Your own 4,000 unread newsletters. A sibling's handwriting that no OCR tool reads correctly.

There are two practical reasons for this. A project you care about is one you will keep working on after the first model gives 61% accuracy and the work turns into cleaning data for two weeks, which is where most side projects are dropped. And you will be happy to talk about it. An interviewer can tell within a minute whether someone is describing a thing they wanted to exist or a notebook they finished because a course told them to.

A project built on your own problem also comes with data nobody else has and a question no tutorial answers, so it can't look like the fifty other submissions.

What a reviewer checks

A reviewer usually has a few minutes per project. These are the things they tend to look for, roughly in this order:

A question. "Can a model sort my father's invoices into his 12 accounting categories?" is a question. "Image classification with CNNs" is a technique.
Data work you did yourself. Collected, scraped, labelled, or cleaned by you, with a note on how much there is and what is wrong with it.
A baseline. The simplest thing that could work, measured the same way as your model. Without it, 87% accuracy means nothing, because predicting the most common class might already give 80%.
An evaluation you can defend. A held-out test set, a metric that fits the problem, and no information from the test set used during training.
What failed. The approaches that didn't work and the examples the final model still gets wrong.

A checklist of the five things a reviewer checks in an ML project: a question, your own data work, a baseline, an evaluation, and what failed.

For example, an invoice classifier with 12 categories could be scored on its held-out test set like this, first for a single linear layer as the baseline and then for the real model:

1import torch
2 
3@torch.no_grad()
4def evaluate(model, loader, num_classes, device="cpu"):
5    model.eval()  # turns off dropout, uses batch norm running stats
6    correct = torch.zeros(num_classes)
7    total = torch.zeros(num_classes)
8    for x, y in loader:
9        preds = model(x.to(device)).argmax(dim=1).cpu()
10        for c in range(num_classes):
11            mask = y == c
12            total[c] += mask.sum()
13            correct[c] += (preds[mask] == c).sum()
14    overall = (correct.sum() / total.sum()).item()
15    per_class = correct / total.clamp(min=1)
16    return overall, per_class
17 
18base_acc, base_per_class = evaluate(linear_baseline, test_loader, num_classes=12)
19model_acc, model_per_class = evaluate(model, test_loader, num_classes=12)
20print(f"baseline {base_acc:.3f}  model {model_acc:.3f}")

Per-class accuracy matters when classes are unbalanced, because a model can reach 90% overall while scoring close to 0% on a rare class. If the two numbers look wrong, check first that test_loader holds examples the model did not see in training.

Why tutorial projects usually get skipped

Titanic survival, MNIST digits, house prices, and a sentiment classifier on IMDB reviews are fine for learning. As portfolio pieces they have a problem: the data arrives clean, the question is given, the evaluation is given, and thousands of identical notebooks exist. None of the five things above are visible, so a reviewer learns nothing about you from them.

A chatbot that wraps one API call with a prompt has the same issue in 2026. It can be a good product, but with no evaluation set and no comparison it shows no ML work.

Five projects a reviewer wants to see

Each of these runs on public data, takes weeks of evenings, and can be pointed at a topic you care about by swapping the corpus or the task.

Train a 50M-parameter GPT from scratch. Use public text such as TinyStories or a slice of Wikipedia. Write your own tokenizer and a training loop with mixed precision and checkpointing, train three model sizes, and plot the loss curves together. Add one ablation, meaning the same run with a single thing changed, such as learned against rotary position embeddings or training with and without learning-rate warmup. The reviewer sees that you can write and debug a real training run.
Fine-tune an open 1B to 8B model on a public task. Text-to-SQL on the Spider dataset and function calling are good choices. Use LoRA, which trains small added matrices while the original weights stay frozen, so it fits on one GPU. Build an evaluation harness that runs the generated SQL and checks the result, then compare four systems: the base model, the base model with a few examples in the prompt, your fine-tuned model, and a large API model. Report accuracy and cost per 1,000 queries. The reviewer sees evaluation discipline and an answer to whether fine-tuning was worth it.
Make one model 4x cheaper to serve. Take Whisper-small or a vision transformer and apply three techniques one at a time: quantization (storing weights in 8 or 4 bits), distillation (training a smaller model to copy the large one's outputs), and pruning (removing weights that contribute little). Report accuracy, latency, and memory on CPU and on GPU for each, with a profiler trace showing where the time goes. Many production teams spend most of their time on this kind of work.
A retrieval-augmented generation system with a benchmark attached. Retrieval-augmented generation (RAG) fetches relevant passages and hands them to a language model to answer from. Build it over a public corpus that ships with questions and gold answers, such as arXiv ML papers or a legal or medical QA set. Run 8 to 10 experiments, changing one thing each time: chunk size, keyword search combined with embedding search, a reranking step, a fine-tuned embedding model. Report retrieval hit rate for each and measure how often the generated answer is unsupported by the retrieved passages. The reviewer reads the experiment table.
Reproduce a known result at small scale, then ask your own question. Good candidates are double descent (test error falling, rising, then falling again as the model grows), grokking on modular arithmetic (test accuracy jumping long after training accuracy reaches 100%), or fitting a scaling law across six tiny models. Match the published plots first, then test one thing the paper did not. This shows research ability, which labs and applied-research teams screen for.

One finished project with all five reviewer checks usually does more for you than six half-finished ones.

How to present it

Put the result at the top of the README: the question, the final number next to the baseline number, and one plot. Then the data (where it came from, how much, known problems), the approach, what you tried that didn't work, and what you would do next. Keep setup instructions short and make sure they run. Most reviewers read the top third of the README and open one file, so the top third has to carry the project.

"Why didn't you do X instead?"

Expect this question in most interviews where you present a project. Why a CNN and not a vision transformer? Why fine-tune when you could have prompted a larger model? Why accuracy and not F1? Interviewers often argue the other side on purpose, including when they think your choice was fine. They are checking two things: whether you understand the trade-offs of what you built, and what you are like to disagree with, because disagreeing about approaches is a large part of working on an ML team.

Answers that go badly are the rigid ones. "Because CNNs are better for images" is a blanket claim the interviewer can knock down with one counterexample, and it makes you sound like someone who will defend a choice instead of examining it.

If you did consider the alternative, say what you compared and what decided it: "I tried a small ViT early on. With 3,000 images it overfit faster than the CNN and validation accuracy was about 4 points lower, so I stayed with the CNN. With more data I'd expect that to flip."

If you have never heard of what they suggest, say so plainly. Something like: "I was still learning when I built this and I didn't know about X at the time. If I were doing it again I'd look into X, compare it against what I used on the same test set, and keep whichever did better." Then ask them what they like about X. That answer shows you can admit a gap, that you know how you would close it, and that you stay curious when challenged, which is what the question was testing.

Prepare for this before the interview. For each major choice in the project (data, model, loss, metric, split), write down one alternative and one sentence on why you didn't use it, or that you didn't know about it then.

Common mistakes

Reporting a score with no baseline next to it.
Tuning on the test set, then reporting the test score.
A README that lists the tech stack and never states the result.
Hiding the failures. The failed attempts are often the most convincing part.
Picking a topic to impress, then having nothing to say about it when asked why you chose it.

QuiddityML ends each unit with a Projects section that asks for visible results such as code, metrics, and a short write-up, followed by interview questions on the same material, so the concepts behind your project choices are ones you have practiced explaining.