Almost every front-end developer resume shows the same line: React, TypeScript, Redux, Next.js, Tailwind, Jest. These technologies are expected, and their absence would rule you out for most job ads. Their presence, however, says almost nothing. It does not distinguish someone who followed a tutorial from someone who has maintained, for three years, the interface of a product used every day by thousands of people. What makes the difference for a front-end lead are specific topics, described in the experience section. This article reviews them and shows how to write them.
Why "React, Redux, Next.js" is not enough
A lead hiring a front-end developer reads the skills section in a few seconds: they check that the ad’s stack is there, then move on to the experience. That is where they look for the answer to their real question: can this candidate build an interface that stays fast, accessible, tested and maintainable as the product grows?
A list of libraries does not answer that question, for three reasons.
- Libraries change quickly. State management, routing, styling and build tools have gone through several generations in a few years. A lead is more interested in your understanding of the problems (shared state, server-side rendering, code splitting) than in the tool of the moment.
- They are the same for every candidate. The dominant frameworks are taught everywhere, from schools to bootcamps. Listing them puts you level with the competition, not above it.
- They say nothing about scale. A five-screen application and a two-hundred-screen application shared by several teams use the same libraries, but require very different skills.
The skills section should therefore remain short and precise, as explained in our article on presenting your tech stack. The essentials are played out elsewhere.
The topics that signal an experienced front-end developer
Five topics come up in conversations with front-end leads and in experienced-level job ads. Each deserves at least one bullet in your experience section, if you have really practised it.
- Performance. Loading time, responsiveness to interactions, visual stability of the page. Google groups these measurements into the Core Web Vitals 🔗 (LCP, INP, CLS), which many teams track.
- Accessibility. Keyboard navigation, compatibility with screen readers, contrast, focus management. In France, the RGAA 🔗 serves as the reference framework for public digital services and many companies, building on the W3C’s WCAG 🔗.
- State and data management. Where state lives, how it is shared, how server data is cached and synchronised. This is often where the most costly bugs are born.
- The design system. A library of reusable components, documented, shared between teams, built with designers. It is a strong marker of a profile who thinks beyond their own screen.
- Testing and quality. Component unit tests, user journey tests, strict typing, code review.
TypeScript 🔗 deserves a separate mention. Writing it in your skills is expected; what distinguishes an experienced developer is how they use it: strict mode enabled, types shared with the API, types generated from a schema, gradual migration of a JavaScript codebase.
Writing performance and accessibility into an experience
These two topics are the easiest to make concrete, because they can be measured.
Performance
A good performance bullet gives the metric, the value before and after, the page or journey concerned, and the technique used.
Before: "Optimised the performance of the React application."
After: "Reduced the catalogue page’s LCP from 3.8 s to 1.7 s (field data): route-based code splitting, lazy-loaded images, server rendering with Next.js for landing pages."
The lead will ask you how you measured: prepare the answer (measurement tool, sample, period). It is also a chance to show that you distinguish lab measurements from real-user measurements.
Accessibility
An accessibility bullet cites the framework, the scope and the result.
Before: "Took accessibility into account."
After: "Ran an RGAA audit of the sign-up and payment journeys with the design team, then fixed the blocking non-conformities (keyboard focus, form labels, error announcements for screen readers); tested with NVDA and VoiceOver."
If you do not have a measured conformance rate, do not invent one: describing the fixes made and the testing tools is enough to prove real practice. The front-end developer resume template shows a bullet of this kind, alongside a design system and user journey tests.
Testing and code quality
Testing is the topic most often forgotten on front-end resumes, even though leads look at it closely. Three levels to distinguish:
- component tests, with Testing Library and Vitest or Jest: they check that a component behaves as the user expects;
- user journey (end-to-end) tests, with Playwright or Cypress: they check that a user can complete a sign-up or a payment;
- visual or regression tests, rarer, often plugged into the design system.
Write what you set up, on what scope, and what it changed.
Before: "Unit tests with Jest."
After: "Set up 30 Playwright journeys on critical features (login, ordering, payment), run on every pull request; regressions caught in acceptance testing became rare."
Other quality signals also have their place, in one line: strict typing, shared lint rules, systematic code review, component documentation in Storybook. These are team practices that show your maturity.
Front-end or full-stack: positioning yourself
Many front-end developers also work on the server side: API routes in Next.js, serverless functions, third-party service integrations. Should you then present yourself as full-stack?
The answer depends on what you want to do and what you can defend.
- If your core job is the interface, present yourself as a front-end developer, and mention your server-side forays in the experience section. Teams looking for an interface specialist prefer a clearly positioned profile.
- If you regularly design APIs, model databases and handle deployment, the full-stack title is justified. In that case, show at least one module you carried from the database to the screen, as the full-stack developer resume template does.
- If you are unsure, adapt the title to the ad without changing the content: "front-end developer with Node.js experience" is an honest phrase that opens both doors.
In every case, the title must match what the experience shows. A resume that announces full-stack but only talks about React components will be read as a front-end resume, and a lead will notice in the interview.
For these bullets to be read, they must also be extracted correctly by recruitment software, which struggles with column layouts and skills shown as icons. Our article on scale-ups’ ATS details these pitfalls. The TechCV editor produces a plain one-column page where each technology remains readable text. You can update your resume starting from the front-end template.
Frequently asked questions
Should I list Vue or Angular as well as React?
Only if you used them in a real project you can talk about. Significant experience with two frameworks is an asset, especially for IT services companies and agencies; a mention without context adds noise to your section.
How do I show my level without performance figures?
Describe the problems solved and the choices made: a state management architecture reworked, a design system built, a migration to TypeScript carried out. These are as telling as a figure, provided they are precise.
Is a portfolio essential for a front-end developer?
It is strongly recommended, because your work is visible. Two or three well-presented pieces of work, with a link to the code or a demo, are better than a spectacular but empty portfolio site. Our article on the GitHub link on a resume gives ideas for preparing it.
Should I mention build tools?
In one line, yes, especially if you led a migration (from one build tool to another, for example) or optimised a build time. Without particular context, they do not set you apart.