Data Science Portfolio: Projects That Get Interviews

The data science projects most likely to get you interviews start from a real question, use data you had to find, collect or clean yourself, compare a model against a simple baseline, and end with a conclusion someone could act on. Three or four of those, each with a short write-up on your portfolio site and a reproducible GitHub repository behind it, do more for you than a dozen notebooks on the famous datasets everyone else uses.

What reviewers are trying to learn

A hiring manager skimming your portfolio is asking a handful of questions, whether or not they say them out loud:

• Can you turn a vague problem into a question data can answer?
• Can you handle real, messy data, not just a cleaned CSV someone handed you?
• Do you know how to tell whether a model is actually good, and when it's good enough?
• Can you explain what you found to someone who doesn't write code?
• Could a colleague rerun your work without you in the room?

Every project you show should answer at least two of these clearly. If a project only proves you can call fit() and print an accuracy score, it's taking up space a better one could use.

Pick projects by the job you want

"Data science" covers very different jobs, and each rewards different evidence.

Target role	A project that fits	What it proves
Data or product analyst	Answer a business question with SQL on a public dataset, ending in a one-page memo and a small dashboard	Framing, SQL, writing for non-technical readers
Product data scientist	Analyze an experiment: choose the metric, check the sample size, interpret the result honestly	Statistics, judgment, avoiding false wins
Machine learning engineer	Train a model and serve it behind a small API, with tests and a note on how you'd monitor it	Engineering, deployment, maintainability
Data engineer	A pipeline that pulls a public API on a schedule into a database, with validation and tests	Reliability, scheduling, data quality
Domain roles (health, climate, finance, sports)	Any of the above, on data from that field	You already understand the field's problems

If you're applying to more than one kind of role, put the most relevant project first for each application. That's easy on your own site, since you choose which projects the home page features. If you're starting that site now, FNJ's data science portfolio starter opens the AI builder with a prompt written for data scientists.

Four project patterns that work

1. A question you actually had

Start from curiosity, not from a dataset. "Do bike-share stations near new transit stops get busier after the stop opens?" is a far better starting point than "bike-share data exploration". Many cities publish open data portals covering transit, permits, inspections and service requests. That data is messy, current and rarely overused.

2. A dataset you built

Collecting your own data shows a skill most portfolios skip. Pull from a public API over several weeks, combine two sources that weren't designed to fit together, or turn a stack of PDF reports into a clean table. Read each site's terms first and respect rate limits; what's allowed varies by site and by country.

3. An end-to-end model with an honest baseline

Show the whole arc: a simple baseline (last week's value, the most common class, a linear model), a better model, evaluation on data the model never saw, and an error analysis that says where it fails. "Beats the seasonal baseline in most months but misses badly around public holidays" is more credible than a single impressive number, because it shows you looked.

4. A replication that goes one step further

Take a published analysis, such as a paper, a public report or a well-known technical blog post, reproduce its main result, then extend it with newer data, a different region or a test of one of its assumptions. It shows you can read other people's work critically, which is a big part of the job.

What to leave out

• The overused tutorials: Titanic survival, Iris, MNIST digits, the standard house-price competition. Reviewers have seen them many times. Keep one only if you took it somewhere genuinely new.
• Capstones identical to your classmates'. If a whole cohort submitted the same project, add your own angle or leave it out.
• Scores with no baseline. "93% accuracy" means nothing if always predicting the most common class would score about the same.
• Leaky models. If a feature wouldn't exist at prediction time, a great score is a bug, and an experienced reviewer will spot it.
• Methods you can't explain. If you can't talk through a technique in an interview, learn it properly or drop the project.

Notebooks vs write-ups: you need both

A notebook and a write-up do different jobs for different readers.

	Notebook	Write-up on your site
Who reads it	A technical reviewer checking your work	Recruiters, hiring managers, anyone skimming
Its job	Evidence: the code and steps behind each claim	Argument: what you asked, found and recommend
Length	As long as the analysis needs	A few minutes of reading
Where it lives	Your GitHub repository	A project page on your portfolio

Most reviewers won't open a notebook unless the write-up persuades them first. Structure every write-up the same way:

1. Question. One or two sentences, in plain words.
2. Data. Where it came from, its size and quirks, and what you had to clean.
3. Approach. The baseline, the methods you tried, and why you chose the final one.
4. Result. The main finding, with your metric next to the baseline's. A template: "The final model cut mean absolute error by [X]% against a seasonal-naive baseline on a held-out final year."
5. Limitations. Where it fails, and what the data can't tell you.
6. Next steps and links. What you'd do with more time, then links to the repository, the notebook and any demo.

When a reviewer does open the notebook, make it readable. Restart the kernel and run every cell top to bottom before you commit, delete dead cells, narrate with markdown headings, trim long outputs, and move heavy functions into a src/ module so the notebook tells the story instead of holding all the code.

Charts that carry the argument

• One chart per claim. If a chart doesn't support a sentence in your write-up, cut it.
• Title each chart with its finding, not its variables: "Late deliveries cluster on Mondays" rather than "Deliveries by weekday".
• Label axes with units, and start bar charts at zero.
• Strip default clutter: heavy gridlines, rainbow palettes, 3D effects.
• Explain technical plots. A confusion matrix or residual plot needs a sentence on what to notice, and a feature importance chart needs a caveat about what it doesn't mean.
• Export clean images for your site, and link to an interactive version if you made one.

Make every project reproducible

Before you link a repository from your portfolio, check it against this list:

• A README with a one-paragraph summary, the main result and exact steps to run it.
• A pinned environment: a requirements.txt with versions, an environment.yml, a lock file or a Dockerfile.
• A script or clear instructions to download the data, plus a note on its license. Don't commit large raw files.
• A sensible layout: data/raw, data/processed, notebooks, src and a figures folder.
• Fixed random seeds wherever results depend on them.
• A few tests for the functions that clean or transform data.
• No secrets. API keys belong in environment variables, never in a notebook cell.
• A note on how long a full run takes and what hardware it needs.

Then ask a friend to clone it and run it on their own machine. Wherever they get stuck is where a reviewer would get stuck.

Connect GitHub and your portfolio site

GitHub is where the evidence lives; your portfolio site is the front door. Use them together on purpose:

• Pin your three or four best repositories on your GitHub profile, and add a short profile README that points to your site.
• Link each repository's README to its write-up, and each write-up back to the repository.
• Host interactive demos on a service built for them, such as Hugging Face Spaces or a hosted Streamlit app, and link the demo from the project page.
• Keep the site's structure simple: a home page with your target role and three featured projects, each with a one-line result; one page per project; an about page with your resume; and a contact link.

If you're also applying for engineering-heavy roles, the advice on which projects a software engineer should show overlaps a lot with the machine learning engineering path.

Building the site with FNJ

Build a data science portfolio with FNJ's AI builder: it starts from a prompt for data scientists, and you add a reference for the look you want. It designs the site itself (home, project pages, about), but it doesn't host notebooks or run apps, so keep demos on their own service and link to them. When the site is ready, you can push its code to a branch of your own GitHub repository, so it sits in version control like the rest of your work.

Frequently asked questions

How many projects should a data science portfolio have?

Three or four well-documented projects are usually enough. Choose them to match the roles you're applying for, and put the most relevant one first.

Are Kaggle projects good for a data science portfolio?

They can show modeling skill, but competitions hand you a clean question and dataset, which skips framing and data collection. Include one if you did something distinctive, and write it up like any other project, with a baseline and an honest account of what worked.

Should I put Jupyter notebooks in my portfolio?

Keep them in your GitHub repositories and link to them, but lead with a short written summary on your portfolio site. Most reviewers read the summary first and open the notebook only if it interests them.

Is GitHub enough, or do I need a portfolio website?

GitHub shows your code, but it isn't built to explain your thinking to non-technical readers. A simple portfolio site with one page per project gives recruiters a quick overview and sends technical reviewers to the right repositories.

What makes a data science project stand out?

A real question, data you gathered or cleaned yourself, a comparison against a simple baseline, honest limitations, and a conclusion someone could act on. Clear charts and a repository that runs on someone else's machine make it far more convincing.