What I read on a frontend CV before I book a screen
The order I read a frontend CV in, the bullets that get you a screen, and the layout mistakes that quietly cost you.
I do not read a frontend CV top to bottom. I scan for proof that you ship UI people use, then I decide whether a screen is worth both our time. Here is what I actually read, in the order I read it.
I am Harry Ashton. I built CodePrepped so engineers stop guessing what hiring managers look for. This is the step before what I mark in a 45-minute screen and the same first impression I describe in your developer profile is making recruiters and AI guess. If the CV does not get you the screen, nothing else on this blog matters yet.
Photo: Kampus Production / Pexels.
The top third decides whether I keep reading
The first thing I look at is the line under your name. “Frontend engineer, React and TypeScript, design systems and accessibility” tells me where you fit. “Passionate full-stack developer who loves learning” tells me nothing I can act on.
Then I look at your most recent role. Not the company logo, the bullets. If the top third of the page does not say what you built, for whom, and with what, I start skimming instead of reading.
Bullets that describe a shipped thing, not a duty
A duty bullet says “Responsible for frontend development.” A shipped bullet says “Rebuilt the checkout form in React with inline validation and keyboard support; replaced three legacy jQuery pages.” The second one gives me something to ask about in the screen.
The pattern I want is simple: what you built, the constraint you worked under, and what changed for users or the team. You do not need a number on every line. If you have a real one you can defend, use it. If you do not, describe the change honestly. I will ask about any figure you write, and a number you cannot explain hurts more than no number at all.
The stack line is a filter, not a trophy shelf
I read the skills section to check fit, not to count logos. Twenty-five technologies in a comma list makes me wonder which ones you could pair on today. Eight you have used in production, grouped sensibly, reads as honest.
Something like “React, TypeScript, Next.js, Tailwind, Testing Library, Playwright, Storybook, WCAG” is plenty. If a job ad names a tool you have genuinely used, make sure the exact word appears somewhere. Recruiters and screening tools both search for the words in the ad, and I would rather you got through on a true match than lost out on a synonym.
Frontend signals I scan for on purpose
Because I hire for UI work, there are a few things I look for by name:
- Accessibility tied to something real, like “keyboard and screen-reader support for the booking flow”, not just the word “a11y”.
- Performance tied to a page or a metric you actually watched, not “optimised performance”.
- Design collaboration: working from Figma, shaping a component library, pushing back on a pattern that would not work on mobile.
- Testing that matches the UI: component tests, end-to-end tests on the critical path, visual checks if you used them.
- Ownership: a feature you took from ticket to production and then maintained.
One of these, written clearly, is worth more than all of them named in a buzzword line.
Links I actually click
If you include a GitHub, portfolio, or live project link, I will probably click one. Make it the one that helps you. A pinned repo with a clear README and a working demo beats a profile full of forked tutorials. I wrote up what I check in the 60-second GitHub pass, and it is the same instinct I bring to a take-home: open it, see it run, read the decisions.
A broken link is worse than no link. Check every one before you send the CV, especially old Netlify or Heroku demos that may have gone quiet.
Length, layout, and the things that quietly cost you
Two pages is fine for a senior engineer. One page is fine for most people. What matters more is that it reads cleanly as plain text, because many applications get pasted into or parsed by systems that strip your layout.
Things that quietly cost you:
- two-column templates where the order of your text gets scrambled when parsed,
- skills shown as star ratings or progress bars, which say nothing and often vanish as text,
- key details only inside images or icons,
- dates that do not line up, with no word about the gap,
- a summary written for every job at once.
A simple single-column layout with real headings is boring. Boring is good here.
Tailoring without rewriting your life
You do not need a new CV for every application. You need a base CV and ten minutes of tailoring. Swap the top line to match the role. Move the two most relevant bullets to the top of your latest job. Make sure the tools the ad cares about, and you have actually used, appear in plain words.
CodePrepped’s job tracker and shortlist scorecard are built for that loop: one place to keep the role, the tailored version you sent, and what you need to prep before the call.
What makes me book the screen
I book the screen when I can picture the first question I would ask you. “Tell me about the checkout rebuild” or “how did you test the design system?” If your CV hands me that question, you have done the job.
I pass when every bullet is a duty, the stack line is a wall of logos, and none of the links show me anything running. That is not a judgement on your ability. It is a judgement on whether the page gave me enough to go on.
Should I include a personal summary?
Only if it is one or two lines that say what you do and what you want next. If it could sit on anyone’s CV, cut it and let your latest role do the talking.
Do I need numbers on every bullet?
No. Use a number when it is real and you can explain how you know it. Otherwise describe the change in plain words. Invented metrics come apart in the first follow-up question.
Should I use an AI tool to write my CV?
It can help you tighten wording. Check every line afterwards, because it will happily add skills or results you never had, and I will ask about them. Your CV should sound like the person who turns up to the screen.
What about side projects if my day job is not frontend?
Lead with them. One finished project with a live demo, a README, and a sentence on what you would do next can carry a career switch. Put it near the top, not under “Interests”.
