11 min read
You've got twelve repos and a portfolio site with animations. The recruiter has ninety seconds and a req that says React, TypeScript, and accessibility. They're not clicking every thumbnail. They're reading whether your resume proves you already did the work they're hiring for.
Most frontend applicants list project names like Todo App or Dashboard without saying who logged in or what broke in production. US hiring teams treat those as noise. The projects that move you to screen read like mini case studies squeezed into one bullet.
Start with a free resume check against the posting you want. If React only appears in Skills and your Projects section is empty, reorder before you polish README badges.
Below you'll see teardown pairs for junior, mid-level, and switcher portfolios, what to cut, mistakes that waste space, and a copy-paste project bullet block you can adapt tonight.
Quick Wins
- Keep two to four projects that match paragraph one on the target posting.
- Put stack keywords in the bullet text, not only in the repo name.
- Add one README sentence a recruiter can skim without running npm install.
- Move bootcamp clones off the resume if you cannot explain a custom feature.
What US hiring teams scan before they open GitHub
The order matters: title and employer or project header, dates, bullet one, then maybe a link. Hiring managers in Greenhouse often never leave the parsed resume pane during first triage. Your live site matters at interview, not at initial keyword pass.
A composite junior applicant listed six tutorials under Projects with no stack in the bullet text. Workday search for TypeScript returned nothing. Same person, two rewritten lines naming React hooks and WCAG fixes on a volunteer site, surfaced on the next req with those terms in the posting.
Mid-level files win when one bullet cites production constraints: design system version, bundle work, or form flows tied to revenue paths. Personal repos can carry that proof if you describe real users, not just CSS tricks.
This won't replace a live coding screen. It stops strong builders from losing triage because the resume read like a link dump.
For stack placement across the whole file, read UI engineer resume keywords for US ATS . Projects belong in the same keyword plan as Experience.
Staffing and agency reqs often ask for a portfolio URL in a separate field. Treat that field as a backup. The resume PDF still has to parse with keywords intact when the recruiter never clicks through.
If you're applying to product companies and consultancies in the same week, keep one master project list and swap which two entries lead based on paragraph one. Do not maintain five versions with different fake metrics.
Frontend developer resume projects that impress US hiring teams
Use the pairs below as templates. Numbers inside bullets are sample illustrations for your own metrics, not claims about industry averages.
Junior: volunteer dashboard vs tutorial list
Before: Projects: Weather App, Todo App, Calculator (no stack in text).
After: Personal project: React + TypeScript intake dashboard for a food pantry, keyboard-navigable forms, sample line: cut volunteer check-in steps from 6 fields to 3 for weekend shifts.
Junior: bootcamp capstone vs customized OSS fork
Before: Built e-commerce site per coursework requirements.
After: Extended OSS checkout component with Stripe test mode, lazy-loaded product grid, sample line: held LCP under 2.5s on mid-tier Android in Lighthouse run documented in README.
Mid-level: internal tool buried vs bullet-led
Before: Worked on frontend for various internal tools.
After: Led React migration for support console used by 40 agents, sample line: split monolith bundle into route-based chunks and trimmed repeat ticket lookups with shared filter state.
I've screened frontend stacks in Greenhouse where the only React proof lived in a portfolio URL field recruiters skip, and the Experience section still said participated in agile ceremonies.
Mid-level: design handoff vs measurable UI delivery
Before: Collaborated with designers on new features.
After: Shipped Figma-based account settings in Next.js with focus-trapped modals, sample line: closed 12 a11y bugs from QA before release branch freeze.
Career switcher: unrelated job vs project bridge
Before: Retail manager role with no tech bullets, five unrelated repos linked.
After: Projects header with two entries naming Vue inventory kiosk for former employer volunteer project and open-source docs site PRs, each with stack and user in bullet one.
Contract: client anonymity vs scoped line
Before: Frontend developer for client (NDA).
After: Contract React work for fintech onboarding (client confidential), sample line: built multi-step KYC flow with shared validation schema and unit tests in Testing Library.
Open source: drive-by commit vs owned issue
Before: Contributed to open source.
After: Maintained docs site for OSS charting lib, sample line: shipped accessible tooltip pattern adopted in v4.2 release notes, PR link in README.
Performance project: vague speed claim vs measured work
Before: Improved website performance.
After: Profiled React re-renders on catalog page, sample line: memoized list rows and deferred image decode, documented before/after Lighthouse run in repo wiki.
Copy-paste block: project bullet skeleton
Copy-paste project line (adjust brackets)
[Project or Employer] · [Month Year – Month Year]
• Built [feature] in [React/Vue/etc.] + [TypeScript/testing tool] for [users/stakeholders];
[sample outcome: reduced steps, improved metric in README, shipped before deadline].
Repo: github.com/[handle]/[repo-with-readme]
Edge case: employer blocks public code. Describe architecture and tests in text, offer walkthrough on screen, and never invent a repo link.
Edge case: team project. Name your slice in bullet one: owned checkout stepper, wrote Cypress smoke tests, paired on API types. Credit the team in interview, not with vague we statements on the resume.
Portfolio habits that waste resume space
Listing every tutorial. Cut clones unless you added a feature you can demo in thirty seconds.
Link-only project rows. Parsers and humans need keywords in the bullet body. URLs at the end, not alone.
Skills soup without project proof. Twelve frameworks in Skills with zero matching bullets reads like keyword stuffing.
Screenshot-only portfolios. Images without alt text in the PDF do not help parsers. Describe the UI change in words recruiters can search.
Stale repos. If main branch is two years old, either refresh README with a current setup note or drop the link from the resume until you do.
Before: Projects section as a table of icons and stars.
After: Plain text bullets, single column, same heading style as Experience.
Read resume rejected by ATS when your project table breaks import order before a human sees the GitHub link.
Match the posting before you link repos
Paste the req into score your job match and note which frameworks appear in paragraph one. Rewrite two project bullets to mirror those terms honestly before you add another repo.
Export a single-column PDF and run the ATS checker to confirm React and TypeScript survive parse. If Skills shows keywords Projects stripped, fix layout before you spam applications.
When the posting wants a short letter, draft structure in the cover letter generator and cite one project outcome the letter can repeat without duplicating every bullet.
Run the checker on the same file you upload to Greenhouse, not on the HTML portfolio page. Two different exports, two different parse results. Align them before you batch apply.
Do this now: Pick your strongest repo, update README setup in three lines, then mirror that stack in bullet one on the resume.
Pick two projects to keep
Frontend developer resume projects that impress US hiring teams are the ones you can defend on a phone screen without opening slide decks. Pick two, rewrite bullet one on each with stack and user, cut the rest from the PDF, and keep READMEs honest.
Open your master resume. Delete the weakest tutorial. Replace it with one line from the copy-paste block. Run match score on a live req before you upload again.
Your repo history can be messy. Your resume project lines should not be.
Read more
Frequently asked questions
Two to four strong entries beat a laundry list. Each line should name stack, user or business outcome, and one proof point. If you cannot explain the project in thirty seconds on screen, cut it or move it to a portfolio link only.
Yes when the repo is public, README explains setup, and main branch reflects the work you claim. One clean link per featured project in a Projects or Experience bullet beats five dead forks. Never link a bootcamp template you never customized.
They care whether the bullet proves the skills in the posting. Paid work wins when you can describe production constraints. Personal or open-source work counts when it shows initiative and matches the stack. Label unpaid work honestly as personal project.
Under Experience when it was paid or contract. Use a Projects section when it was school, personal, or OSS. Keep the same Month Year style as jobs. Do not bury the only React proof under Skills with no bullet.
Icons, tables, and link-only lines without keywords from the posting. Write React, TypeScript, and accessibility in plain text bullets. Repo URLs belong at the end of the line, not as the only content in the row.