How to List Coding Projects on a Software Engineer Resume

If you're a junior or self-taught engineer, your projects section is doing the job your work history can't. It's where you prove you can actually build things, not just talk about them. Done well, it turns a thin resume into one that gets calls. Done lazily, with three tutorial clones and no context, it gets skimmed and skipped.

This guide walks through exactly how to list coding projects on your resume: which projects to include, where to put them, how to write each bullet, how to link your code, and how to tailor the whole section to the job you want. Every recommendation here reflects what recruiters and applicant tracking systems (ATS) actually do with your resume in 2026.

When you don't have years of paid experience, projects are your proof of work. A recruiter scanning a junior software developer resume wants to answer one question fast: can this person write code that solves a real problem? Your projects section is the fastest way to say yes.

This is why career centers now routinely place projects high on the page for junior and career-switcher candidates, right under the summary. Hands-on skills need to surface in the first pass, not on page two.

There's a practical scanning reality behind this. The so-called 7-second rule says recruiters spend roughly 7 to 10 seconds on their first look at a resume before deciding to read on or move to the next one. In that window they're hunting for signal: relevant technologies, real outcomes, and evidence you can ship. A strong projects section puts that signal where their eyes land.

The bar has also risen. Because AI tools like GitHub Copilot and ChatGPT can scaffold a basic app in minutes, a to-do list or a CRUD blog no longer proves much. Hiring managers know a beginner can generate that in an afternoon. What still carries weight is a project with real users, unusual data, or production constraints.

A good resume project shows judgment, not just syntax. It has a real problem behind it, some technical difficulty, and a result you can describe. The exact idea matters less than whether it forced you to make engineering decisions.

Tutorial clones fail this test. A weather app that calls one API, a to-do list, a Bootstrap portfolio, a copy of a course project: recruiters have seen thousands of each. They signal that you can follow instructions, not that you can build independently.

Here's what separates a project worth listing from filler:

On volume, more is not better. Current hiring guidance points to two to four high-impact projects rather than a long list of small ones. Some engineers build their whole resume around a single flagship project done thoroughly. Depth beats breadth every time. Three finished, well-explained projects say more than eight abandoned ones.

We analyze the job descriptions that flow through Roleframe's tailoring engine, and a clear pattern shows up in entry-level software engineering postings. Employers repeatedly ask for the same kinds of hands-on work as proxy experience when they can't require years on the job. If your projects section mirrors these, you're speaking the language of the posting.

The categories that come up most often for junior roles:

Notice the theme: employers want evidence you've touched the parts of the stack that a tutorial usually skips. Deployment, testing, and real data are exactly where beginners stop, so demonstrating them sets you apart.

Placement is a strategic choice, not a formatting afterthought. The rule is simple: put your strongest evidence highest. For most people early in their careers, that's projects.

Put projects directly under your summary, above or level with education, and above any unrelated work history. If your paid experience is retail or hospitality, it should not be the first thing a hiring manager reads on a software role. Lead with the code.

Name the section clearly: Projects or Technical Projects. Both parse cleanly in ATS and tell a recruiter what they're looking at.

Lead with work experience, then follow with a tighter projects section featuring one or two standout personal or open-source builds. At this stage, projects fill gaps: they show a technology your day job doesn't use, or an interest that matches the target role.

Projects usually become optional. A short section can still be worth it if you maintain a well-known open-source project or built something that directly proves a skill the job wants. Otherwise, let your professional impact carry the resume.

One important distinction: don't list unpaid personal projects under Work Experience. Keep them in a Projects section. Blurring the line reads as padding, and experienced recruiters notice. The exception is a project you built for a job, internship, freelance client, or open-source org. Those belong inside the relevant experience entry, because they came with real collaboration and constraints.

Every project entry should answer three questions fast: what did you build, what problem did it solve, and what happened as a result. The strongest bullets follow the STAR shape borrowed from behavioral interviews: Situation, Task, Action, Result. You don't need to label them, just make sure the problem and the outcome are both visible.

Here's a reliable header format for each project:

Weak bullet: "Built a web app using React and Node.js." It states tools and nothing else. Every candidate can write it.

Strong bullet: "Built a meal-planning app (React, Node.js, PostgreSQL) that generates weekly grocery lists from user recipes; deployed on Render with a REST API serving 40+ weekly active users." Now there's a problem, a stack, a deployment, and a usage number.

Quantify wherever you honestly can. Hiring managers respond to concrete outcomes like "reduced page load time by 40%" or "cut data-processing time by 25%." If you don't have performance numbers, use scope instead: number of users, records processed, endpoints built, test coverage. A real, modest number beats a vague superlative.

List the specific technologies inside each project, not just in a skills blob at the bottom. Modern ATS platforms like Greenhouse and Workday parse for project-level keywords such as React, Docker, REST API, and PostgreSQL, and they cross-reference them against the job description. Naming your stack per project raises your keyword match and gives a human reviewer the context a bare skills list can't.

Write the tool names exactly as the industry does: "Node.js" not "nodejs," "PostgreSQL" not "postgres," "CI/CD" spelled out at least once. Matching the job's exact phrasing matters for both machine and human readers. For more on getting past the filters, see our guide on how to beat the ATS and how to build an ATS-friendly resume format.

Links are now a baseline expectation in software hiring. Recruiters and engineers want to open your repo and check the code, the commit history, and the README. A project without a link is a claim without evidence.

For each significant project, include two links where possible: the GitHub (or GitLab) repository and a live demo. The live demo is what a busy recruiter clicks first, so make sure it loads and works. A broken demo hurts you more than no demo.

Embed the link on descriptive anchor text like "GitHub" or "Live demo" rather than pasting a long raw URL. Long URLs clutter the page and can trip up parsing. Keep hyperlinks on non-critical words so that if the ATS strips the link, the sentence still reads fine. Since Roleframe exports your resume as a PDF that matches the editor exactly, embedded links stay clickable and formatting holds up. Save and submit as PDF by default; only use another format if a specific employer explicitly asks.

A few practical rules for your repos:

For placement of your profile link versus per-project links, and how to handle a sparse GitHub, we go deeper in our guide on where to include your GitHub link on a resume.

Both belong on a resume, but they signal different things, and open source often carries more weight for one reason: it proves you can work inside someone else's codebase. Personal projects show initiative. Open source shows collaboration, code review, and the ability to navigate constraints you didn't set.

List open-source work with the specific contribution, not just the project name. "Contributed to an open-source library" is vague. "Implemented rate-limiting middleware in [project], merged into main after code review" is concrete and verifiable. Link the merged pull request if you can.

You don't need to have committed to a famous framework. A well-scoped, merged fix to a mid-sized project signals more than a solo repo with one contributor. If you've done work for an internship, freelance client, or a real org, describe it with bullets like "Diagnosed and fixed a production issue in a legacy Java codebase" and put it in your experience section, because that's real-world work.

The same set of projects should be described differently for different jobs. Tailoring your project bullets to each posting is one of the highest-leverage moves you can make, because it shifts both the keywords the ATS scores and the story a recruiter reads.

Start by reading the job description and pulling out the specific technologies and concepts it names: microservices, TypeScript, Kubernetes, CI/CD, whatever it emphasizes. Then reorder and reword your projects so the most relevant one is first and its bullets highlight the matching tools.

Match your projects to the role's focus:

Don't fabricate a stack you didn't use. Tailoring means emphasizing the true parts of your work that match, and cutting what doesn't. If a project used five technologies and the job cares about two, lead with those two.

Doing this by hand for every application is slow, which is why most people give up and send the same resume everywhere. That's where a base resume plus tailored versions pays off: you keep one strong master resume per target role, then spin off a version aligned to each posting. Roleframe does this in seconds, reordering and rewording to match the job so you can apply while the role is still fresh. Being early in the pipeline often matters as much as the resume itself.

Here are three complete project entries you can adapt. Notice the pattern: name and one-liner, stack, link, then bullets that state a problem and an outcome.

ShiftSwap — Scheduling API for hourly workers to trade shifts (Node.js, Express, PostgreSQL, Docker). GitHub · Live demo

• Designed a REST API with 12 endpoints and JWT authentication, handling shift requests, approvals, and conflict detection.
• Containerized the app with Docker and set up a GitHub Actions CI pipeline running the full test suite on every push.
• Achieved 85% test coverage; deployed to Render and used by a 30-person restaurant team for 3 months.

TrackFin — Personal finance dashboard with interactive spending charts (React, Next.js, TypeScript, Recharts). GitHub · Live demo

• Built a responsive dashboard that visualizes 12 months of transactions, cutting the time to spot spending trends versus a raw spreadsheet.
• Implemented client-side caching and lazy loading, reducing initial page load time by roughly 40%.
• Followed WCAG accessibility guidelines: keyboard navigation, ARIA labels, and tested contrast ratios.

Open-source contribution — [Library name] (Python). Merged pull request

• Diagnosed a memory leak in the caching module affecting long-running processes; fix merged into main after review.
• Added unit tests covering the previously untested cache-eviction path.

Each of these would take under 30 minutes to adapt to your own work. Keep the structure and swap in your real numbers. If you're rebuilding the resume around them, our step-by-step guide to writing a winning resume covers the sections around your projects, and our list of common resume mistakes covers what to avoid.