The specific signals an experienced frontend engineer hiring panel grades on during the eight-second scan.

• Summary names a surface owned, not a personality

  'Owns the design system at Vellum' beats 'passionate React developer.'

• Core Web Vitals in real units (LCP, INP, CLS)

  Latency in ms (LCP 3.4s → 880ms), INP in ms, CLS as a decimal. The vocabulary hiring panels recognize as current.

• Bundle / hydration / TTI numbers — before and after

  'Cut bundle 280kb' or 'TTI 3.4s → 880ms' — concrete deltas, not 'improved performance.'

• Accessibility named explicitly (WCAG, ARIA, axe)

  AA conformance, audit work, screen-reader testing. A frontend resume without accessibility signal reads as junior at sophisticated companies.

• Design + PM partner count or surface count

  'Partnered with 4 PMs across 14 product surfaces' is the senior-track signal. Frontend is a collaboration role; the resume should prove it.

• One portfolio or recognized OSS link

  A live portfolio with shipped work, or a merged PR to Radix / shadcn / TanStack / Framer Motion. Don't list tutorial projects.

• Education to one line (mid+ levels)

  School, degree, year. Frontend hiring panels weight portfolio and OSS over education past the entry level.

1. 1

   Open with the surface and the framework version

   A staff-frontend summary names a surface: 'Owns the design system at Vellum across 14 product surfaces.' A senior summary names the same: 'Frontend engineer on the editor team at Linear; ships the canvas and selection model.' A mid-level summary names a feature: 'Frontend engineer at Vellum; owns the data-table component family used across 14 surfaces.' An entry-level summary names a project: 'Recent CS grad; shipped the merchant accessibility-audit pass as a Stripe intern (47 WCAG violations cleared).'

   The pattern is consistent: the noun matters more than the adjective. A hiring panel reading the first sentence of your summary is asking 'what does this person actually own,' not 'what kind of developer are they.' Lead with what.

   Name the framework with its current version. 'React 19 / Next.js 16 App Router' is the 2026 signal that the candidate has shipped in the current era. 'React / Next.js' parses but reads as undated. The version detail is especially important post–App Router migration because hiring managers are explicitly screening for current-era shipping. If you've worked across multiple meta-frameworks, name the one you primarily ship with — listing three meta-frameworks in your summary reads as resume-padding.

2. 2

   Quantify with Core Web Vitals and bundle numbers

   LCP, INP, CLS, TTI, FCP, bundle size, hydration time, JS execution time — these are the units frontend hiring panels grade on. 'Cut LCP from 3.4s to 880ms' is read; 'improved page load times' is skipped. The denominator matters: a 50% LCP improvement on a marketing site that already loaded in 800ms is a small win; a 50% LCP improvement on a site that loaded in 4s is the kind of work a hiring panel pulls forward.

   The specific numbers to favor: • LCP: report in seconds or milliseconds, with both before and after. • INP: report in ms; INP replaced FID in March 2024 as the Google-graded responsiveness metric. • CLS: report as decimal (e.g., 0.18 → 0.04). • Bundle size: kb delta, with the migration that caused the delta. • TTI / TTFB: still useful for marketing-heavy sites. • Accessibility: WCAG conformance level + count of flows or violations. • Render performance: render count, time-to-first-paint of a data-heavy component, virtualization improvement. • Design-system adoption: count of engineers and product surfaces using the system.

   If you don't have the exact baseline, estimate with language that signals you're estimating: 'roughly halved,' 'order of magnitude better,' 'sub-second from multi-second.' Hiring panels respect honest estimation and distrust suspicious precision.

3. 3

   Name your stack with versions, weighted toward depth

   A frontend Skills section should be fifteen to twenty-five items, grouped lightly: 'Languages: TypeScript, JavaScript, CSS' / 'Frameworks: React 19, Next.js 16, Storybook' / 'Tooling: Vite, Vitest, Playwright, axe-core.' Group labels are optional but they parse well.

   What to weight toward: depth in your primary framework (React + ecosystem libraries you actually ship with — TanStack Query, React Hook Form, Framer Motion, etc.), one styling system, one component-testing tool, one E2E tool, one accessibility tool. Naming the specific libraries you ship with parses better than naming the abstract category.

   What to drop: frameworks you touched briefly in a side project. Listing React, Vue, and Svelte signals you've sampled all three; listing only React signals you ship with React. Hiring panels at sophisticated companies prefer the second pattern.

   List CSS architecture choices precisely: 'Tailwind' is parseable; 'CSS' alone is not specific enough for the parser to grade. If you ship with CSS Modules, vanilla-extract, or styled-components, name it.

   Do not list libraries you have not shipped with in at least three months of production work. Listing a library you read a tutorial about will read as inexperience to a hiring panel at a sophisticated frontend shop — they would rather see depth in your real stack.

4. 4

   Include the design-system and accessibility signal

   Frontend hiring at sophisticated companies — Linear, Vercel, Stripe, Shopify, Figma, Notion, the FAANG tier — increasingly weights two specific kinds of work above raw shipping: design-system ownership and accessibility leadership. These are the items that move a resume from 'phone-screen' to 'on-site' pile.

   Design-system signal that reads well: • Building a token system on Storybook + a recognized headless layer (Radix, ARK, React Aria, Headless UI). • Adoption metric: count of engineers and surfaces using the system. • Partner count: number of designers and PMs you collaborate with on system work. • Migration: surfaces migrated from a legacy system or third-party library to the new system, with bundle and consistency outcomes.

   Accessibility signal that reads well: • WCAG conformance work (specify AA or AAA, specify the standard version). • Count of violations cleared or flows audited. • Screen-reader testing with named screen readers (NVDA, VoiceOver, JAWS). • Authoring a team or org accessibility checklist that other teams adopted.

   If you don't have either signal, focus on shipping velocity and concrete user-facing impact in your bullets. But know that at the senior+ level, the absence of either signal will narrow the kinds of companies that move your resume forward.

5. 5

   Close with portfolio or recognized OSS

   A frontend resume's high-signal closing item is one of three things: (1) a portfolio with shipped work that goes beyond personal sites, (2) a merged PR to a recognized React-ecosystem library, or (3) a side project with non-trivial adoption or traction.

   What counts: • Merged PRs to libraries with 1k+ stars (named project, named PR, brief technical description). Radix UI, shadcn/ui, TanStack, Framer Motion, React Hook Form, React Aria, Mantine, Chakra UI — these are the names a hiring panel recognizes. • A solo open-source library with 200+ stars and demonstrable use. • A live portfolio with shipped work (3-5 projects, each with a short case-study description). • A talk at a recognized venue (React Conf, JSConf, JSNation, ChainReact, CSSday). • A meaningful technical-blog post that gained traction (citations, HN front page, conference quote).

   What doesn't count: tutorial projects (todo apps, weather apps), landing-page clones, portfolio sites without underlying case-study work, contributions to your own throwaway repos. Filler in this section weakens the rest of the page by association.

   If you don't have any of these yet, leave the section out entirely. A frontend resume without an OSS line is normal; a frontend resume with a thin OSS line is a red flag. The exception is entry-level candidates — a portfolio with shipped work (a CRDT collaborative whiteboard your university capstone used, for example) is the highest-leverage thing you can put on the page.

Each follows the [verb] [object] [number] structure hiring managers grade against. Copy them as a starting point, swap in your own numbers, and read the annotation to understand why each one works.

• Core Web Vitals

  Cut LCP on the marketing site from 3.4s to 880ms via route-segment loading + critical-CSS extraction; INP improved from 320ms to 140ms on the same release.

  Why it works: Names two Core Web Vitals (LCP + INP) with absolute before/after, and explains the technical intervention. INP is the 2024+ signal; naming it instead of FID shows the candidate has stayed current. The 'same release' detail signals the candidate understood the perf budget across metrics, not just one number.

• Design system

  Built the React + TypeScript design system (Storybook + custom design tokens) used by 70+ engineers across 14 product surfaces; v2 token migration completed without a single regression on visual-regression tests.

  Why it works: Names the stack (React + TS + Storybook + tokens), the adoption (70 engineers, 14 surfaces), and the migration outcome (visual-regression pass). 'Without a single regression' is a credibility detail — hiring panels recognize the discipline required to ship a token migration cleanly.

• Accessibility

  Led the WCAG AA remediation pass across the primary app; cleared 84 violations across 14 surfaces and authored the team's axe + screen-reader testing checklist (adopted by 3 sister product teams).

  Why it works: Names the standard precisely (WCAG AA), quantifies the work (84 violations, 14 surfaces), and surfaces a documentation outcome that scaled (3 teams adopted the checklist). Accessibility leadership at this level is a senior-track signal.

• Performance

  Migrated the data-table surface from a third-party grid (AG Grid) to a custom TanStack-based one; bundle shrank by 280kb and render latency on 10k-row tables fell 4×.

  Why it works: Names both libraries (AG Grid → TanStack), gives bundle delta in kb (the unit hiring panels speak), and gives a render-latency improvement at a specific scale (10k rows). Three follow-up interview questions are immediate.

• Feature shipping

  Owned the dark-mode rollout across the product including the accessibility audit; passed WCAG AA contrast on all primary surfaces and shipped without a single rollback.

  Why it works: Names the surface owned (dark mode), the standard the audit cleared (WCAG AA contrast), and the rollout-quality signal (no rollback). Dark-mode work is a common interview topic — the bullet sets up a strong story arc.

• Product shipping

  Shipped the cycle-planning UX end-to-end; adoption among >20-person teams reached 78% within 6 months of launch.

  Why it works: Ownership signal ('end-to-end'), specific user segment (teams >20), and an adoption metric (78%) with timeframe (6 months). Adoption metrics are the gold standard for product-frontend work — they prove the build shipped to real users who chose to keep using it.

• Testing

  Reduced flaky Playwright tests on the planning flow from 12% to under 2% by introducing deterministic time + a contract-test layer between the frontend and the GraphQL gateway.

  Why it works: Names the test framework (Playwright), the before/after on flakiness, and the specific fix (deterministic time + contract tests). 'Contract-test layer' signals frontend depth — engineers familiar with the pattern recognize it as the right answer.

• Tooling

  Authored the team's Storybook + Chromatic visual-regression pipeline; CI catches design-token drift before merge, and review cycles on design-system PRs fell from 4 to 1.

  Why it works: Names two tools (Storybook + Chromatic), the technical purpose (token drift), and a process outcome (review cycles 4 → 1). Tooling investments are hard to demonstrate on a resume; the review-cycle number proves the investment had an outcome that engineering leadership measures.

• Mentorship

  Mentored two junior engineers through their L3-to-L4 promotion cycles, focusing on accessibility + performance ownership; both promoted on first eligibility.

  Why it works: Levels (L3, L4) parse across the industry. The mentorship focus (a11y + perf) signals the senior was teaching the load-bearing skills, not generic engineering. 'Both promoted on first eligibility' is the verifiable outcome.

• Open source

  Three merged PRs to radix-ui/primitives — one closed a focus-trap edge case in Dialog under nested portals; one shipped keyboard navigation in Menubar.

  Why it works: Named library (Radix UI), PR count (three), and two technical descriptions that signal frontend depth. 'Nested portals' + 'focus-trap' is the kind of detail a hiring panel reads as senior-level signal. Radix is also widely recognized across the frontend ecosystem.

• Side projects

  Shipped react-flex-grid, a headless responsive-grid primitive built on container queries — 720 GitHub stars; powering layout systems at two recognized B2B SaaS companies.

  Why it works: Side projects that show real architectural thinking read at a higher level than personal portfolios. 'Container queries' signals current-era CSS; the adoption metric (two companies using it internally) is the differentiator. Star count is a secondary signal.

• Internship

  Built the merchant-dashboard accessibility audit as a Stripe intern; cleared 47 WCAG violations and authored the team's a11y checklist (used by the design org through 2024).

  Why it works: Two parenthetical details make this internship bullet read as production work, not coursework: the count of violations (47) and the lasting artifact (the checklist still in use). For an entry-level candidate, this is the single most important kind of bullet — it proves they shipped in a real frontend environment.

Same intent, two phrasings. Read why the right column lands on the keep-pile and the wrong column doesn't.

Patterns our writers see most often when reviewing frontend engineer resumes — each one disqualifies candidates faster than weak experience does.

• Mistake

  Opening with adjectives instead of a surface. 'Passionate React developer with a love for clean code and pixel-perfect interfaces.'

  Fix

  Lead with the surface and the framework version. 'Frontend engineer at Vellum, owns the design system across 14 product surfaces. React 19 + TypeScript; most recent work cut INP from 480ms to 120ms.' Two sentences, twenty words, and the hiring panel knows what to ask in the phone screen.

• Mistake

  Listing every framework you've touched. 'Frameworks: React, Vue, Svelte, Angular, Solid, Qwik, Astro, Remix, Lit, Alpine, Stimulus, Backbone, Ember, Knockout.'

  Fix

  Three to four frameworks you've shipped in for production work. Hiring panels at sophisticated frontend shops read long framework lists as inexperience, not breadth. The Goldilocks band is depth in one primary framework + one or two adjacent.

• Mistake

  Reporting FID instead of INP.

  Fix

  INP replaced FID in March 2024 as the Google-graded responsiveness metric. Frontend hiring panels read an FID number as 'this candidate hasn't kept up.' Use INP — and if you don't have INP data, use the LCP and CLS numbers and skip the responsiveness metric entirely rather than reporting deprecated FID.

• Mistake

  A long 'Soft Skills' or 'Personal Qualities' section. 'Communication, attention to detail, team player, problem solver.'

  Fix

  Cut it. The bullets in the experience section should already demonstrate them. Replace the soft-skills cloud with a Languages section (natural languages, with proficiency level) if you have meaningful proficiency outside English.

• Mistake

  Vague performance claims. 'Optimized the React app for better performance.'

  Fix

  Name the Core Web Vital, the absolute before/after, and the technical intervention. 'Cut LCP from 3.4s to 880ms via route-segment loading + critical-CSS extraction' is the bullet a hiring panel reads. Vague performance claims read as 'has not measured.'

• Mistake

  Color-coded skill bars showing percentage proficiency.

  Fix

  Cut them. Frontend recruiters universally dislike skill bars — they're unparseable for the ATS and read as design-noise to hiring managers. List skills as a clean grouped list with depth implied through context (a 'Frameworks' section that names three frameworks reads as deep; one that names ten reads as shallow).

• Mistake

  Two-page resume with fewer than 7 years of frontend experience.

  Fix

  One page. Frontend hiring panels rarely open page two unless page one earned the read. Trim ruthlessly: internships to one line, education to a single row, oldest role to two bullets if the recent roles are stronger.

• Mistake

  A portfolio link that goes to a personal site without case studies.

  Fix

  Either link a portfolio with 3-5 case studies (each with the problem, the work, and the outcome), or skip the portfolio link entirely. A bare portfolio site without case studies reads as weaker than no portfolio link — it sets the expectation of work to look at and then doesn't deliver.

Strong verbs lead strong bullets. Replace generic openers (worked on, helped with, was responsible for) with the specific verb that matches what you actually did.

ATS pipelines weight your Skills section as a structured list. Include 15-25 of the items below if they match your experience — not soft skills.