How to List Personal Projects on a Resume for Tech Roles

Personal projects belong on a tech resume when they prove something your job history does not prove yet. MIT explicitly notes that relevant experience can include class projects, competitions, and personal projects, as long as you make the relevance clear, while Harvard stresses tailored, specific, fact-based writing that is easy to scan.^[1][2] That is the right standard: a project earns space when it adds evidence, not just because you spent time on it.

The mistake is treating every side project as a badge of passion. Hiring managers are not scoring you for having a GitHub full of half-finished experiments. They are looking for judgment. If a project shows that you can ship, solve a concrete problem, learn a stack that matters for the role, or demonstrate range that your current title hides, it can help. If it just repeats skills already obvious from stronger paid work, it usually dilutes the story.^[1][2]

For junior candidates, projects often carry real weight

Early career candidates usually have a proof gap. You may have coursework, internships, a bootcamp, freelance work, or a first job with limited scope. In that context, personal projects can do meaningful resume work because they show initiative, hands-on technical choices, and the ability to turn theory into something concrete. NACE is useful here only as light framing: its career-readiness competencies include technology, communication, and career self-development, which helps explain why strong project work can matter while you are still building formal experience.^[3]

For a junior candidate, a projects section can sit near the top of the resume, often after skills or education and before less relevant work history. That placement makes sense when the projects are among the clearest evidence you have. The bar is still relevance. A deployed web app with authentication, tests, and a short note about tradeoffs is useful. Five tiny tutorial clones are not.

Strong junior projects work best when they close a proof gap, not when they just add noise.

For mid-career candidates, projects should close a specific gap

Once you have a few years of solid experience, personal projects become more selective. Their job is no longer to prove that you can code at all. Their job is to add missing signal.

Maybe you work in backend systems but want to show product sense through a small customer-facing app. Maybe you are moving toward data engineering and have a pipeline project that makes that direction credible. Maybe your day job is in a slow-moving environment and a side project shows recent familiarity with tools the target role uses. Those are good reasons to include a project.

But if your resume already includes strong production work, projects should not crowd out the work experience section. In most mid-career cases, they belong lower on the page or under a selected projects section with only one to three entries. The rule is simple: if the project is not sharper than the next work bullet you would cut to make room, it probably should not be there.

For senior candidates, projects are usually supporting evidence

Senior and staff-level candidates are mostly hired on scope, decision-making, leadership, and business impact. A side project can still help, but usually as supporting evidence rather than the center of the resume.

At that level, the most useful projects tend to show one of three things: continued hands-on depth, credibility in a new area, or public evidence of technical leadership. An open source maintainer role, a meaningful developer tool, or a well-adopted niche product can help because it says something your title alone may not capture. A small weekend app with no context usually does not.

This is where many experienced candidates overcorrect. They worry that leaving projects off will make them look less technical, then add weak entries that distract from larger career wins. Harvard's advice to order content by importance is a good filter here: senior resumes should foreground the highest-value evidence first.^[1]

Put projects where the evidence matters most

There is no universal rule for section placement. There is only the question: where will this evidence do the most work?

• Near the top: best for students, new grads, and career changers whose projects are central proof.
• Lower on the page: best for mid-career candidates using projects to reinforce a direction or add one missing signal.
• Very selective or omitted: best for senior candidates whose work history already carries the argument.

If a target role cares about React, distributed systems, Terraform, or computer vision, the project entry should say so plainly when that is truthful. Clear naming helps recruiters and hiring teams understand relevance faster. Do not make the reader infer the stack from a repo name.

Project placement changes with career stage: earlier resumes lean on projects more, while later resumes use them selectively.

Write project entries like evidence, not hobbies

Weak project bullets read like a feature list. Strong ones explain the problem, the technical choices, and the result. Columbia's resume guidance is useful here: start with action, add context, and make the outcome visible where possible.^[4]

Compare these two versions:

• Built a movie app in React.
• Built a React movie-tracking app with local caching and search debounce, reducing repeated API calls during testing and clarifying state-management decisions in a linked code sample.

Stronger project entries show what you built, why the choices mattered, and what proof came out of the work.

The second version is better because it signals judgment. Even if a personal project has no revenue or user base, you can still describe scale, constraints, design decisions, performance improvements, testing approach, deployment, documentation, or contributor adoption. MIT and Harvard both push candidates toward specificity and clear relevance, which matters just as much for unpaid work as paid work.^[1][2]

A strong project entry usually answers four questions quickly:

1. What problem did this solve?
2. What did you actually build or decide?
3. What technologies or methods matter here?
4. What result, learning, or proof came out of it?

If you cannot answer those in one or two lines, the project may not be resume-ready yet.

Use a hard filter before you include anything

Before adding a project, ask:

• Does it support the exact role I want?
• Does it prove something my work history does not prove clearly enough?
• Can I describe it with specifics, not vague enthusiasm?
• Would I be happy if an interviewer spent ten minutes drilling into it?

If the answer to two or more is no, leave it off.

If you keep multiple resume versions, a tool like CoreCV can help you maintain one structured base resume while testing when a project belongs in a junior-targeted, pivot-focused, or more specialized variant. That is usually a better move than stuffing every project into one master document.

The takeaway

Personal projects help a tech resume when they close a credibility gap, sharpen your direction, or reveal technical judgment that your day job does not show yet.

Pick fewer projects, describe them better, and place them according to your career stage. The goal is not to prove that you are always coding after hours. The goal is to give a hiring manager one more strong reason to believe you can do the job.

Sources

1. Harvard FAS Mignone Center for Career Success, Create a Strong Resume: https://careerservices.fas.harvard.edu/resources/create-a-strong-resume/

2. MIT Career Advising & Professional Development, Resumes: https://capd.mit.edu/resources/resumes/

3. NACE, What is Career Readiness?: https://www.naceweb.org/career-readiness/competencies/career-readiness-defined

4. Columbia Center for Career Education, Resumes with Impact: Creating Strong Bullet Points: https://www.careereducation.columbia.edu/resources/resumes-impact-creating-strong-bullet-points