How to List Projects on Your Resume (So They Read Like Real Experience)
When your work history is thin, projects are your proof. Here's how to list them on your resume so a recruiter reads them as experience, not homework.
How to List Projects on Your Resume (So They Read Like Real Experience)
Every job ad seems to want experience, and every route to experience seems to start with a job. That loop is the whole problem for students, career changers, and anyone coming back after time away. Projects are the one part of a resume where you get to break it. A project is work you chose, did, and can prove, and when it is written up properly, a recruiter reads it the same way they read a job: as evidence of what you can actually do.
The catch is that most people write their projects like a course catalogue. A title, a tool name, a date, and nothing a hiring manager can use. "Built a website using React." That tells them you once touched React. It does not tell them what the site did, who it was for, or whether anyone used it. This guide fixes that. You will learn what counts as a project, the four-part format that makes an entry read like work experience, where the section belongs on the page, and the mistakes that make recruiters skip straight past it.
Why projects carry more weight than they used to
Hiring has been drifting away from credentials and toward proof for a few years now, and the numbers are consistent across surveys. The National Association of Colleges and Employers (NACE) found in its Job Outlook 2026 survey that 70% of employers now use skills-based hiring for entry-level roles, up from 65% the year before. The SHRM Foundation's 2025 survey of 1,184 HR professionals found that 34% of organizations use skills-first hiring often or almost always, and 78% said skilled credentials factor into their decisions. TestGorilla's State of Skills-Based Hiring 2025 report, based on 1,084 employers in the US and UK, put the figure even higher: 85% said they use skills-based hiring, up from 73% in 2023.
Here is the part that matters for your resume. The same SHRM survey found that only 12% of companies feel effective at validating skills, and 72% still rely on resumes or self-reported skills to do it. In other words, employers want proof of skill, and the resume is still where they look for it first. A project entry is the most concrete proof a resume can carry, because it is a work sample in miniature. That is not just my opinion. In the most cited meta-analysis in hiring science, Schmidt and Hunter (1998) found that work-sample tests predicted job performance better than any other method they studied, with a validity of .54, ahead of general mental ability at .51 and far ahead of years of experience at .18 and years of education at .10. A 2022 re-analysis by Sackett and colleagues revised the work-sample figure down to .33, but it stayed near the top of the table. The pattern survived twenty-four years of argument: watching someone do the work beats reading about their qualifications.
The degree itself is losing its gatekeeping power, slowly and unevenly. Indeed's Hiring Lab reported in January 2026 that 51% of US job postings list no formal education requirement at all, and 19.3% require a bachelor's degree or higher, up from 16.6% in November 2023. But the Burning Glass Institute and Harvard Business School tracked 11,300 roles from 2014 to 2023 and found something sobering: when employers removed the degree requirement from a posting, the share of hires without a bachelor's rose by only 3.5 percentage points, and fewer than 1 in 700 hires actually changed. The employers that did change who they hired were a minority, about 37%, and they were the ones that replaced the degree line with a real way to judge skill. At those firms, non-degree hires stayed at rates 10 percentage points higher than their degreed colleagues and earned about 25% more than they had before. The lesson is not that credentials are dead. It is that dropping a requirement helps nobody unless something better takes its place, and on your resume, that something is the project.
Employers are also telling students directly what they want to see. In NACE's Job Outlook 2026 Spring Update, 59% of employers said they want specific skills backed by examples, while only 16% would accept a bare list of specific skills and 2% a list of general ones. And in NACE's 2025 Student Survey, 88.1% of students said they had taken part in projects, internships, or volunteer work that built career-relevant skills. The supply is there. The gap is in how it gets written down.
None of this means projects are a magic key. Entry-level hiring is genuinely tight. HackerRank's 2025 Developer Skills Report, which surveyed 13,732 developers across 102 countries, found that 74% of developers still say finding a job is difficult, and that entry-level hiring grew just 7% year over year, against 19% for senior roles and 22% for lead roles. The same report noted that the share of open software engineering roles aimed at entry-level candidates has fallen to just over 20%, from nearly 30% since January 2023. A good Projects section does not change that market. It changes whether your application survives the first seven seconds of it. TheLadders' 2018 eye-tracking study put that first scan at 7.4 seconds, and nothing since has suggested recruiters got more patient.

What counts as a project
A project is any bounded piece of work with a goal, a method, and an outcome you can describe. That definition is deliberately wide, because most people undercount what they have done. Five kinds cover almost everything:
Academic projects. Coursework with a real deliverable: a final-year project, a capstone, a dissertation with a dataset, a lab build. The test is whether you produced something, not whether you attended something. A semester of lectures is not a project. A semester that ended with a working prototype is.
Personal projects. Something you built because you wanted it to exist: an app, a blog with a real audience, a dataset you cleaned and analyzed, a small business you ran. Self-directed work counts, and for career changers it is often the strongest evidence available, because it proves interest in the new field without anyone having to take a chance on you first.
Freelance and client work. Paid work done outside a job, even for one client. This overlaps with the freelance section I covered in the freelance work guide, and the rule there applies here too: if it had a client, a deadline, and a deliverable, it is experience, and you should write it up like experience.
Open-source and community contributions. Code merged into a real repository, documentation you rewrote, a bug you fixed that shipped. Open source is unusually easy for a hiring manager to verify, which is exactly why it carries weight. GitHub's Octoverse 2025 report counted more than 36 million developers joining the platform in a single year, taking the total past 180 million, with roughly 630 million repositories. Your link sits in a very large crowd, which is why the write-up matters more than the link itself.
Work projects inside a job. A discrete initiative inside a role you already held: a process you redesigned, a report you automated, a campaign you ran. These usually live under the job entry itself rather than in a separate section, but the same format applies, and if the project is the most impressive thing you did in that job, it deserves its own bullets.
What does not count: a tutorial you followed click by click, a certificate course with no deliverable, a group assignment where you cannot say what you personally did, and anything you would not be able to talk about for two minutes in an interview. If you cannot defend it, it does not belong on the page.
The four-part entry: how to write a project so it reads like a job
Every strong project entry has the same four parts, in the same order. Think of it as a small job entry, because that is how a recruiter reads it.
1. A descriptive title, not a code name. "Inventory tracker for a neighbourhood pharmacy" beats "Project 2" and beats "PharmaApp v1" too. The title should tell a stranger what the thing is. Add your role if it was a team effort, and the context: final-year project, personal project, client work, hackathon, open source.
2. A tools line. One line naming the technologies, software, or methods, written as plain text so an applicant tracking system can read it. "Python, pandas, Tableau" or "Figma, Maze, Dovetail" or "Excel, Power Query, VBA." Keep it honest: list what you actually used, because an interviewer may ask about any of them. A parser cannot read a tools badge image, so never put this in a graphic.
3. Two or three bullets, built on one formula. Open with a strong verb, name the thing you made, say how you made it, then land the outcome or the size of it. "Built" on its own is not a bullet. "Built a stock-tracking sheet for a family pharmacy in Excel with Power Query, cutting the weekly stock count from 3 hours to 40 minutes" is a bullet. The result does not have to be a percentage. It can be a number of users, a dataset size, a time saved, a decision made, or an outcome like "adopted by the shop for daily use." If you genuinely have no result, give scale instead: how many records, how many screens, how many weeks of work.
4. A link, but only if it works. A GitHub repository, a live demo, a portfolio page, a published report. Check every link before you send the resume, and check it again a month later. A link that leads nowhere does more damage than leaving the link off entirely, because the reader stops trusting the entry, not just the URL. If the work is under NDA or belongs to a client, say so in one line ("client name withheld under NDA") and describe the work without the link. Recruiters understand that; they do not understand a 404.
Here is the same project written two ways, so the difference is visible:
Before: "Library App | React, Firebase | 2025. Built a library app as a final-year project."
After: "Book-swap app for a campus library | Final-year project | React, Firebase | 2025. Built a reservation and lending flow for 400+ registered students, with role-based access for librarians and borrowers. Cut manual sign-out logging from 15 minutes per session to under 2 minutes. Presented to the library committee, which adopted the app for the spring term."
Same project, same person. The second version is a job. The first is a line on a syllabus.
Where to put the Projects section
Placement is a judgement call, and it depends on how strong your projects are relative to everything else on the page. The rule is simple: your strongest evidence goes highest.
| Your situation | Where Projects goes | Why |
|---|---|---|
| Student or recent graduate | Directly after Education, or after Internships if you have a strong one | Projects are your main proof of ability, so they should not be buried at the bottom |
| Career changer | Directly below your summary, above Work Experience | It puts the new field first and frames the old jobs as background, not the headline |
| Mid-career, changing direction | After Work Experience, as a supporting section | Your job history carries the page; projects add range |
| Experienced hire, 10+ years | Fold the best one or two into the relevant job entries | A separate section would push real experience down the page |
If you have only one project worth listing, do not create a whole section for it. Put it under the closest heading instead: under Education for an academic project, under a job for a work initiative, or as a single line in your summary's proof. A section with one lonely entry looks like padding. Two to four strong entries is the sweet spot for a dedicated section. Five is the ceiling, and only if every one of them is genuinely relevant to the job you want.
There is one more placement question people get wrong: do not put projects under Skills. A skills section is a list; a project is a story. The moment you compress a project into a comma-separated list, you have thrown away the only thing that made it persuasive.
How many projects, and how to choose them
Relevance decides, not size. A small project that lines up with the posting will do more for you than a showpiece in a field the employer does not care about. Before you include a project, run it through three questions:
Does it match this job? Read the posting, pull out the three skills it repeats most, and check whether the project demonstrates at least one of them. If it demonstrates none, leave it off this version of the resume. Tailoring is not optional here; Jobscan's survey of 384 recruiters found 99.7% use keyword filters, and a project entry is one of the best places to put the posting's own language, honestly, in context. For the full method, see my guide on finding resume keywords.
Can I defend it in an interview? If the interviewer says "walk me through this project," can you talk for two minutes about the decisions you made, the problems you hit, and what you would do differently? If the honest answer is no, the entry is a liability, not an asset. This is the test that kills most tutorial projects, and it should.
Is it finished? A finished small project beats an ambitious half-built one. "Built and launched" is a complete sentence. "Currently building" invites the question of why it is not done, and it hands the interviewer a thread to pull. If the project is genuinely ongoing and worth including, say what is live now, not what you plan to add.
Cut ruthlessly. A resume is not an archive. The projects you leave off are not wasted; they are just not for this application.
Examples: five situations, written the right way
The student with no work experience. This is the most common case, and the one where projects matter most. Lead with the project that is closest to the job, and do not apologise for it being academic. Employers already know what a final-year project is; your job is to show what you did inside it.
Campus food-bank inventory sheet | Final-year project | Excel, Power Query | 2025
- Rebuilt a paper stock log as a live inventory sheet for a food bank serving 300 households a week, with expiry alerts and a weekly reorder list.
- Cut the monthly stock count from a full day to under 2 hours, and flagged 40+ expired items in the first month that the paper log had missed.
- Trained two volunteers to run the sheet, and handed it over with a one-page guide.
The career changer. Your old jobs are not the story; the bridge is. Put the project section high, and use the summary to connect the two halves. For the wider playbook, see my guide on writing a resume for a career change.
Neighbourhood bakery ordering page | Personal project, career change into web development | HTML, CSS, JavaScript, Stripe test mode | 2026
- Built a mobile-first ordering page for a local bakery, with a menu, a basket, and a pickup-time picker.
- Orders placed through the page rose from 0 to 25 a week in the first month, and the owner stopped taking orders by phone.
- Wrote the copy and photographed the menu items myself, after the owner said customers kept asking what each cake looked like.
The tech candidate. For developers, the GitHub link is part of the entry, and the repository itself is the interview. An older HackerRank survey found that 84.1% of the CEOs, CTOs, and founders who responded treated GitHub project work as an important indicator of on-the-job skill. That survey is old, and GitHub alone will not replace a technical interview, but the direction is clear: engineering managers open the link, especially for junior roles where there is little work history to read. So curate it. Pin your two best repositories, write a README that explains what the project does and how to run it, and make sure the most recent commit is not from eleven months ago.
Volunteer shift scheduler | Open source | React, Firebase | 2025, github.com/yourname/shift-scheduler
- Built a drag-and-drop rota tool for a food bank coordinating 150 volunteers across 3 sites.
- Automated shift reminders by email, cutting no-shows from roughly 1 in 5 shifts to 1 in 12 over two months.
- Merged 14 pull requests from 6 contributors; wrote the setup docs that new contributors still use.
The non-tech candidate. Projects are not a tech-only device. A marketing graduate who ran a real campaign for a real small business has a stronger entry than a developer with a to-do app. The same formula applies: what you did, for whom, and what changed.
Instagram relaunch for a campus thrift shop | Volunteer project | Canva, Meta Business Suite | 2025
- Rebuilt the shop's Instagram from scratch: new visual style, a weekly posting calendar, and a "new in" story template.
- Followers grew from 180 to 1,400 in one term, and weekend footfall rose enough that the shop added a Saturday opening.
- Tracked every post in a simple sheet, and dropped the two formats that never converted.
The freelancer or side-hustler. If the work was paid, write it like a job, with the client named where you can. One strong client entry can carry the whole section. For the full format, see my guide on listing freelance work.
Freelance: monthly reporting pack for a dental practice | Self-employed | Excel, Power BI | 2025–present
- Built a monthly dashboard tracking appointments, no-shows, and treatment revenue across 2 chairs.
- No-show rate fell from 18% to 11% after the practice started texting patients the day before, a change the dashboard made visible.
- Retained on a monthly basis; the practice has renewed the arrangement three times.

Group projects: saying what you did, not what the team did
Group work is where most project entries fall apart, because people write "we built" and then cannot answer a follow-up question. Recruiters know how group projects work. They are not suspicious of teams; they are suspicious of vagueness. Three rules keep you safe:
Name your part. "I owned the data model and the reporting queries; two teammates built the front end" is a strong sentence. "Our team built a dashboard" is not. Use "I" for your contribution and "the team" only where the work was genuinely shared.
Give your numbers, not the team's. If the project served 500 users, say so, but do not claim the whole outcome as yours. "My module handled the payment flow, which processed 2,000 transactions in the first term" is honest and specific. "Increased revenue 40%" for a project you touched for two weeks is not.
Be ready for the follow-up. The interviewer will ask what went wrong, who disagreed with you, and what you would change. Have an answer. A real answer to "what would you do differently" is one of the most persuasive things you can say in an interview, because it proves you actually did the work.
The ATS angle: projects are keyword real estate
A Projects section is one of the best places on a resume to hold keywords, because the words arrive inside real sentences instead of a stuffed skills list. When a posting asks for Python, pandas, and stakeholder reporting, a project bullet that says "Built a donor report in Python with pandas, presented monthly to a board of 9 trustees" gives the parser three matches and gives the human reader a reason to care. That is the whole game: keywords the machine can find, attached to evidence a person can believe.
Two technical rules. First, write everything as plain text. No text inside images, no tables with merged cells, no columns that split a bullet across the page. The Enhancv parse tests I cited in my ATS-friendly guide found single-column layouts parse far more reliably than two-column ones, and the same logic applies inside a section: keep the layout boring and the content rich. Second, spell out acronyms the first time you use them if the posting spells them out. If the job says "search engine optimisation" and your bullet only says "SEO," a strict keyword filter can miss the match. One extra word costs you nothing.
For the wider picture on how parsers treat your resume, read my guide on what "ATS-friendly" really means and my breakdown of what a good ATS score looks like.
Five mistakes that sink a Projects section
1. Listing course titles instead of work. "Machine Learning, CS-401" is a module, not a project. If the entry has no deliverable, no user, and no outcome, it is not a project entry. It is a transcript, and the transcript already exists.
2. No numbers anywhere. A section with zero measurements reads like fiction, even when it is true. You do not need revenue figures. Users, rows, hours saved, items processed, weeks of work, and people trained are all numbers, and they are all on the table. If you genuinely cannot find one number, ask yourself whether the project was finished.
3. Too many projects. Six half-described projects lose to three fully described ones. Every entry you add dilutes the ones above it, and a recruiter who has already decided to interview you will not read the sixth entry. Pick your best two to four and give them room.
4. Dead or embarrassing links. A GitHub link that 404s, a demo that shows a default template, a portfolio with placeholder text. Check the links, and if the work is not presentable, leave the link off and let the write-up carry it. A clean entry with no link beats a linked entry that embarrasses you.
5. Inflating your role. Calling yourself the lead on a project where you wrote one screen, or claiming a team outcome as a solo result, is the fastest way to fail an interview. Novoresume's 2026 survey found that 86.1% of recruiters had caught resume lies through online checks. Your project is checkable in a way a job title is not: the repository has a commit history, the client can be called, the demo either works or it does not. Honesty is not just the right policy here. It is the only policy that survives contact with reality.
A short note for UK applicants
In the UK, where the document is a CV rather than a resume, the Projects section works the same way and is arguably more common, because UK employers are used to seeing academic and extracurricular work presented as evidence. Two differences are worth knowing. First, UK hiring managers are more likely to expect the section to sit under Education for recent graduates, rather than directly under the summary. Second, the degree-classification system means your education section already carries a signal about attainment, so the project entries should lean harder on the work itself and less on the grade the project received. For the full UK picture, see my guide on CV vs resume.
The 30-second audit
Before you send the resume, read your Projects section once, out loud, and check five things:
- Every entry has a descriptive title, a tools line, and at least one bullet with a number in it.
- You can say what you personally did in each project, in one sentence, without saying "we."
- Every link opens, and opens to the right thing.
- Nothing in the section is older than the story it tells: if a project is from three years ago and you have done nothing since, the section is telling the reader you stopped.
- The section would still make sense if the reader skipped everything else on the page. Because in the first seven seconds, that is exactly what they do.
FAQ
How many projects should I put on my resume? Two to four, in a dedicated section. One is not enough to justify a section; five or more usually means you kept entries that should have been cut. Students and career changers can stretch to five if every one is directly relevant to the job.
Should I include personal projects on my resume? Yes, if they are finished, relevant, and defensible in an interview. Personal projects are often the best evidence a career changer or a student has, because they show initiative and real skill without needing an employer to have taken a chance first. Tutorial follow-alongs do not count.
Where do projects go on a resume with no experience? Directly after Education, or after Internships if you have a strong one. For a student, projects are the main proof of ability, so they belong near the top. For a career changer, they go directly below the summary, above your old work history.
Do recruiters actually check GitHub or portfolio links? Some do, and the ones who matter most are the ones who do. Engineering managers and interviewers open links for junior and technical roles, often as a tiebreaker between similar candidates. Non-technical recruiters usually just confirm the link exists. Keep the link live, the README readable, and the best work pinned.
Should I list a project I did as part of a team? Yes, but name your part clearly. Say what you owned, what the team owned, and which numbers are yours. Never claim a team outcome as a solo result; interviewers will ask, and the commit history or the client will answer for you.
What if my projects are old? Old is fine if the skill is still current. A three-year-old project in a tool you still use is evidence. A three-year-old project in a tool you have not touched since is a museum piece. If nothing in the section is recent, that is the real problem, and the fix is a new project, not a rewrite.
The bottom line
A Projects section is not a consolation prize for people without experience. It is the part of the resume where you show your work instead of describing it, and the hiring data says that is exactly what employers are looking for: specific skills, backed by examples, in a format a machine can parse and a human can believe. Pick two to four finished projects, write each one like a small job with a result attached, put the section where your strongest evidence belongs, and check every link. Then run your resume through the free ATS checker and see whether the keywords you meant to include are the ones the parser actually finds. If the checker cannot see your projects, neither can the employer's system, and that is a formatting problem worth fixing before you apply anywhere.
Was this article helpful?
Be the first to rate this article
Get weekly resume tips
Practical ATS and job search advice every week. No fluff, unsubscribe anytime.
Keep reading
Is your resume ATS-ready?
Run a free compatibility check — no account, no limits, nothing stored.
Check my resume


