Why Beginner Data Science Projects Look Different in 2026
The beginner project bar has moved. Five years ago, a Titanic survival notebook and an Iris classifier were enough to earn a nod from a recruiter. In 2026, hiring managers open your GitHub with a very different checklist: did you handle a real, messy dataset; did you write code someone else could run; did you ship something (even a tiny Streamlit app) rather than just plotting inside a notebook; and, increasingly, did you use an LLM sensibly rather than pretending you did not.
That shift is not about difficulty. It is about signal. The commodity notebooks are now generated in seconds by ChatGPT, Claude, and Copilot, and every reviewer knows it. What still cannot be faked is the judgment behind a project: choosing the right question, cleaning data you did not create, defending your metric choice, and explaining what the model actually learned. Those are the exact skills that separate a beginner who will grow from one who will stall.
This guide is written for people building their very first three to six data science projects in 2026. It is opinionated on purpose. You will not find twenty vague ideas here. You will find a scoped progression, from a first exploratory analysis to a small deployed model, with the reasoning behind each choice so you understand why one project belongs in a portfolio and another does not.
A few working assumptions before we start. You know a little Python (functions, pandas, matplotlib) or you are willing to learn as you build. You have used Jupyter or VS Code. You have a GitHub account. If any of that is missing, do not panic, do the first project anyway and pick up the tooling as friction forces you to. This is how every practitioner actually learned, and Refonte Learning teaches it the same way: build first, then generalise.
We will move through six project archetypes in order of increasing sophistication: an exploratory data analysis (EDA), a SQL-driven analytics report, a supervised machine learning classifier, a time-series forecast, a small NLP project, and a lightweight deployed app. For each, you will see how to scope it (avoid the classic beginner mistake of choosing something twelve weeks too big), which dataset genres actually make sense, what the deliverable looks like, and the specific portfolio artefacts to produce. You can find worked examples and code across the Refonte Learning data science projects hub, which is a useful companion as you build.
One meta-point before the projects. Do not build six unrelated pieces. Choose a domain you find genuinely interesting (climate, football, personal finance, public health, gaming, transit, music) and let three or four of your projects share that domain. A recruiter who sees you produce an EDA, a SQL report, a classifier, and a forecast on New York transit data reads "specialist in the making." A recruiter who sees six disconnected Kaggle rehashes reads "followed a tutorial list." The signal difference is enormous.
Project 1: A Real Exploratory Data Analysis (Not a Cleaned Kaggle CSV)
Your first project should be an honest exploratory data analysis. The purpose is not to build a model. The purpose is to prove you can take a dataset you did not curate, form questions about it, and answer those questions with code and charts a non-technical reader can follow.
Avoid the pre-cleaned Kaggle darlings (Titanic, Iris, Boston Housing, the wine quality dataset). Every reviewer has seen them hundreds of times, and they teach you almost nothing about the actual work of EDA because someone already did the hard part. Instead, source raw data from a government or civic portal: data.gov, the UK ONS, Eurostat, the World Bank, NYC Open Data, or your city's equivalent. These datasets have missing values, inconsistent categories, weird encodings, and columns nobody documented. That is the point.
Scope tightly. "Analyse climate data" is not a project. "How has the number of days above 30 degrees Celsius changed in Lyon between 2000 and 2024, by month?" is a project. A good beginner EDA answers three to five specific questions, each with a chart and a paragraph of interpretation. That is the whole deliverable.
Structure your notebook the way a report is structured, not the way a REPL session grows. Section one: the question and why it matters. Section two: the data source, what it contains, and what its limits are (this is the section every beginner skips and every reviewer looks for). Section three: cleaning, with each decision explicitly justified in a markdown cell. Section four: the questions, each with the chart and the answer. Section five: what you would do next with more time.
On tooling, stick to pandas, matplotlib or seaborn, and Jupyter. Do not reach for Plotly or Streamlit yet, they will distract you. Do use df.info(), df.describe(), and df.isna().sum() early and often. Do write your cleaning code in functions with docstrings, not as thirty stray cells. This one habit alone puts you ahead of most bootcamp graduates.
Common failure modes for a first EDA: too many charts (fifteen histograms of everything, no interpretation), no data-quality section (the reviewer cannot trust your numbers), and "insights" that are actually just descriptions ("the average is 42" is not an insight, "the average is 42 which is 3x higher than the national benchmark of 14 because of X" is). Fix those three and your first project already looks senior.
Budget: one to two weekends. If you are still on it after three, you have scoped too big, cut a question.
Project 2: A SQL-First Analytics Report
Your second project should be built primarily in SQL, not Python. This surprises beginners who assume data science means pandas. In reality, most working data scientists write more SQL than Python, and every entry-level analytics job tests it. A SQL project also proves you can think in sets, joins, and window functions, which is a completely different mental model from row-by-row pandas.
Pick a dataset with at least three tables that need to be joined. The Chinook music store database, the Sakila DVD rental database, Northwind, or any of the public BigQuery datasets (GitHub Archive, Stack Overflow, NYC taxi trips) all work. If you already used your city's transit or climate data for Project 1, see whether it comes in a relational form you can load into DuckDB or Postgres locally. DuckDB in particular is a gift for beginners in 2026: it reads CSV and Parquet directly, runs standard SQL, and needs no server.
The deliverable is a written analytics report answering a business-flavoured question. Examples: "Which product categories drive the top 20% of revenue, and how has that concentration changed over the last three years?" Or "Which pickup neighbourhoods have the highest average tip percentage on Friday nights, controlling for trip distance?" The report should include the question, the query (readable, formatted, commented), the result table or chart, and a short interpretation. Repeat for five to eight questions.
Deliberately practice the SQL patterns that show up in interviews: inner and left joins, GROUP BY with HAVING, window functions (ROW_NUMBER, RANK, LAG, LEAD, running totals), CTEs for readability, and date arithmetic. If a query grows past twenty lines without a CTE, refactor it. A reviewer reading WITH monthly_revenue AS (...), category_share AS (...) SELECT ... sees someone who can already write maintainable code.
Write the report as a markdown file in the repo, not a slide deck. Include the SQL inline in fenced code blocks. If you want to level up, load the results into a small pandas dataframe at the end and produce two or three charts, but keep the analytical work in SQL. This is exactly the workflow used at real companies: SQL to shape the data, Python only for what SQL cannot do.
A thorough grounding in the language pays off far beyond this project. If you want to go deeper on patterns and interview-grade queries, the Refonte guide to SQL for data science walks through the exact constructs that come up in analyst and data scientist screens.
Budget: one weekend for the queries, one evening for the writeup.
Project 3: A Supervised Machine Learning Classifier With Honest Evaluation
Project three is your first predictive model. The temptation is to reach for XGBoost or a neural network immediately. Resist it. The point of this project is not the model, it is the evaluation. A beginner who ships a logistic regression with a proper train-validation-test split, a confusion matrix, and a calibration plot is more employable than one who runs AutoML on the same dataset and reports 0.99 accuracy without understanding why that number is meaningless.
Good beginner classification datasets: churn prediction (Telco churn from Kaggle is fine here because the interest is in your methodology), loan default, spam vs ham email, review sentiment (positive/negative), or bike-share demand thresholded into high/low. Pick one where the class balance is genuinely imbalanced (say 20/80 or worse), because handling imbalance is one of the most important beginner lessons.
Structure the notebook as a real ML pipeline. First, EDA focused on the target: how balanced are the classes, which features correlate with the target, are there obvious leakage risks (a common trap, e.g. a last_contact_date feature that only exists for customers who did not churn). Second, a train-validation-test split done once at the top, before any feature engineering, so you cannot leak. Third, a baseline: predict the majority class and report accuracy, precision, recall, F1. Any model you build later must beat this baseline meaningfully.
Then build two or three models in ascending complexity: logistic regression, a random forest, and optionally gradient boosting (XGBoost or LightGBM). For each, report the same metrics on the validation set. Choose your final model based on the metric that matches the business problem, not accuracy by default. For churn, recall on the churn class often matters more than overall accuracy. Explain this choice in the notebook.
Evaluate honestly. Include a confusion matrix, a precision-recall curve, and a ROC curve. If your dataset is imbalanced, always show precision-recall, not just ROC. Run your final model on the test set exactly once at the end and report those numbers as the honest performance. If you tune hyperparameters, do it with cross-validation on the training set only.
The portfolio artefact is the notebook plus a one-page README summarising: the problem, the metric you optimised, the baseline, the final model, its test-set performance, and its limitations. That last section (limitations) is where beginners can most easily look senior, because most portfolios pretend the model is perfect. Yours will say "this model has high recall on churners but precision of only 0.42, which means for every true churner we flag we also flag 1.4 false positives, this would need to be weighed against the cost of a retention offer." That sentence changes how a reviewer sees you.
For worked references you can study end to end, browse the collection of data science projects with source code and read the evaluation sections closely, not just the model code.
Budget: two weekends.
Project 4: A Time-Series Forecast You Would Actually Trust
Your fourth project moves into time-series forecasting, and it teaches a very different discipline. Cross-sectional ML lets you shuffle your data. Time series does not. Get the split wrong and you leak the future into the past, producing beautiful validation curves that mean nothing. Learning to avoid this is worth the whole project on its own.
Good beginner time-series datasets: daily bike-share rentals, hourly electricity demand for a region, daily air quality for your city, weekly retail sales, daily website traffic (if you have your own). Avoid stock prices as your first forecast, they are close to random walks and will teach you the wrong lessons about model performance.
Start with visualisation. Plot the series. Look for trend, seasonality (daily, weekly, yearly), obvious anomalies (COVID lockdowns still show up as huge dislocations in almost every 2019-2022 dataset, treat them explicitly). Decompose the series with statsmodels' seasonal_decompose or STL. This visual step is often skipped and it is where the modelling decisions actually come from.
Build three forecasts in ascending sophistication. Baseline: naive seasonal (this week equals last week, or today equals seven days ago for weekly seasonality). This is not a joke, naive seasonal beats a lot of fancy models on well-behaved series and it is the honest bar to clear. Second: a classical model, either ARIMA/SARIMA or exponential smoothing (Holt-Winters). Third: a feature-engineered regression model where you extract calendar features (day of week, month, holiday flag, lag features) and fit a gradient booster on them. This last approach, sometimes called "reframing forecasting as regression," is what most production forecasting systems actually do in 2026.
Evaluate with a rolling-origin (walk-forward) cross-validation, not a random split. This means you train on data up to time t, forecast t+1 to t+h, roll forward, and repeat. Report MAE and MAPE (or sMAPE if you have zeros). Include a plot of forecast vs actual on the held-out period. If you are forecasting more than a few steps ahead, also include prediction intervals, not just point forecasts, and explain what the interval means.
A great writeup finishes with a section on what would go wrong in production. What happens if there is a new holiday your model has not seen? What happens if the underlying trend breaks (a new competitor, a policy change)? How would you monitor forecast quality over time? Answering these puts you in a different league from beginners who stop at the plot.
Project 5: A Focused NLP Project (Not Another Sentiment Classifier)
Project five should touch text data, because in 2026 an alarming number of data science tasks involve unstructured text, and because working with language teaches you tokenisation, embeddings, and evaluation subtleties that will come back everywhere.
Do not build a generic sentiment classifier on IMDB reviews. It has been done, the accuracy ceiling is well known, and it teaches almost nothing about real NLP work. Instead, pick a focused text problem tied to your chosen domain. Some good beginner options: classify GitHub issues into bug/feature/question, cluster BBC news headlines into topics and label the clusters, extract structured information (dates, prices, locations) from classified ads, or build a semantic search over a corpus you care about (your favourite podcast transcripts, a book series, product reviews).
Semantic search is a particularly good 2026 beginner project because it directly uses the embedding models that power modern LLM applications, without requiring you to fine-tune anything. The pipeline: chunk your documents, embed each chunk with a small open-source model (sentence-transformers all-MiniLM-L6-v2 runs on a laptop), store the embeddings in a lightweight vector store (FAISS, Chroma, or even a numpy array for a first version), and at query time embed the question and return the top-k most similar chunks. That is a working retrieval system. Add a Streamlit UI on top and you have a demoable project.
If you go the classification route, use a modern baseline. TF-IDF plus logistic regression is still a shockingly strong baseline for text classification and takes ten lines of scikit-learn. Compare it against a small transformer (a fine-tuned DistilBERT) and honestly report the tradeoff: the transformer probably wins by a few points of F1, at the cost of much longer training and inference. Understanding when the extra complexity is worth it is the actual skill being demonstrated.
Whichever route you choose, spend real time on evaluation. For classification, do not just report accuracy, look at per-class F1, examine the confusion matrix, and manually inspect twenty misclassified examples. That last habit, error analysis by hand, is what senior practitioners do and juniors skip. Write a section in your README titled "where the model fails and why," with three or four concrete example rows.
Because Python is the working language for almost all of this, keep sharpening it in parallel. The Refonte piece on Python projects for data science beginners has smaller Python-first exercises that complement a larger NLP build.
Budget: two to three weekends. Semantic search takes the least time to a working demo, which is why it is a great pick if you want a fifth project you can actually finish.
Project 6: A Small Deployed App (Where Most Beginners Never Go)
Your sixth project is the one that changes recruiter reactions the most, because almost no beginner does it. Take one of your earlier models (the classifier or the semantic search work well) and deploy it as a small web app people can actually use.
The simplest 2026 stack: wrap your model in a Streamlit or Gradio app, containerise it with Docker, and deploy to Hugging Face Spaces, Streamlit Community Cloud, or Fly.io. All of these have free tiers. The URL you get back, https://your-username-your-project.hf.space, goes at the top of your README and at the top of your CV. A live link is worth ten notebooks.
Keep the UI dumb-simple. One or two inputs, one output, one chart. Do not build a dashboard. The point is to demonstrate you can move a model out of a notebook and into something a stranger can interact with. That single act touches skills notebook-only beginners never develop: serialising a model (joblib or ONNX), writing an inference function that handles bad input gracefully, thinking about latency, and considering what happens when two users hit your app simultaneously.
Add basic hygiene. A requirements.txt or pyproject.toml with pinned versions. A README with a screenshot, the live URL, the problem statement, and a "how it works" section. An .gitignore that excludes data and model artefacts if they are large (use Git LFS or a cloud bucket instead). Environment variables for anything secret, never hardcoded API keys.
Go one step further and add a tiny bit of observability. Log every prediction request (input, output, timestamp, latency) to a file or a free-tier hosted database. After a week of use, produce a chart of usage over time and average latency. This turns your project into a story: "I built it, I shipped it, I watched it run, here is what I learned." That arc is what hiring managers are actually buying.
If the app is a classifier, include a feedback button ("was this prediction correct?") and log the responses. You now have a tiny loop that could, in principle, retrain the model on real feedback. You do not have to implement retraining, just noting it in the README shows you understand the full lifecycle.
For a fuller walkthrough of how to convert a raw project into portfolio-grade artefacts, the Refonte guide on building real-world data science projects to boost your portfolio is worth reading before you start Project 6, not after.
How to Package Every Project So It Actually Gets Read
A finished project that lives in an unlabelled GitHub repo with a default README is almost invisible. Ten minutes of packaging can multiply the impact of every project on this list. Do the ten minutes.
Every repo needs a README with the same six sections in the same order. What problem does this solve, and for whom. What data was used and where it came from (with a link). What methods were tried and why. What the results were, honestly, including a metric and a comparison to a baseline. What the limitations are. How to reproduce (clone, install, run these commands). If your project has a live demo, put the URL in the very first line under the title.
Add one hero image at the top of the README. A chart, a screenshot of your app, a confusion matrix, anything visual. Recruiters skim on mobile. A repo without a visual gets scrolled past. A repo with a clean chart gets clicked.
Pin your best three or four projects on your GitHub profile. Not your best twenty, your best three or four. Reviewers spend less than sixty seconds on a profile. Curate ruthlessly. The projects that do not make the cut can stay in the repo list, just not pinned.
Write a short blog post per project on Medium, dev.to, or your own site. Two thousand words is enough. Same six-section structure as the README, more narrative, one or two extra charts. Link the post from the README, and link the repo from the post. This cross-linking is what gets your work found through search rather than only through direct-link sharing.
On LinkedIn, post once per finished project. Not a screenshot dump, a short story: what you set out to answer, the one surprising thing you found, and a link. Do not fish for likes. The goal is that six months later, a recruiter searching "churn prediction beginner" or "NYC transit analysis" finds your name.
Finally, keep your commits honest. A repo with one giant commit "initial commit" reads like a dump. A repo with twenty commits showing the actual arc of the work ("add EDA notebook," "clean missing values in fare column," "add baseline model," "add cross-validation," "add README") reads like real work. It also protects you in interviews, because your commit history matches your ability to talk about what you did.
Datasets, Tools, and the Environment Choices That Matter in 2026
A quick tour of the tooling ground truth for beginners in 2026, so you do not waste weeks choosing.
For data sources, prefer public government portals (data.gov, ONS, Eurostat, INSEE, NYC Open Data), the World Bank open data catalogue, official APIs (GitHub, Wikipedia, OpenWeatherMap, Spotify), and the Hugging Face Datasets hub for text and multimodal data. Kaggle is useful for practice but overrepresented in portfolios, so treat Kaggle datasets as training grounds, not portfolio pieces, unless you do something genuinely different with them.
For Python, use uv or pipx to manage your environments in 2026, they are dramatically faster than pip plus venv and are becoming the default. Stick with Python 3.11 or 3.12 for compatibility with the scientific stack. Your core beginner toolkit is small: pandas, numpy, matplotlib, seaborn, scikit-learn, statsmodels, and Jupyter. Add DuckDB for local SQL, sentence-transformers plus FAISS for embeddings, and Streamlit or Gradio for demos. That is enough for every project in this guide.
If a project starts to feel slow on pandas (many gigabytes), do not immediately jump to Spark. Try Polars first, it is a drop-in-ish DataFrame library that handles larger data on a single machine and is often ten times faster than pandas. Learning Polars in 2026 is a small investment with a big payoff.
For version control, Git and GitHub, no exceptions. Learn the seven commands you actually need (clone, add, commit, push, pull, branch, merge) and ignore the rest until you need them. For notebooks, install nbstripout so you do not commit output cells full of images, it keeps diffs readable and repos small.
For writing code with LLM assistance, use it, do not hide it, but never paste output you do not understand. In interviews, you will be asked to explain lines of your own code. The single fastest way to fail a technical screen in 2026 is to have LLM-generated code in your repo that you cannot walk through. Treat Copilot and Claude as pair programmers who occasionally lie: helpful, but every suggestion gets verified.
For compute, your laptop is enough for every project in this guide, including the small transformer fine-tune in Project 5 (DistilBERT trains in under an hour on a modern laptop CPU, faster on any GPU). If you want free GPU time, Google Colab and Kaggle Notebooks both offer it. Do not spend money on cloud compute as a beginner, you do not need to.
What Not to Build, and Why
A short list of projects that look tempting and consistently underperform on portfolios in 2026. Not because they are bad ideas in the abstract, but because they either fail to differentiate you or teach the wrong lessons.
Stock price prediction. The signal-to-noise ratio is brutal, your model will look great in-sample and fail out-of-sample, and every reviewer knows this. If you insist, frame it as a volatility forecasting or regime detection problem instead of price prediction, which is a genuinely interesting question.
A chatbot wrapped around the OpenAI API with no domain data. In 2026, this takes an afternoon and demonstrates almost nothing about your data skills. If you want to build with LLMs, do retrieval-augmented generation over a specific corpus (see Project 5), where the interesting engineering is in the retrieval, not in calling the API.
A generic recommender system on the MovieLens dataset. Overdone. If recommenders interest you, build one on a niche dataset (board games, books in a specific genre, local restaurants) where you have opinions about what "good" recommendations look like and can defend your evaluation.
A COVID dashboard. The moment has passed, the datasets are stale, and the space is saturated. If public health interests you, look at more recent datasets: air quality, hospital readmission data, mental health surveys.
Any project where the model is doing something ethically fraught (predicting criminality from faces, guessing salary from name, inferring sexual orientation from any signal) even as an exercise. These come up because they appear in old tutorials. In 2026, showing that you would build such a system is a negative signal, no matter how good the code is. Pick a different problem.
And finally, a project that is really just a re-run of a well-known tutorial with the variable names changed. Reviewers can spot these instantly, because they have seen the same charts a thousand times. If you do a tutorial to learn, that is fine, do the tutorial, then throw it away and build something adjacent from scratch on a different dataset. The rebuild is the portfolio piece, the tutorial is the practice.
From Six Projects to Your First Data Role
Six well-scoped projects, packaged as described, is enough to start applying for junior data analyst, junior data scientist, and data science internship roles. It will not be enough on its own, you also need to grind interview prep (SQL puzzles, statistics fundamentals, one algorithmic screen for the rare company that still does them), but the portfolio removes the biggest bottleneck, which is getting past the initial screen.
Use each project as a story. Interviewers almost always ask, "tell me about a project you are proud of." You want three to four minutes ready per project, structured as: the question, the data and its problems, what you tried and why, the result, and what you would do differently. Rehearse this out loud. Reading it in your head is not the same, and you will be surprised how much smoother your fifth telling is than your first.
Do not wait until all six projects are finished to start applying. Start applying after project three, keep building four, five, and six while you interview. Every rejection is data. If interviewers keep asking about deployment and you have no deployed project, that is your signal to prioritise Project 6. If they keep asking about SQL and you fumble window functions, that is your signal to add another SQL-first analysis.
Seek feedback aggressively. Post your repos in relevant Discord and Slack communities and ask for specific critique ("is my evaluation section honest, is my README clear to a non-technical reader"). Find a mentor, formally or informally, who works in the field and will look at one project a month. Structured programs, including the Refonte Learning Data Science Program, exist specifically to compress this feedback loop, pairing you with practitioners who review your code and your writeups the way a hiring manager would, then coaching you through the fixes.
Beyond the six projects, keep learning in public. A short weekly note on what you learned, a small script shared as a gist, a chart posted with a paragraph of interpretation, all of these compound. Six months of consistent small outputs, layered on top of six real projects, will get you noticed in a way that a single burst of activity never does.
Closing: Build Small, Ship Real, Explain Everything
The beginners who succeed in 2026 are not the ones who have read the most, or watched the most videos, or collected the most certificates. They are the ones who shipped six honest projects, packaged them well, and can talk about every line of code and every metric choice. That is a genuinely achievable bar. The projects in this guide are the ones that consistently produce that outcome, in the order that has worked best for the students Refonte Learning has coached into first data roles.
Start today with Project 1. Pick a dataset from your city's open data portal. Ask three specific questions. Answer them in a notebook with a real README. Commit it to GitHub. That is the first move. Everything else follows.
When you are ready for structured guidance, code review, and a curriculum designed around exactly this project progression, explore the Refonte Learning Data Science Program, and start building the portfolio that turns "beginner" into "hired."