If you are a fresher applying for data analyst or data science roles, your projects do the job that work experience does for everyone else. A list of tools tells a reader what you have heard of. A well-written project shows what you can actually do with data.
Many fresher project sections name a famous dataset, list five libraries and end with "gained insights". Nobody can tell what was asked, what was found, or which part the candidate did. Here is how to fix that.
The five facts every project entry needs
Each project should answer five questions in two to four lines. If a reader can't find one of these, they will assume the weakest version.
| Fact | What to write | Example phrase |
|---|---|---|
| Question | The decision or problem the analysis was for | "Which delivery zones had the most late orders?" |
| Data source | Where the data came from and roughly how much | "Public dataset, about 1 lakh rows" |
| Method and tools | What you did, named with the tools you used | "Cleaned in Python (pandas), aggregated in SQL" |
| Result | What you found or built, with a number only if you measured it | "Three zones accounted for most late orders" |
| Your part | What you did yourself, especially in a team | "I wrote the SQL queries and built the dashboard" |
The last row matters most in team projects. Say which part was yours. Describe the team's outcome as the team's outcome.
Before and after: one project rewritten
This is an illustrative example. Kavya is a fictional B.Sc Statistics graduate from Coimbatore applying for junior analyst roles.
Before:
- Sales Analysis Project | Python, SQL, Excel, Power BI, Machine Learning
- Performed end-to-end analysis on sales data and gained valuable business insights. Improved sales by 20%.
The tool list includes machine learning, but nothing below uses it. "Improved sales by 20%" can't be true, because no business ever acted on the analysis. An interviewer will ask about both.
After:
- Retail sales analysis (individual project, public dataset), 2025 | Python, SQL, Power BI
- Asked which product categories drove falling monthly revenue in a public superstore dataset (about 10,000 order rows).
- Cleaned missing and duplicate records in pandas, then wrote SQL queries to compare revenue and discount by region and category.
- Built a three-page Power BI report showing that heavy discounts in two categories matched lower profit per order. Code and a README are linked on GitHub.
Every line in the second version can be checked. It names the data, shows the method and states a finding without claiming business impact.
Same story. A little more breathing room.
Switch the layout. Watch how spacing and hierarchy change the way this sample reads.
Alex Morgan
Product designerProfile
Product designer focused on making complex workflows easier to understand.
Experience
Product Designer · Example Studio
- Mapped the onboarding journey with the support team.
- Designed and tested a clearer account setup flow.
- Documented reusable components for the engineering team.
Skills
Interaction design · Prototyping · Design systems
Everything is asking for attention.
Closely packed headings and text leave fewer visual signposts. Try the other treatment.
Label the data honestly
Recruiters and interviewers ask where your data came from. Put the answer on the page first.
- Public data. Kaggle datasets, government portals and published research data. India's Open Government Data platform, data.gov.in, states that its content is licensed under the Government Open Data License – India. Name the source in the entry or the README.
- Synthetic data. Data you generated or a generator created. Say "synthetic" plainly. Never describe generated rows as real customer or patient records.
- Confidential data. Data from an internship, a family business or a college office. Describe the work, not the data. Don't upload it to GitHub or paste figures that belong to someone else. If you are unsure whether you may share it, ask the person who gave it to you.
A line such as "internship project, company data not shared" is enough. It tells the reader why there is no link.
Kaggle, course capstones and guided projects
These are all fair evidence if you label them.
- Kaggle competitions. Write the competition name and your actual result, such as your public leaderboard rank out of the number of teams. If you only submitted a starter notebook, it is a practice project, not a competition result.
- Course capstones. Name them as capstones: "Capstone project, online data analytics course". A capstone where everyone used the same dataset and brief is still useful. Show what you did differently, such as an extra question you asked or a check you added.
- Guided or tutorial projects. If you followed a video line by line, don't present it as original work. Extend it first. Use a different dataset, answer a new question or add a test. Then describe your extension.
- College projects. Say whether it was individual or team work.
Show tools through the work
A skills line of "SQL, Excel, Python, Power BI" is easy to write and hard to believe. Tie each tool to a project line where you used it.
- SQL: the kind of queries you wrote, such as joins across tables, grouping and window functions, and on what data.
- Excel: pivot tables, lookups or data cleaning on a named file, not "advanced Excel".
- Python: the libraries and what they did, for example pandas for cleaning and matplotlib for charts.
- Power BI or Tableau: what the report showed and who it was for, even if the "user" was your faculty guide.
- Statistics or machine learning: the method and how you checked it, such as a train–test split and the metric you used. Include a model only if you can explain why you chose it.
Keep the skills section, but make sure each skill appears in a project.
Make GitHub links worth clicking
A GitHub link helps only if the repository explains itself. GitHub's own documentation describes the README as the place to tell people what a project is about.
Before you add a link, check the repository:
- The README states the question, the data source, how to run the code and the main finding.
- The data is either included under its licence or linked, and nothing confidential is committed.
- Notebooks run from top to bottom and show their outputs.
- The link on the resume is written in full, so it works on a printed page.
One strong repository beats ten forks with no README.
Claims to cut
These phrases invite questions you can't answer well:
- Business impact that never happened. "Increased revenue by 15%" on a practice dataset. Write what you found, not what a business might have gained.
- Accuracy with no context. "98% accuracy" without the metric, the test data or the baseline. On unbalanced data, high accuracy can mean very little.
- Inflated titles. "Data Scientist" for a course project. Use the project name, not a job title.
- Solo credit for team work. Say "team of four" and name your part.
An honest, modest project that you can explain for ten minutes in an interview does more for you than an impressive one you can't defend.
Where projects sit on the page
For a fresher, a common order is a short summary, then education, then projects, then skills. If you have a relevant internship, it can go above projects. Choose two to four projects that match the roles you apply for, and put the strongest first.
Use a plain "Projects" heading in the main column. Keep dates, labels and links as text, not inside images. For more on layout and education lines, see Fresher resume ATS notes for India, and for placement drives, read the campus placement resume guide.
Your experience. A fresh canvas.
Try a different look. These are actual Guul template previews, with illustrative sample content.
A clean slate. Literally.
One column, distinct sections, and room for your experience to lead. A simple place to start.
Make this layout yours ↗The builder opens with your selected template.Replace all sample details with your own experience.Explore the resume lookbook →
Checklist before you send
- Each project states the question, data source, method, result and your part.
- Every dataset is labelled public, synthetic or confidential.
- Kaggle, capstone, tutorial and college work is named as such.
- Every tool in your skills section appears in at least one project.
- No number appears that you did not measure yourself.
- Each GitHub link opens a repository with a clear README and no private data.
- Team projects say what you personally did.
When you are done, you can run the draft through Guul's resume checker, which explains each finding in plain words. If you are applying to a specific opening, tailoring the resume to the job description shows which skills the posting asks for that your projects don't yet show.
Start with your best project. Rewrite it with the five facts and ask whether you could explain every line to an interviewer. Then do the next one.
