Yes — and if you're early career or changing fields, projects should be the most prominent section on your resume, above education and often above limited work experience. They're the only direct evidence you can actually do the work.
**How to present them so they count:**
Each project needs four things:
1. **What it does, in one line**, framed around the problem it solves rather than the technology. 'A tool that lets my college society manage event signups, replacing a spreadsheet used by 200 members.'
2. **The tech**, briefly — this is what keyword searches hit.
3. **A live link and a repository link.** Non-negotiable. A project a reviewer can't click is worth a fraction of one they can.
4. **One line of scope or outcome**: real users, a technical challenge you solved, scale, or something measurable.
**Which projects to include:**
- Things with real users, even a handful. Enormously more persuasive than anything else.
- Things that solve a genuine problem, particularly one connected to the industry you're targeting.
- Things where you made non-obvious decisions you can discuss for ten minutes.
**Which to leave off:**
- Tutorial projects everyone has — the standard weather app, to-do list, or clone of a famous site built by following a video. They demonstrate you can follow instructions, which isn't a differentiator when a thousand applicants have the same three.
- Anything unfinished or broken. A project with a dead link actively damages you.
- Long lists. Three strong projects beat eight mediocre ones; the reader averages rather than takes the maximum.
**The detail most people miss**: be ready to discuss any project you list in depth. Interviewers frequently use your projects as the technical conversation — why you chose that approach, what you'd change, what broke. A project you can't discuss confidently is worse than not listing it, and it's obvious within two questions.
**Where to place them**: if your professional experience is thin, put Projects immediately after a short summary and before Education. If you have several years of relevant work experience, projects move below it and get shorter — at that point your work is the evidence and projects are supporting detail.
One addition worth the effort: a two-paragraph write-up in each repository's README explaining the problem, your approach and one hard thing you solved. Reviewers read READMEs more often than code, and almost nobody writes a good one — so it's a cheap way to stand out.