← Back to Blog

How to List Projects on Resume: The CS Student's Secret Weapon

Published ยท Finch Team

Updated

If you're wondering how to list projects on resume and actually make them count, you're already ahead of most applicants. The projects section is the single most underused part of a CS student's resume. Most people treat it like a footnote. It should be your headliner.

Here's the thing: recruiters at tech companies expect students to not have much work experience. They know you're 20. What they're looking for is evidence you can build things. Projects are that evidence. But the gap between a project section that gets you interviews and one that gets skimmed past in three seconds is massive.

Why Projects Matter More Than You Think

I've talked to recruiters at career fairs who told me they spend more time reading the projects section than the experience section on student resumes. That sounds backward until you think about it. Your internship at some local IT shop tells them you showed up and did what you were told. Your projects tell them what you choose to build when nobody's making you.

A friend of mine had zero internships and got offers from two Big N companies. His resume was 70% projects. Three projects, each with strong bullets, backed by GitHub repos. The recruiter literally told him in the interview that his sentiment analysis pipeline project is what got him the phone screen.

If you're a student with thin work experience, go read our guide on building a CS resume with no experience. Projects are your answer.

The Format: Where and How to Structure It

Put your projects section directly below your experience section. If you have less than one real internship, put projects above experience. Seriously. Lead with your strongest material.

Each project entry should have:

  • Project name and a one-line descriptor (or link)
  • Tech stack listed on the same line or immediately below
  • 2-3 bullet points describing what you built and what happened

Here's the skeleton:

Sentiment Analysis Pipeline | Python, spaCy, FastAPI, PostgreSQL, Docker
- Built a real-time NLP pipeline processing 12K tweets/hour with 89% classification accuracy using fine-tuned spaCy models
- Designed REST API serving predictions in <50ms p95 latency, deployed on AWS EC2 with Docker Compose

Notice there's no paragraph explaining what the project is. The title and tech stack handle context. The bullets handle impact. That's it.

The XYZ Formula, Adapted for Projects

Google popularized the XYZ formula for resume bullets: "Accomplished X, as measured by Y, by doing Z." It works great for work experience. For projects, it needs a twist.

Student projects rarely have business metrics. Nobody's going to write "increased revenue by 15%" for their class project. So here's the adapted version:

Built [what] using [how] that [measurable outcome or technical achievement].

Let me show you bad vs. good versions of the same project.

Bad:

  • Created a web application for tracking expenses

Good:

  • Built a full-stack expense tracker with React and Express serving 30+ active users, with JWT auth, CSV export, and real-time category breakdowns via Chart.js

The bad version tells me nothing. The good version tells me the tech, the scale, and the features. I can picture what this person built.

Bad:

  • Worked on a machine learning model for image classification

Good:

  • Trained a ResNet-50 classifier on 15K labeled images achieving 94.2% test accuracy, reducing inference time 3x through ONNX model optimization

Same project. Completely different signal.

How to Quantify When You Don't Have Numbers

"But I don't have metrics." Yes you do. You just haven't looked for them yet.

Here are real things you can measure from almost any project:

  • Dataset size: "Processed 50K records," "trained on 15K images"
  • Performance: "Response time under 200ms," "94% accuracy on test set"
  • Scale indicators: "Served 30 concurrent users," "handled 500 requests/minute in load testing"
  • Code scope: "Built 12 REST endpoints," "wrote 2,400 lines of Go across 8 packages"
  • Time efficiency: "Reduced build time from 4 minutes to 45 seconds"
  • Test coverage: "Maintained 85% test coverage across 120 unit tests"

You don't need production traffic numbers. You need specifics that show you thought about performance, scale, or quality. Run a load test on your project for 10 minutes. Now you have throughput numbers. Check your test coverage. Now you have a percentage. Count your API endpoints. These are all real, honest numbers.

If the project genuinely has nothing measurable, lean on the technical complexity instead: "Implemented custom B-tree index supporting range queries and concurrent reads" is still a strong bullet even without a number attached.

What Kinds of Projects Actually Impress

Not all projects are equal. Here's a rough ranking of what recruiters care about, from most to least impressive:

Tier 1: Projects with real users. Anything deployed and used by actual humans. A Discord bot with 200 users beats a class project every time. A Chrome extension with 50 installs. A tool your student org actually uses.

Tier 2: Projects that solve a real problem you had. You wrote a script that scrapes your university's course catalog and alerts you when a seat opens. You built a CLI tool to batch-rename your photo library. These show initiative and product thinking.

Tier 3: Technically deep projects. A compiler, an operating system kernel module, a distributed key-value store. These might not have users, but they signal strong CS fundamentals. Great for companies that care about systems knowledge.

Tier 4: Class projects, done well. Fine to include, but dress them up. Don't write "CS 314 Final Project." Write the actual thing you built and what it does. Nobody cares which class it was for.

Avoid: Tutorial follow-alongs. If your project is a to-do app from a YouTube tutorial, leave it off. Recruiters have seen that exact app 10,000 times. If you extended it meaningfully (added auth, deployed it, added collaborative editing), then it's fair game.

For more ideas on writing strong bullets generally, check out our resume bullet examples for software engineers.

GitHub, Quantity, and Common Mistakes

Your resume projects and your GitHub should tell the same story. If you list a project on your resume, it should have a repo that isn't embarrassing. That means a README that explains what the project does, commits that aren't all "fixed stuff" and "asdfgh," and code that's at least somewhat organized. Spend 20 minutes writing a decent README for your top three projects. It's one of the highest-ROI things you can do.

This matters for your overall CS student resume too. A GitHub link in your header that leads to polished repos reinforces everything in your projects section.

As for how many projects: two to three. If you have strong work experience (two or more relevant internships), two projects is plenty. If you're light on experience, go with three. Three projects with three bullets each gives you nine lines of content. Don't list five projects with one bullet each. Depth beats breadth.

Now for the mistakes that kill project sections:

Listing the tech stack as the bullet. "Used React, Node.js, MongoDB" is not a bullet. It's a tag line. The tech should appear in the bullet naturally as you describe what you built.

Being vague about your contribution on team projects. If it was a group project, be specific about what you did. "Implemented the authentication system using OAuth 2.0 and session management" is yours. "Built a web app with my team" is nobody's.

Describing what the project is instead of what you did. "This app helps users track their fitness goals" is a product description. "Built a fitness tracking dashboard with React and D3.js, rendering 90-day trend visualizations from user workout data" is a resume bullet.

No links. If the project is deployed or has a repo, link it. Put the URL right next to the project title. Make it easy for the recruiter to verify your work.

The Bottom Line (and How to List Projects on Resume Faster)

Your projects section is where you prove you can build things. Treat every project entry like a mini work experience: name it clearly, state the tech, and write bullets that show what you built, how you built it, and what the outcome was. Quantify where you can, be specific where you can't, and make sure your GitHub backs up what your resume claims.

Writing project bullets is one of those things that takes way longer than it should. You stare at your project trying to figure out how to describe it in one line that sounds impressive but honest. Then you need different versions for different jobs because a frontend role cares about your UI work and a backend role cares about your API design.

That's exactly what the first version of Finch automated. It read students' GitHub repos, ranked their projects, and wrote different bullet versions for different jobs. A systems role got a student's kernel project with performance-focused bullets. A web dev role got their full-stack app with feature-focused bullets. You can copy the idea by hand: write two versions of each project's bullets, one about performance and one about features, and pick per application.

Then spend that effort on the right roles. Each week Finch picks the 3 internships or new-grad roles that fit your major best and says why, so you know which applications deserve your best project bullets. It's free, and you start with your major. Your projects deserve better than copy-paste.