How to list projects on your CV without making them look like filler

Projects can be the best evidence on a technical CV, because they show the thing job titles never quite capture. How you think, what you build when nobody hands you a spec, and whether you can turn a vague problem into something real. For a lot of people, the strongest proof of what they can actually do lives in project work rather than in their official responsibilities.

Which makes it strange how badly projects usually get handled. The two failure modes are opposites. Some people throw three project names and a GitHub link at the bottom of the page and consider the job done. Others bury their best work so deep that a hiring manager would need to go excavating to find it. Both versions leave the reader doing detective work, and readers do not do detective work. They move to the next CV.

The link dump does not do what you hope

A bare GitHub link feels like evidence, but think about what actually happens on the other end. Most reviewers will not click it at all, because they are forty seconds into your CV and clicking is a commitment. The few who do click arrive with no guide, land on whatever your pinned repos happen to be, and judge you on half-finished experiments and a tutorial clone you forgot was public.

So the link ends up either ignored or actively unhelpful. The fix is not to remove links. It is to stop asking the link to make your argument for you. The CV entry itself has to say what the project was and why it matters. The link is there for the one reader in ten who wants to verify, not for the nine who need convincing first.

A project earns space by proving fit, not by being good

The first question is never whether you have projects. It is whether a given project helps prove your fit for this role. A project deserves room when it shows a skill the role cares about, makes a direction change more believable, demonstrates ownership your job titles hide, or gives evidence of delivery in a domain close to the target job.

If it does none of that, it may still be excellent work, but it is portfolio material rather than CV material. That distinction sounds harsh and saves you every time. The CV is not a museum of interesting things you have made. It is the case for one specific application, and every entry is either building that case or diluting it.

Give projects their own section only when that helps

Here is where a lot of technical CVs get structurally messy. If the project happened inside your actual job, it almost always belongs under that role, because pulling it out into a separate section fragments your story and makes the reader reassemble your experience from two places.

A dedicated Projects section makes sense when the work was genuinely separate. Independent builds, freelance work, academic projects, open source, or the strongest proof you have for the direction you are trying to move in. MIT’s sample resumes and cover letters are useful here because they show how different experience categories can be separated when that makes the document easier to scan. The deciding question is always clarity. If a separate section helps the reader recognise relevant evidence faster, keep it. If it just adds a second place to look, fold the work back into the role where it happened.

What a good project entry actually contains

A useful entry answers five things fast. What the project was, what problem it solved, what your role was, which tools genuinely mattered, and what changed because of the work.

Watch the difference in practice. “Built a machine learning app using Python, Flask, Docker, and AWS” lists a stack and stops. “Built and deployed a Python and Flask document-classification tool for internal operations, packaging it with Docker and reducing manual triage time for incoming files” gives the same stack a job to do. The tools now have context and a result, which is what makes them believable rather than decorative.

Small side projects follow the same rule. “Personal budgeting app. React, Node.js, PostgreSQL” is technically true and completely weightless. A stronger version explains the purpose, the feature choices, and what the project let you test or learn. You are not trying to sound grand. You are trying to sound specific enough that the project feels like real work rather than a label.

Choose projects for the job, not for your ego

The project you love most is not automatically the one that belongs on this CV, and this is genuinely hard to accept about your own work. If the role is backend-heavy, the hiring team cares more about your API reliability work or data pipeline project than the beautiful design-system side project you are proud of. If the role leans product or AI, the messy project full of evaluation tradeoffs and judgment calls may do far more for you than the one with the flashiest stack.

Project selection is really just another form of tailoring, and it gets much easier when your projects are stored as reusable evidence instead of pasted into one fixed document forever. A tailored CV should pull in the two projects that sharpen this application and leave the other six in reserve, and with a proper master profile that is a selection decision rather than a rewrite. That is exactly how OutRung treats project work. Keep the full context and outcomes for every project once, then choose which proof travels with each application.

Keep entries short and let the interview do the rest

The other common failure is over-explaining, and it comes from the same proud place as the link dump. One or two lines is enough for almost any project, provided those lines carry role, context, and outcome.

If a project needs a paragraph to make sense, either the writing is loose or the project is not actually central to this application. The CV only needs to make someone curious enough to ask. The full story is what interviews, portfolios, and supporting links are for, and a question about your project is one of the best openings an interview can hand you.

Why this matters more as you get senior

For junior candidates, projects compensate for a thin work history. For experienced people, the job flips. Projects prove you are still hands-on when your recent titles sound managerial, show product judgment when your official responsibilities were vague, and surface technical depth your last few roles never made visible.

That is why I think of them as proof blocks, not hobbies. Chosen well, a single project entry can quietly answer the exact doubt a hiring manager has about your profile, which is more than most bullet points ever manage.

The honest rule

If a project makes the hiring manager more confident you can do this job, keep it and write it properly. If it is there mainly because you spent ages on it, love it, or feel guilty deleting it, that is not enough.

Projects belong on a CV when they sharpen the case. When they do not, leave them out this time and let the stronger evidence breathe.