10 min read
Side repos and capstones can carry an early-career file when job titles are thin. They can also sink a strong profile when they're listed like hobbies with no dates, no stack, and no tie to the req you're chasing tonight. If you're unsure whether a build counts, it probably doesn't until you've tied it to a posting tool list.
Before you paste another bullet, check your resume for free on the export you'll upload. You want project lines to show up under recognizable headers in plain text, not buried under icons or tables.
You'll inventory builds, pick placement, write tight bullets, and trim what doesn't match this posting. Same history, cleaner proof order.
Quick wins
- Highlight four stack terms in the posting before you open the resume file.
- Keep three projects max on the upload copy for this company.
- Rename the section to Projects in Word, not Portfolio or Highlights.
When projects help versus hurt page one
A project entry is proof you can ship with a named stack under a date range. It is not a list of every tutorial you finished. Recruiters use projects to fill gaps in tenure, not to replace missing employment rows when you've already got five years in the same lane.
Parsers need headers. Workday and Greenhouse map Experience first. A Projects block only works when the word Projects sits alone on a line in the source file, same font as body text, with month-year dates on each entry.
Relevance beats volume. Three posting-aligned builds beat nine unrelated repos. If the req is mid-market SaaS support, your churn dashboard capstone outranks the mobile game you shipped for fun unless the game used the same ticket tools.
Before: Projects read like a link farm with no dates.
After: Each entry has month-year, two bullets, and tools repeated in Experience when you used them on the job.
If you're building from zero experience, pair this with how to make a resume for no work experience so projects sit above education without crowding contact lines.
Edge case: the project was internal but not your day job. Label it clearly under the employer if your manager would confirm it, or move it to Projects with "Built while at [Company]" in bullet one. Don't invent a second job title.
Freelance clients deserve the same dating rules as employers. Use the client name or "Freelance" plus month-year, then two bullets on deliverables. A one-line "various clients" block without dates looks like hidden employment and triggers extra questions on a screen.
Open-source contributions fit when you can name the module you touched and the stack the posting wants. One bullet on merge requests you landed beats listing the org unless the req calls out community work explicitly.
Table for placement at a glance:
| Build type | Where it goes |
|---|---|
| Shipped on employer time | Bullet under that job |
| Side repo or capstone | Projects with dates |
| NDA work you can describe | Projects, no client logo |
How to add projects to your resume the right way
Run these five steps on one posting you plan to submit tonight. Stop when plain text shows dated project rows and your top three entries share vocabulary with the req.
Step 1: Inventory and filter
List every build from the last three years: employer-owned, freelance, capstone, and open source. Tag each with tools from the posting highlight pass. Cross out entries you can't discuss for five minutes or that need an NDA you can't name.
Keep side work that repeats at least two must-haves from the job text. Your flashiest repo loses to a smaller script if the script uses the employer's stack.
Step 2: Choose placement
Paid delivery under a W-2 or contract belongs under that employer with the same dates as the role. Night-and-weekend builds go in Projects with their own month-year span. Bootcamp capstones get "Academic Project" in the title line, not a fake company name.
Place Projects after Experience when you have at least one full-time row. Place it before Experience only when you're student-heavy and the posting expects portfolio proof first.
Step 3: Write two bullets per project
Bullet one names scope, audience, and stack in the first eight words. Bullet two holds one illustrative outcome number inside the sample line, not as a claim about hiring markets. Example template: "Built Flask API for campus event signup; handled 120 concurrent users in load test." Swap in your real tools and count.
Avoid paragraph blocks under the title. Parsers treat long prose as orphan text. Two bullets mirror how Experience rows import cleanly.
Step 4: Align headers and read order
Type Experience, Projects, Education, and Skills as plain lines. Skip icon rows and text boxes that hide the word Projects in plain text. Single-column DOCX exports beat two-column templates when project dates must sit next to titles.
When layout fights you, read resume formatting errors that break ATS parsing before you add more project keywords to a scrambled file.
Step 5: Parse-check the export
Save PDF only after DOCX plain text shows Projects as its own section with dates. Upload the same file type the portal accepts. Re-run after any template change.
In Lever and Greenhouse previews, scan whether project tools appear inside Experience rows or as orphan lines. If Skills imported but Projects did not, rename the header in the source file and export again instead of adding a second Projects block in the portal editor.
Keep links on their own line under the bullets, not mid-sentence, so plain text doesn't break URLs across lines. One working demo link per entry is enough for a corporate upload.
Copy-paste into your notes app:
Posting tools: [4 terms from JD]
Project 1 title + dates: [Month Year – Month Year]
Bullet 1 (scope + stack): [line]
Bullet 2 (illustrative metric): [line]
Placement: Experience / Projects
Plain-text header check: pass / fail
Upload filename: [company-role-date]
I've screened Greenhouse files where a strong capstone sat in a footer labeled My Work while Experience held only internships. The candidate wasn't light on skill; the section name never mapped, so the project looked like stray text above the phone number.
Before: Ten GitHub links, zero dates, tools only in a sidebar.
After: Three dated entries, two bullets each, same tools echoed under the latest job where you used them daily.
Project lines recruiters skip
- Listing "Personal Project" with no year while Experience shows a full-time role above it.
- Using creative headers like Selected Work that importers drop into the body.
- Repeating the same stack in Skills without showing it in a project or job bullet.
- Pasting README paragraphs instead of outcome bullets.
- Leading page one with bootcamp repos when you have three years of paid work in the field.
Before: "I'll show every repo so they know I'm passionate."
After: "I'll show three builds that match the req stack and dates."
When projects support a lane change, thread the same proof into your summary spine. How to pick one story for your resume helps you pick which project leads on page one.
Parse-check before you add more keywords
Keyword stuffing in Projects without fixed headers still fails import. Scan the upload after header renames, not before.
Run a free ATS scan on the company-specific file. You're confirming Projects and Experience rows survived export, not chasing a decorative score.
Build your resume in a single-column template if plain text still scrambles dates after your manual fixes.
Three builds, then upload
How to add projects to your resume the right way is mostly filtering and labeling. Pick posting-aligned proof, date it, write two bullets, and keep headers boring so parsers attach tools to the right rows.
Save a company-named file before you submit on Workday or Lever. Tomorrow's req gets a different trio of projects, not a different work history.
Mirror your lead project metric in a short letter with Generate a cover letter so the attachment repeats the same stack language as bullet one.
Read more
Frequently asked questions
Paid work tied to an employer belongs under that job title with dates. Side builds, bootcamp capstones, and open-source contributions go in a labeled Projects section with their own month-year lines. Mixing unpaid work inside a full-time role without a label confuses both parsers and screeners who expect tenure to match pay.
Aim for two or three that mirror the posting stack and scope. More than four on page one reads like a portfolio dump and pushes recent employment down. Keep a master file with everything honest; trim the upload copy to what this req repeats in the responsibilities block.
Only when the link works and shows code or output you can discuss in a screen. A broken GitHub URL hurts more than no link. If the repo is private or stale, drop the URL and keep two bullets on outcome and tools instead.
Yes when you are early-career or changing lanes and the capstone uses the same tools as the posting. Label it Academic Project with dates, not as a job title. Once you have two years of paid work in the field, move the capstone down or off the upload unless it is your only proof for a required stack.