Build Data Science Portfolio — Projects That Get Hired

A certificate says you finished a course. A portfolio shows what you can do when nobody hands you the answer.

A data science portfolio is a small set of public projects that lets a hiring manager check your skills without taking your word for them. "I completed a machine learning course" is a claim. "I built a churn model, compared it with a naive baseline, and wrote down where it fails" is evidence. This guide covers which projects to build, how to structure them on GitHub, which metrics persuade and which mislead, and the mistakes that make otherwise good work look weak.

The advice here is built on the mechanics of the work: what each project type proves, how evaluation can go wrong, and what a reader needs to see. It is not a guarantee of a job, and hiring varies by company, so treat it as a framework to adapt.

---

Why a portfolio matters in this field

Data science is a field where the work can be shown. The U.S. Bureau of Labor Statistics reports that data scientists had a median pay of $120,230 per year in 2025, that employment stood at about 275,600 jobs, and that it projects 35% growth from 2025 to 2035, described as much faster than average. The same page notes that the typical entry-level education is a bachelor's degree, often in mathematics, statistics, or computer science, and that some employers prefer a master's or doctorate. Those figures are on the BLS Occupational Outlook Handbook. The related articles at the end cover the hiring side of the market in more detail.

Growth in a field does not make any single application easy, and the BLS page says nothing about portfolios. The case for building one rests on logic. A degree or certificate tells a reader what you studied. A repository tells them how you think. A project can demonstrate things a transcript cannot:

• Working with messy data that has missing values, odd formats, and surprises
• Making decisions when no one tells you the right answer
• Testing a model honestly instead of flattering it
• Explaining technical work to someone who did not do it
• Shipping something that runs outside your own laptop

What a portfolio can and cannot prove

A portfolio is not a magic key. It proves some things well and others poorly, and knowing which helps you plan.

It proves well	It proves poorly
You can finish a project end to end	That you can work in a large team with shared code
You can clean and explore real data	That you can handle production-scale data volumes
You understand evaluation and baselines	That your model would succeed in a live business
You can communicate in writing	That you can handle ambiguous stakeholder requests

Fill the gaps where you can. A project built with a collaborator, using pull requests and code review, shows teamwork. A project that runs on a scheduled job shows a little of production. A project with a stakeholder, even an informal one, such as a local business owner, shows you can handle a vague request.

---

The five projects, in order

The order below builds skills in layers. Each project adds something the previous one lacks. You do not have to build all five, and three strong projects beat ten weak ones. Pick the ones that match the roles you want.

#	Project type	Main skill shown	Typical data source
1	End-to-end prediction	Full modeling workflow and honest evaluation	A public tabular dataset
2	Messy real-world analysis	Cleaning, judgment calls, storytelling	Open data portals
3	Time series forecast	Temporal thinking, backtesting	Sales, energy, or traffic data
4	NLP or computer vision	Unstructured data, pre-trained models	Text or image datasets
5	Business impact case study	Framing a problem and measuring an outcome	A real or clearly labeled synthetic scenario

Project 1: end-to-end prediction (beginner)

This project proves you can run the whole workflow once, carefully. A house-price model is a classic choice because the target is easy to understand and the data is clean enough to focus on method. The King County, Washington house sales dataset, which contains 21,613 observations according to its R package documentation, is a common one. Because everyone uses it, the way you handle it is what matters.

Minimum deliverables:

• A notebook with markdown that explains each decision
• A requirements.txt so others can reproduce your environment
• A README with the problem, approach, results, and limits
• At least three models compared against a baseline

The baseline matters most. A baseline is a trivial prediction, such as always guessing the average price, that any real model has to beat. Without one, a number like "RMSE of 120,000" means nothing. With one, it means "this model cuts the error by a stated fraction."

import numpy as np
import pandas as pd
from sklearn.dummy import DummyRegressor
from sklearn.ensemble import RandomForestRegressor
from sklearn.linear_model import Ridge
from sklearn.model_selection import cross_val_score, train_test_split
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from xgboost import XGBRegressor

df = pd.read_csv("kc_house_data.csv")

# Feature engineering: age at the time of sale
df["house_age"] = pd.to_datetime(df["date"]).dt.year - df["yr_built"]
df["bath_per_bed"] = df["bathrooms"] / df["bedrooms"].replace(0, np.nan)

X = df.drop(columns=["price", "id", "date"])
y = df["price"]

# Hold out a test set and do not touch it until the end
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42
)

models = {
    "Baseline (mean)": DummyRegressor(strategy="mean"),
    "Ridge": make_pipeline(StandardScaler(), Ridge(alpha=1.0)),
    "RandomForest": RandomForestRegressor(n_estimators=200, random_state=42),
    "XGBoost": XGBRegressor(n_estimators=200, random_state=42),
}

for name, model in models.items():
    scores = cross_val_score(
        model, X_train, y_train, cv=5, scoring="neg_root_mean_squared_error"
    )
    print(f"{name}: RMSE = {-scores.mean():,.0f} (+/- {scores.std():,.0f})")

A few details in that snippet reflect real pitfalls. The scaler sits inside a pipeline, so it is fit only on the training portion of each cross-validation fold. The scikit-learn documentation warns that preprocessing should be learned from the training set and applied to held-out data, and that knowledge about the test set can leak into a model and make the evaluation metrics stop reflecting generalization performance. The test set is held back until a final check. The explainer on why training and test data must be separated walks through the reasoning, and data leakage covers the subtler ways it creeps in.

What separates your project from a tutorial: pick a different validation strategy, engineer a feature the tutorial did not, or analyze where the model fails. A map of the largest errors by neighborhood is more informative than a fifth decimal place of RMSE. If you are new to the workflow, the step-by-step tutorial to build your first ML model is a good warm-up.

Project 2: a real, messy dataset (intermediate)

This project shows you can handle data nobody cleaned for you. Tutorial datasets are tidy on purpose. Real ones have inconsistent categories, impossible values, and gaps, and the decisions you make about them change the answer.

Good sources include:

• NYC Open Data, the city's data portal, which covers topics such as climate, housing, and food
• NOAA's Climate Data Online, which provides quality-controlled daily, monthly, seasonal, and yearly measurements of temperature, precipitation, and wind
• The Johns Hopkins CSSE COVID-19 repository on GitHub, an archive. Its Resource Center stopped collecting and reporting global data on March 10, 2023, so it is a fixed historical dataset, not a live feed

Say that last point in your own write-up if you use it. A dataset with a known end date is not a flaw, but failing to mention it is. State what period the data covers, who collected it, and what it leaves out.

What makes a good analysis:

• A clear question, such as "Did the number of reported incidents change after a policy took effect?"
• An answer stated with its limits, such as "In this data, the count fell, though reporting practices also changed, so the drop may not reflect a real change"
• Charts a stranger can read in ten seconds
• A short list of what you could not determine

The last point is where many portfolios fall short. Be careful about causal language. A pattern in observational data can come from a third factor, a change in how things are counted, or chance. The explainer on how correlation differs from causation is worth rereading before you write conclusions, and how data visualization can mislead is a useful check on your own charts.

Document every cleaning decision. If you dropped rows with missing values, say how many and why you think it was safe. If you filled them, say with what. The article on what data cleaning actually involves lists the usual decisions, and the piece on why cleaning takes so much of a data scientist's time explains why reviewers will look closely at this part.

Project 3: time series (advanced)

Forecasting shows you understand that data has an order, and that order changes how you test. Typical topics are energy demand, retail sales, web traffic, and weather. For background, the explainer on how time series forecasting works covers trend, seasonality, and noise.

The key idea is that you cannot shuffle time. A normal random split lets a model see the future while training. The scikit-learn documentation states that for time series it is important to evaluate the model on future observations that are least like those used to train it, and its TimeSeriesSplit makes each training set a superset of the ones before it, always testing on later data.

import pandas as pd
from prophet import Prophet

# Prophet expects two columns: ds (dates) and y (values)
df = pd.DataFrame({
    "ds": pd.date_range("2023-01-01", periods=730),
    "y": sales_data,  # your daily series
})

model = Prophet(yearly_seasonality=True, weekly_seasonality=True)
model.fit(df)

future = model.make_future_dataframe(periods=90)
forecast = model.predict(future)

model.plot(forecast)
model.plot_components(forecast)

The Prophet quick-start documentation says its input is always a dataframe with two columns, ds and y, and that make_future_dataframe builds the future dates to predict, including the historical dates by default so you can inspect the fit.

Pick metrics that fit the data

The forecasting textbook Forecasting: Principles and Practice by Hyndman and Athanasopoulos explains why metric choice matters.

Metric	What it measures	Watch out for
RMSE	Typical error in the series' own units	Scale-dependent, so not comparable across series with different units
MAPE	Error as a percentage	Infinite or undefined when any actual value is zero, and it penalizes errors unevenly
MASE	Error scaled by a naive forecast on the training data	A value below 1 means better than the average one-step naive forecast

MAPE is popular because percentages are easy to explain, but the textbook points out that it breaks when actual values are zero or near zero and that percentage errors assume the unit has a meaningful zero. MASE avoids this by comparing against a simple naive forecast. Report at least one scaled metric and always compare against a naive method.

A caution about stock prices

Many portfolios include a stock-price predictor. It is a risky choice. In the textbook's own example using a Google stock price series, the naive method (tomorrow equals today) had an RMSE of 43.43, the drift method 53.07, and the mean method 118.03, so the simplest method won among the three tested. A fancy model that cannot beat naive on a financial series has not found a signal. If you pick finance, make the honest comparison against naive the centerpiece, and do not suggest your model is a trading strategy.

The overfitting and underfitting article explains why a model can look excellent on the data it has seen and fail on new data, which is the central risk in forecasting projects.

A bonus step: Turn the forecast into a small app with uncertainty bands. The Streamlit tutorial shows how to build one in Python.

Project 4: NLP or computer vision (specialized)

This project shows you can handle unstructured data, which is text, images, or audio. It matters most if you are aiming at roles where those data types dominate.

Text ideas: sentiment analysis on product reviews, topic modeling of news, support-ticket routing, spam detection, or named entity recognition.

Image ideas: plant or food classification, defect detection, or medical image classification using public datasets.

Using a pre-trained model and adapting it is the standard modern approach, so the value you add is in the adaptation and the evaluation, not in training from scratch. A minimal sketch of fine-tuning with the Hugging Face libraries looks like this:

from transformers import (
    AutoModelForSequenceClassification,
    AutoTokenizer,
    Trainer,
    TrainingArguments,
)

model_name = "distilbert-base-uncased"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForSequenceClassification.from_pretrained(
    model_name, num_labels=2
)

args = TrainingArguments(
    output_dir="./model",
    num_train_epochs=3,
    per_device_train_batch_size=16,
    eval_strategy="epoch",  # older code uses evaluation_strategy
)

# train_ds and eval_ds are tokenized datasets you build from your own data
trainer = Trainer(model=model, args=args, train_dataset=train_ds, eval_dataset=eval_ds)
trainer.train()

Note the eval_strategy argument. Older tutorials use evaluation_strategy, which was renamed in the transformers library, so copied code can fail on a current install. That is a good small example of why you should run your code on a clean environment before publishing it.

What turns this into a portfolio project instead of a tutorial is the data and the evaluation:

• Use data from a domain you can explain, and describe how you labeled or collected it
• Report per-class results, not only overall accuracy, especially if classes are imbalanced (the article on precision and recall with class imbalance shows why accuracy misleads)
• Show examples the model gets wrong and explain why
• State the limits, such as language, domain, and data age

Project 5: a business-impact case study

This is the most persuasive type because it connects the model to a decision and an outcome. The strongest version has a real problem, a measured result, and an honest account of what was and was not proven.

Here are three illustrative framings. They are hypothetical examples of the form, not claims about real results:

• "I built a churn model for a small online shop and tested a retention offer on a random half of the flagged customers. The offered group retained at a rate X points higher than the control."
• "I forecasted weekly demand for a friend's restaurant and compared the model against their ordering habit over several weeks, tracking discarded food."
• "I scraped competitor prices daily and built a dashboard that flags changes, and I tracked which alerts led to a pricing decision."

Notice the word "control" in the first example. A before-and-after comparison cannot tell you whether the model caused the improvement, because other things change over time. A randomized comparison can. The explainer on why randomized trials are powerful explains why, and it is the single most valuable idea for this type of project.

If you cannot get a real client, use a clearly labeled synthetic scenario with stated assumptions. Say plainly that the data is simulated, say how you generated it, and do not report a result as if it were real. Honest labeling reads as maturity. Blurring simulated and real results is the quickest way to lose a reader's trust.

---

A GitHub structure that looks professional

A messy repository makes a reader doubt your code before they read it. A consistent layout signals that you can work with others.

house-price-prediction/
├── data/
│   ├── raw/            # Original data (or a link and download script)
│   └── processed/      # Cleaned data
├── notebooks/
│   ├── 01_exploration.ipynb
│   ├── 02_cleaning.ipynb
│   └── 03_modeling.ipynb
├── src/
│   ├── data_processing.py
│   ├── features.py
│   └── models.py
├── reports/
│   └── figures/        # Saved plots
├── README.md
├── requirements.txt
└── LICENSE

Keep large or licensed data out of the repository and provide a script or link to fetch it. Pin your dependency versions so the project runs next year as well as today. Put reusable logic in src/ and keep notebooks for exploration and narrative.

What the README must contain

The README is the page most visitors will read, and many will read only the top. Write it for someone who has two minutes.

1. Problem statement. One paragraph on what you tried to answer and why anyone would care.
2. Approach. A few bullets on data, features, models, and the validation scheme.
3. Results. Numbers, with the baseline beside them.
4. Limitations. What the project does not show.
5. How to reproduce. Installation and the commands to run.
6. Figures. Two or three charts inline.

Use a template with placeholders so you never publish numbers you have not measured:

## House Price Prediction: King County, WA

Predicts residential sale prices from [N] transactions ([date range]).
Baseline (always predict the mean): RMSE = [X].
Best model ([model name]): RMSE = [Y], a [Z]% reduction versus baseline.

Main finding: [one sentence about the most useful insight].
Limitations: [data period, geography, features not available].

Every bracket should be replaced by a number you can regenerate by running the repository. Anything else is a promise you cannot keep if a reader tries to reproduce it.

---

Writing about your work

Writing shows a reader how you explain things, which is a core job skill. Three to five posts is plenty, and they do not need to go viral.

Reasonable places to publish include your own site or GitHub Pages, Medium, Dev.to, and Substack. Pick one you will actually maintain. A post on a personal site you control can outlast a platform's changes.

Post ideas that work:

• "Why I chose gradient boosting over a neural network for this dataset"
• "The messiest data I have cleaned, and the decisions I made"
• "What my baseline taught me about my model"
• "Where my forecast broke, and what I learned"

A good post follows the same shape as a good README, with more room for the reasoning. State the question, show the evidence, admit the limits. Posts about a failure or a surprise are often more convincing than posts about a clean win, because they show you checked your work.

---

Metrics that persuade and metrics that mislead

Numbers help only when a reader can judge them. Always give a comparison.

Persuasive metric statements share a pattern: a number, a baseline, a data split, and a scale. For example: "On a held-out test set of N rows, the model reached RMSE X against a baseline of Y." The details are placeholders here because your numbers will differ.

Weak statements are vague: "the model performed well," "accuracy improved significantly," "used state-of-the-art techniques," or "built a complex pipeline." None of them can be checked.

Why accuracy can mislead

Suppose 9% of customers churn and 91% stay. A model that predicts "stays" for every customer is right 91% of the time and finds no churners at all. The accuracy looks impressive and the model is useless. This is why you report the baseline next to your number, and why imbalanced problems call for metrics such as precision and recall.

Model	Accuracy	Churners found
Always predict "stays"	91%	0 of 9 in every 100
A model that finds 6 of those 9 and wrongly flags 5 loyal customers	100 − 3 − 5 = 92%	6 of 9

The second model is only one point better on accuracy and far more useful. That is why raw accuracy should never be the only number in your README. The numbers in the table are a worked arithmetic illustration, not results from a real model.

Report uncertainty

A single score from one split can be luck. Cross-validation gives a mean and a spread, as in the first project's code. If two models differ by less than the spread, say so instead of declaring a winner. That small act of honesty is a mark of someone who understands what the numbers mean.

---

A realistic timeline

How long this takes depends on your starting point, your schedule, and how much help you have. Treat the table as a sequence, not a promise.

Stage	Focus
Foundations	Python, Pandas, and basic scikit-learn
First project	End-to-end prediction with a baseline
Writing	A post about the first project
Second project	Messy real-world analysis
Third project	Time series or a specialty of your choice
Polish	README cleanup, tests, a small deployment
Applications	Apply while you keep building

Notice that applying comes before you feel finished. A portfolio is never complete, and waiting for perfection delays the feedback that would improve it. For a roadmap of the skills underneath and a comparison of the main languages, see the related articles at the end.

---

Common portfolio mistakes

Only the classic tutorial datasets. Iris, Titanic, and MNIST are everywhere because they teach well. A reader who has seen a hundred of them learns little from a hundred and first. Use them to practice and feature something else.

No README. A repository with only notebooks makes the reader do your explaining. Many will not.

No explanation of decisions. "I used a random forest" says little. "I used a random forest because the relationships look non-linear and the dataset is small enough that a deep model has little advantage" shows your thinking.

Only one problem type. Mix regression, classification, forecasting, and perhaps clustering. Range shows you are not tied to one recipe. A model such as XGBoost is a good tool, and a project where you explain when it is the wrong tool is better still.

Copying tutorials exactly. Change something meaningful, such as the dataset, the validation scheme, or an engineered feature.

Leaking test data. Scaling or selecting features on the full dataset before splitting inflates your score. It is among the most common errors in beginner projects, and reviewers know to look for it.

Unreproducible work. If the code needs a file you never shared or a package version that no longer exists, a reviewer cannot run it. Test your repository on a clean machine or a fresh virtual environment.

---

Deploying at least one project

A deployed project shows you can finish the last mile. Deployment can be small: a Streamlit app, a FastAPI endpoint, or a notebook published with a live demo. The aim is to show that a stranger can use your model without installing anything.

When you deploy, think about what can go wrong after launch. Inputs may differ from training data, a service may fail, and a model's accuracy may decay as the world changes. The beginner MLOps guide introduces monitoring and retraining. You do not need a full production system, but a README section titled "What I would monitor if this were live" shows you have thought about it.

Another route into the same skills is web development, since a deployed project is a small web app. The article on web development portfolio projects covers the parallel for that field.

---

Preparing to talk about your projects

A project becomes a stronger asset when you can discuss it. Interviewers often ask about portfolio work to see whether you understand it, so prepare to answer these questions about each project:

1. What question were you trying to answer, and who would use the answer?
2. Where did the data come from, and what is missing from it?
3. What was your baseline, and how did the final model compare?
4. How did you validate, and what could have gone wrong with that choice?
5. What would you do with another week? With another year?
6. What would convince you the result is wrong?

If you can answer all six without opening the notebook, you understand the project. If you cannot, spend time on the gaps before you add another project. Depth in three projects is worth more than a surface knowledge of ten.

---

FAQ

Q: How many projects do I need? A: Three well-documented projects are a sound target, with a fourth or fifth if you want to show a specialty. Quality matters more than count, because each project is a sample of how you work.

Q: Should projects come from competitions or original ideas? A: Both can work. Competitions give you a clear metric and a leaderboard, and original projects show initiative and the ability to frame a problem. A mix lets you show both, and you should explain your choices either way.

Q: Do employers check code quality? A: Many reviewers skim the repository, so readable, documented code with a clear README helps. Consistent style, type hints where useful, and docstrings signal care. A reviewer who cannot run your project is unlikely to give you the benefit of the doubt.

Q: Should I deploy my models? A: A simple deployment, such as a Streamlit app, shows you can finish a project and make it usable. It is not required for every project, but one deployed example is a useful addition.

Q: Can I use datasets that everyone else uses? A: Yes, for practice and for a first project, if you add something of your own such as a new validation scheme, an engineered feature, or an error analysis. For the featured projects, a less common dataset makes you easier to remember.

Q: What if I do not have a degree in the field? A: The BLS notes that a bachelor's degree is the typical entry-level education and that some employers prefer higher degrees. A portfolio cannot replace a requirement an employer has set, but it can show skills a degree line does not. Check the requirements of the roles you target.

---

Sources

• U.S. Bureau of Labor Statistics, Data Scientists, Occupational Outlook Handbook: bls.gov/ooh/math/data-scientists.htm
• scikit-learn documentation, cross-validation, data leakage, and TimeSeriesSplit: scikit-learn.org/stable/modules/cross_validation.html
• Hyndman and Athanasopoulos, Forecasting: Principles and Practice, forecast accuracy: otexts.com/fpp3/accuracy.html
• Prophet documentation, quick start: facebook.github.io/prophet/docs/quick_start.html
• NYC Open Data: nyc.gov/opendata
• NOAA Climate Data Online: ncei.noaa.gov/cdo-web
• Johns Hopkins CSSE COVID-19 Data Repository: github.com/CSSEGISandData/COVID-19
• King County house sales dataset documentation: search.r-project.org

---

Related Articles

• Complete ML Learning Path 2026
• ML Job Market in 2026 — Salary, Requirements, Best Companies
• Python vs R for Data Science

---

Bottom Line

Three honest, well-documented projects beat ten flashy ones.

Show your work. Use real data, compare against a baseline, state your limits, and explain your decisions in plain language. A reader who can reproduce your result and understand your reasoning has what they need to say yes.

Last verified: October 2026