7 min read
Your portfolio page tells a story. Your resume parser reads a text dump. On the PDF, a polished Projects section with logos and color blocks looks like proof. In Workday, that same section often imports as undated lines sitting between Skills and Education, with no employer name attached. Recruiters ctrl-f the current job block first. If your best project work lives in a sidebar list, it won't score where it counts.
Check your resume for free after you move project lines into Experience bullets. You'll see whether tools like Python, HubSpot, or Jira still appear inside dated job text or if they've vanished into a footer the parser skipped.
The fix isn't more adjectives. It's structure: employer, Month Year dates, bullet one with scope, tool name, and one number when you've got an honest one. Below you'll see before/after pairs for software engineers, marketers, and project managers, plus a copy-paste skeleton you can adapt tonight.
You don't need a separate project write-up for every role you've held. Most candidates only need two or three project bullets under their current job and one under a prior employer where the work was distinct. That's enough proof for parsers and for recruiters scanning on a phone between meetings.
Job searching is hard enough without rewriting bullets that never reach a human. If a project needs one sentence of context a bullet can't carry, draft a short note with the cover letter generator after your Experience block is accurate.
Quick Wins
- Move top projects under the employer where you did the work.
- Lead bullet one with tool or outcome in the first eight words.
- Paste test: project tools appear on the same line as job title text.
Project bullets parsers read vs. lists they skip
Parsers score dated Experience text higher than undated project labels. Greenhouse, Workday, and Lever look for employer names, job titles, and Month Year dates. Bullets nested under that block inherit the timeline. A separate Projects header with no dates often flattens into generic lines the matcher treats like Skills tags.
A strong ATS-friendly project description answers four questions in one or two lines: what you built or shipped, which tools or channels you used, who it served or how big the scope was, and when it happened through the employer dates above it. Fancy layout doesn't help. Plain bullets with searchable nouns do.
Students and bootcamp grads can keep a short Projects section below Education when paid Experience is thin. Everyone else should fold project proof into the job block where the work occurred, including internships and contract roles.
Contract and freelance work follows the same rule. List the client or agency as the employer line with Month Year dates, then describe deliverables as bullets. "Freelance web developer" with no dates and a Projects list underneath is weaker than "Web Developer, Self-employed, January 2024 to Present" with two shipped-site bullets attached.
When a posting asks for a portfolio link, put the URL on its own plain line under the relevant bullet. Don't replace employer names with "See portfolio" links. Parsers need text they can search; humans need a path to proof after the keyword match fires.
For why weak bullets get skipped even when keywords match, read why weak bullet points get ignored . For section order on import, see how resume simplicity improves parsing .
ATS-friendly project descriptions by role
Pick the role closest to yours. Rewrite one bullet under the correct employer tonight, then paste your export into Notepad to confirm the tool name sits on the same line as the job title block.
Software engineer
Lead with the system or feature, name the stack in the first line, and attach scale or reliability proof when you have it.
Before: Projects section lists "E-commerce app" with no employer, no dates, and "various technologies."
After: Under Software Engineer, Acme Retail, June 2023 to Present: "Built checkout microservice in Python and FastAPI on AWS, handling 12k daily orders with 99.9% uptime monitoring in Datadog."
Marketing manager
Campaign projects belong under the brand or demand gen role where you ran them. Metrics go in bullet one, not a sidebar metrics box.
Before: "Led successful digital campaigns" in a Projects table with logo icons.
After: Under Marketing Manager, Bright Apps, March 2022 to Present: "Launched paid social in Meta Ads Manager for three SKUs, delivering 318 MQLs in Q1 at $41 CPL."
Project manager
Name methodology only when the posting asks for it. Otherwise lead with delivery scope, stakeholder count, and timeline.
Before: "PM for multiple cross-functional initiatives" with no tools or dates in a standalone list.
After: Under Project Manager, Northline Health, January 2024 to Present: "Delivered EHR rollout across four clinics in Jira, on schedule with 96% training completion in six months."
Data analyst
Before: "Dashboard project" under Projects with Tableau mentioned only in Skills.
After: Under Data Analyst, FinServe Co., August 2023 to Present: "Built executive churn dashboard in Tableau and SQL, surfacing accounts at risk for 14 regional reps weekly."
Customer support lead
Support project work often hides in generic duty lines. Name the platform, ticket volume, and outcome in bullet one.
Before: "Handled customer issues and improved processes" with Zendesk only in Skills.
After: Under Support Lead, CloudDesk Inc., May 2023 to Present: "Redesigned tier-two escalation workflow in Zendesk, cutting repeat contacts 18% across 2,400 monthly tickets."
Copy-paste: project bullet skeleton
[Action verb] + [deliverable] + in [tool/stack/channel] + for [scope/audience] + [metric or timeline if honest]
Examples:
- Built [feature] in [language/framework] on [cloud], [metric or scale]
- Launched [campaign type] in [ad platform] for [product line], [MQL/revenue metric]
- Delivered [initiative] across [sites/teams] in [tool], [on-time % or duration]
After you rewrite, run a paste test. If your project tool names appear above your current employer in plain text, move them back under the dated job block before you apply.
Tailor one project bullet per application when the posting names a specific stack or channel. Keep the employer and dates the same. Swap the tool name and outcome line to mirror the req without inventing work you didn't do. Honest overlap beats a generic project list that could apply to any role in the field.
Project lines that look strong on paper
Isolating projects in a designed grid. Tables and icon rows scramble on import. One-column bullets under the employer survive paste tests.
Using vague verbs without objects. "Responsible for website project" tells a parser nothing searchable. Name the site type, stack, and outcome.
Repeating the same project under every job. Duplicate lines look like stuffing. Keep each project under the role where you did most of the work.
I've screened stacks of these in Greenhouse, and the project line that wins is boring: employer, dates, tool name in bullet one, one number you can defend on a call.
Hiding tools in a Skills cloud only. List the platform in Skills as backup, but prove it inside an Experience bullet first. Matchers weight dated lines higher than undated tags.
Verify project terms parse cleanly
Rewrite one project bullet, export the file you'll upload, and confirm tool names still appear inside the Experience block on a plain-text paste.
Run a free ATS check with the posting pasted in. Keyword gaps for tools you used on a real project usually mean the term is trapped in a Projects footer or Skills icon row.
If you're rebuilding from scratch, build your resume in a single-column layout with standard headers before you paste in project bullets from the examples above.
This won't fix applying without the core skills the req lists. It stops solid project work from living in a section parsers treat like decoration.
Rewrite one project bullet tonight
ATS-friendly project descriptions belong under dated employers with tools and scope in line one. Move your strongest project out of a floating list, mirror the posting's must-have stack honestly, and paste-test the export before you submit.
Pick one before/after pair from above, fix bullet one under your current role, and check your resume for free on the posting you're targeting. That's how project proof stops living in a section parsers never score.
Read more
Frequently asked questions
Only when you're a student or career changer with thin paid Experience. For most applicants, parsers weight dated employer blocks higher than undated project lists. Put project scope inside bullets under the job or internship where you did the work. A standalone Projects section without Month Year dates often imports as floating skill tags with no employer attached.
One to two lines. Open with the tool or outcome in the first eight words, then add scope: team size, timeline, or one metric. Long paragraphs flatten on import and bury the keyword a recruiter ctrl-f's. If you need a second line for context, keep line one as the searchable proof.
One honest number or scope marker per bullet is enough when you have it: users served, budget, timeline, error rate, or ticket volume. If you lack a metric, lead with scope instead: 'Built internal API for three product teams' still beats 'Worked on API project.' Never invent figures to fill a template.
Plain URLs on their own line under the bullet are fine in DOCX. Avoid icon buttons or QR codes that parsers skip. Spell the repo or stack in text inside the bullet first so keyword matchers see Python or React even if the link breaks on import.