React Developer CV example

What recruiters expect

Before writing anything, it helps to know what the person reading is checking for. In this field that is usually a short, specific list:

• Production React, not tutorial React: routing, data fetching, caching, error handling and forms in a codebase other people also work in.
• A clear position on TypeScript. Many React teams now write typed code by default, so expect to be asked how you type component props and API responses.
• Evidence that you understand rendering: why a component re-renders, how you found a slow one, and what you changed.
• Testing that goes beyond snapshots. Naming a testing library is weak; describing what you test and why is strong.
• Some sense of how your work reached users: build pipeline, preview deploys, feature flags, release cadence.

Recommended CV structure

This is the running order the example uses. It is a starting point rather than a rule, but the order reflects what tends to be read first in this profession.

1. Profile — Three or four lines positioning you for the role.
2. Technical Skills — Grouped skills, for example "Languages" and "Tooling".
3. Professional Experience — Paid roles, in reverse chronological order.
4. Selected Projects — Work you built, with outcomes and the stack used.
5. Education — Degrees, diplomas and school-leaving qualifications.
6. Certifications — Completed certifications with the issuing body.
7. Languages — Spoken languages with CEFR levels.

Sections worth adding

• Open Source — Worth adding only if you have merged pull requests you can point to. Link to the pull requests themselves, not the profile, and describe what each one changed.
• Awards — Only if the award is technical - hackathon wins age quickly after your second job.
• Community — Meetup talks and mentoring read well for senior roles where you will be expected to raise the team.

Skills worth including

Grouped rather than listed in one block. Grouping makes a long list readable and shows that you can tell the difference between the things you use daily and the things you have touched.

Beyond the technical list: Code review, Pairing with designers, Writing technical specs, Mentoring junior developers, Estimating and scoping. These belong inside your experience bullets, demonstrated, rather than in a list of adjectives.

Core React knowledge versus ecosystem tools

React adverts often list a dozen tools, but technical interviews tend to test a much smaller core. Put the core where it can be seen, and name ecosystem tools only when you have used them for something you can describe. The split below is a working convention rather than an official definition - teams draw the line in slightly different places.

The core: expected, and tested in interview

• Components, props and composition — show a component you designed for other people to reuse, and the props you chose to expose or deliberately left out.
• State and hooks — useState, useReducer, useEffect and custom hooks. The convincing evidence is a hook you extracted, or an effect you removed because it never needed to be one.
• Rendering behaviour — why a component re-renders, keys in lists, and memoisation used where profiling justified it rather than everywhere.
• Forms and events — controlled and uncontrolled inputs, validation timing and error messages a screen reader announces.
• TypeScript with React — typed props, events and API responses, including what happens when the API changes shape.
• Testing components — behaviour-level tests that click and type like a user, rather than snapshots that fail on every restyle.

The ecosystem: name it when it is true and relevant

• Next.js or React Router in framework mode — name it when the role is server-rendered or search-sensitive, and say which rendering approach you used and why.
• TanStack Query, SWR or Apollo Client — worth naming when caching server data was part of the work - attach it to the problem it solved.
• Redux Toolkit, Zustand or similar — list the ones you have shipped with. The library named in the advert matters more than how many you know.
• Tailwind CSS, CSS Modules or CSS-in-JS — one line is usually enough, unless the role is design-system work where styling architecture is the job.
• Vite or Webpack — worth a bullet only if you changed the build: a migration, a bundle reduction, a faster pipeline.
• Storybook, Playwright, MSW — component documentation, end-to-end tests and API mocking. Tie each one to a result rather than listing it.

If an ecosystem tool appears in the advert and you have used it, mirror its exact name. If you have not, leave it off. A missing ecosystem tool is usually learnable on the job; a listed tool you cannot discuss tends to surface quickly in a technical interview.

Example professional summary

Three or four lines, positioned for the role rather than describing your personality. Two versions you can adapt:

React and TypeScript developer, four years in, currently maintaining a Next.js property search used by three internal teams through a shared Storybook library. Recent work: typing an untyped listings API at the boundary so a renamed field fails in CI, and halving first render on the listing page behind a Lighthouse CI budget that keeps it there. Happy owning a feature from design review to rollout, and happy to be the person who writes the Playwright spec for it.

React developer focused on accessible, well-tested interfaces. Experience across Next.js, TanStack Query and Tailwind CSS in a codebase of around 90,000 lines, with a habit of leaving the parts I touch better documented than I found them.

Writing your experience

The difference between a CV that gets a call and one that does not is almost always in the bullet points. Each pair below shows a real rewrite of the kind of line that appears on most CVs in this field.

Taken from the example

The sample CV for this profession is fully written. A few sections from it, so you can see the level of specificity that works:

Experience

Front-End Developer, Northgate Property Group

• Rebuilt the property search interface in Next.js and TanStack Query, replacing a jQuery page that had grown to 4,000 lines and was the source of most front-end bug reports.
• Halved time to first meaningful render on the listing page: code-split a 610 KB map bundle behind an intersection observer, moved two analytics scripts to after hydration, and served hero images through next/image. Lighthouse CI now fails the build if the mobile performance score falls below 85, so the win does not quietly erode.
• Typed every response from the listings API with generated TypeScript types and validated them at the boundary, so a renamed back-end field now fails in CI instead of in production.
• Designed and shipped a shared component library in Storybook, now used by the search, agent portal and marketing teams; new landing pages went from roughly two days to half a day.

Projects

• Fieldnote — An offline-first note-taking app for site surveyors, built with React, IndexedDB and a service worker for full offline use.
• form-guard — A small hook library for accessible form validation: announces errors to screen readers, labels fieldsets and returns focus to the first invalid field.

Education

• BSc (Hons) Computer Science, University of Leeds — Upper Second Class (2:1)

Certifications and registration

• Meta Front-End Developer Professional Certificate — Coursera
• Web Accessibility (W3Cx) — edX

Common mistakes

ATS considerations

Applicant tracking systems behave differently by sector, and generic advice is often wrong for a given field. These points are specific to react developer applications:

• Write "React" as a standalone word somewhere in the skills section. A recruiter searching a candidate database may type the exact token, and not every search expands "ReactJS" or "React.js" to match it.
• Keep framework names out of image-only logos or skill bars. A rating out of five is unreadable to a parser and unconvincing to a human.
• Spell out both forms once where they differ in the wild: "CI/CD (continuous integration and delivery)", "UI/UX".
• If the advert names a specific state library, mirror its exact wording in your CV where it is true - "Redux Toolkit" and "Redux" can be searched as different terms.
• Put your GitHub as plain text as well as a link. Some parsers keep the anchor text and drop the address.

The Minimal ATS layout is built for this, and the ATS guide covers what parsers do to a file in more detail.

Guides that go deeper

This page applies general CV advice to one field. The full treatment of each part is here:

• How to Write a Software Developer CV — What technical reviewers look for, why the stack list is not enough, and how to write about work you cannot show.
• How to Describe Work Experience — The difference between listing duties and demonstrating impact, and a repeatable way to rewrite any weak bullet point.
• How to List Skills on a CV — Group them, be specific, and cut anything you would not want to be interviewed on for ten minutes.
• How to Make an ATS-Friendly CV — What applicant tracking systems do to your file, the four failures that matter, and which of the usual claims about them anybody can actually stand behind.

Questions about react developer CVs

Sources

• React blog: Sunsetting Create React App (14 February 2025)(opens in a new tab) — checked 21 Sept 2026
• React blog: React v19 (5 December 2024)(opens in a new tab) — checked 21 Sept 2026
• React versions and release dates(opens in a new tab) — checked 21 Sept 2026