How to write a CV for a frontend engineer role

What gets scanned first

A frontend hiring manager reading your CV is not starting at the top and working down. They are checking, in this rough order: whether your stack overlaps with theirs, whether you have something they can actually look at rather than take your word for, and whether the way you describe your work suggests you've shipped production code or just followed tutorials. This matters more in frontend than in most fields because there is no licensing body standing behind your claims. A nurse's PIN or a solicitor's practising certificate does verification work that the CV doesn't have to. Your CV is the whole case.

That means the vaguer end of CV writing — "worked with modern JavaScript frameworks", "experience across the full stack" — reads as a warning sign rather than a summary. It could mean anything from six months following a course to five years maintaining a production app. Name the frameworks: React, Vue, Angular, Svelte. Say whether it was TypeScript or JavaScript, and if TypeScript, whether you were writing types or inheriting a loosely-typed codebase someone else built. If the job advert says "React + TypeScript + GraphQL", your CV should use that exact combination near the top, not a paraphrase of it. Skim-readers and any automated keyword pass are both looking for the words in the advert, not synonyms for them.

The stack line, and why depth beats breadth

Most frontend CVs list tools as a flat, undifferentiated block: React, Redux, Webpack, Sass, Jest, Git. That tells a reader almost nothing about how deep the experience goes. Better is to attach context: which build tool (Webpack, Vite, esbuild), which testing approach (Jest and React Testing Library for units, Cypress or Playwright for end-to-end), which state management you actually reached for and why (Redux Toolkit versus Zustand versus just Context, depending on the size of the problem), which meta-framework if any (Next.js, Remix, Nuxt).

A line like "migrated a legacy class-component codebase to React 18 with hooks, removed the last uses of componentWillMount" says more than three years of "React" on a skills list. It shows you've worked inside an existing system, not just started new ones. If you've done CSS at any depth, say which approach — CSS Modules, styled-components, Tailwind, BEM conventions on plain Sass — because these represent genuinely different working practices and a hiring manager on a Tailwind codebase will read "CSS" and still not know if you'll be productive on day one.

How experience gets evidenced in this field

In frontend, unlike most other engineering disciplines, a meaningful amount of your work can simply be looked at. That changes what "evidence" means on your CV. A link to a GitHub profile with real commit history, a link to a live deployed site you built, a link to a pull request you're proud of, a link to a component library or Storybook instance — these do more work than a bullet point claiming the same thing. If you've contributed to an open-source project, name it and link the merged PRs, not just the project.

Where the work is under an NDA and you can't link the code, describe the problem and the outcome rather than inventing a number to fill the gap. "Reduced the bundle size on the checkout flow through route-based code splitting" is a real, checkable-in-interview claim. A specific percentage you can't stand behind under questioning does more damage than the vague version, because it's the first thing an interviewer will probe.

A personal site or portfolio is worth mentioning on its own, because for this occupation it is itself a piece of evidence, not just a container for one. A frontend engineer's own site is read the way a photographer's portfolio or a chef's plated dish is read: it's a direct sample of the thing you're claiming to be good at. If you don't have one, that absence is noticed by anyone hiring for this role specifically — it's less noticed in roles where the work product isn't visually or functionally inspectable.

Qualifications, and what doesn't gatekeep here

There's no licence or professional registration for frontend engineering. A computer science degree helps at the graduate-scheme stage of large employers, where it's sometimes used as an initial filter, but it isn't a gate the way a practising certificate is in law or a PIN is in nursing — plenty of working senior frontend engineers are self-taught or came through a bootcamp. If that's your background, name the bootcamp and cohort, but don't lead with it. Lead with what you shipped afterwards. The certificate got you in the door of your first job; it isn't doing any work for you three jobs later.

Vendor certifications (cloud provider badges, framework-specific certificates) are weak signals in this field. They're not harmful to list, briefly, near the bottom, but they don't substitute for shipped, production work and shouldn't take up space that a link to real code could occupy instead.

What frontend candidates routinely leave off

A few things turn up missing again and again, even from CVs that are otherwise well put together:

• Accessibility work. If you've done anything toward WCAG conformance, ARIA attributes, keyboard navigation, or screen reader testing, say so specifically — "brought the checkout flow to WCAG 2.1 AA" rather than leaving it out because it feels like a minor part of the job. Some hiring managers now ask about it directly and are visibly surprised when a candidate has done the work but never mentioned it.
• Performance specifics. "Improved performance" is a sentence that tells a reader nothing. If you've worked on Core Web Vitals — LCP, INP, CLS — or moved a Lighthouse score, name the metric. You don't need an invented percentage; naming which metric you worked on and what you did to move it is enough to make the claim checkable.
• How you worked with design. Frontend sits at the seam between design and engineering, and how that handoff actually worked — Figma-to-component workflow, building or maintaining a design system, working inside or building a Storybook instance — is routinely left off CVs even though it's often a large part of the actual day-to-day job.
• Cross-browser and responsive work. Taken for granted, rarely stated, and occasionally the actual reason a candidate is being hired — a team that's just had a painful Safari-specific bug wants to know you've dealt with that class of problem before.
• Code review and CI/CD practice. Whether you've been part of a PR review culture, paired regularly, or maintained test coverage on a codebase says something about engineering maturity beyond "wrote code", and it's frequently the difference between a CV that reads as junior and one that reads as ready for more responsibility, regardless of years of experience listed.

What to do next

Open the actual job advert next to your CV. Match the stack line to its exact wording. Add three links near the top: your GitHub, a live deployed project, and one specific pull request or component library you can point to. Cut anything that reads as true of any developer rather than true of you on this stack. If you've done accessibility or performance work, name the metric or standard rather than the adjective.

jobmarket.pro reads the advert in full, checks it against your existing profile, and prepares the application from that — it doesn't invent experience you don't have.