The Frontend Engineering Resume

Frontend engineering has a resume problem that no other specialism has: the output is visible, so people describe what it looked like instead of what it took. A bullet about a redesign reads as a project you were present for rather than a system you built.

The underlying difficulty is that the hard parts of frontend work are invisible from the outside — state, performance, accessibility, and the accumulated constraints of real devices and real browsers. Those are the parts a technical reviewer can evaluate, and they are usually missing from the page.

The four things a reviewer is looking for

State, and how you contained it. Complexity in a frontend is almost always complexity in state: what is server data and what is local, what is cached and for how long, what happens to a form mid-submission, how two components that shouldn’t know about each other stay consistent. An engineer who can describe a state boundary they chose is demonstrating design judgement.

Performance, with a mechanism. Not “optimised performance” — the actual cause. A bundle that grew because a date library was imported wholesale, a list that re-rendered on every keystroke, an image pipeline with no size negotiation, a font that blocked paint. Naming the cause is what separates someone who has profiled a page from someone who has read about profiling.

Accessibility, if you know it. This is the most under-supplied real skill in frontend engineering and it is genuinely checkable in an interview. Keyboard navigation, focus management in a modal, an accessible name on a control that isn’t a button, a live region that announces once rather than on every update. One specific bullet here distinguishes you from most of the pile.

Whether you have worked with a design function. Frontend engineers sit on a boundary, and the reviewer wants to know whether you can hold a conversation with a designer about a trade-off rather than either implementing pixel-for-pixel or ignoring the spec. Evidence: a design system, a component library, a negotiation over an interaction that would have been slow.

The framework list problem, in its frontend form

Every frontend resume lists React, and roughly a third list React, Vue, and Angular. As the tech stack list problem argues, that combination reads as three names rather than three skills — and in this field specifically, the framework is the least differentiating thing you can say. Everyone applying has it.

What differentiates: the layer underneath and the layer above.

Underneath — the browser. Event loop and task scheduling, layout and paint, the cache headers your assets go out with, how a service worker behaves on a bad connection, why a scroll janks. Frontend engineers who understand the platform rather than the abstraction over it are much rarer than the resumes suggest.

Above — the architecture. Routing and data-loading strategy, server-rendered versus client-rendered and why you chose it, module boundaries in a large application, how many teams share the codebase and how you kept them from colliding.

Framework roster: Developed responsive web applications using React, Redux, TypeScript, and Tailwind CSS.

Better: Split the checkout flow out of the main bundle after it turned out to be loading the payment SDK on every page view — route-level code splitting plus a deferred SDK load, which took the initial JavaScript payload for the landing page down by most of its size.

Both are illustrations. The second one names one technology and describes a diagnosis, a decision, and a change of state.

Figures that hold up

Frontend work has unusually good measurements available, because the browser exposes them and the tooling records them.

Defensible and specific: bundle sizes before and after, in kilobytes. Core Web Vitals from real-user monitoring, if your team collected it — largest contentful paint, cumulative layout shift, interaction latency — cited as the metric they are rather than a general “performance” claim. Lighthouse scores, with the caveat that they are a lab measurement and reviewers who know that will note the difference. Render counts, if you were fixing a re-render problem. Test suite runtime. Build time.

Weaker: engagement or conversion changes attributed to your frontend work. These are usually owned by another team and measured by an experiment you did not design, and the honest constructions for that situation are in when the numbers belong to another team.

Avoid: “improved page speed” with no metric named, and any performance claim expressed as a bare multiplier. The defensibility question applies exactly as it does everywhere else — as in writing engineering bullets that say something, could you explain the measurement in two sentences?

The bullet shapes that work

The migration. Framework major-version upgrades, a build-tool replacement, a rewrite of a rendering strategy. These are the archetypal hard frontend project because they touch everything and cannot break anything. Describe the increment: which routes moved first, how both stacks ran together, what the rollback was. The general treatment is when the work was keeping a legacy system alive.

The design system or component library. Its consumers are other engineers, which makes it a platform, and the interesting content is adoption and deprecation rather than the components themselves — how many teams use it, how you shipped a breaking change, whether the old patterns actually went away.

The thing you made testable. Frontend testing is genuinely hard and most codebases do it badly. An engineer who has made a flaky end-to-end suite reliable, or replaced one with something faster and more useful, has done work every team wants and nobody advertises.

The bug that was in the platform, not the code. A rendering difference between browsers, a mobile keyboard behaviour, an iOS scroll quirk, a memory leak in a long-lived tab. These are the war stories that establish depth in one clause.

The accessibility remediation. An audit and what you changed, in specifics. Say whether it was against a standard, and don’t claim full conformance unless it was independently assessed — an overclaim here is both checkable and unwise.

The portfolio question

Frontend is the one specialism where a deployed link genuinely helps, because the artefact is directly viewable in a way a backend service never is.

Two cautions. First, a portfolio of visual work invites judgement on visual design, which may not be your skill and is usually not the job — if you are applying as an engineer, the link should lead somewhere that shows engineering: a component library, a tool, a write-up with a performance profile in it. Second, the link is now a live artefact being evaluated, so it has to load quickly, work on a phone, and be navigable by keyboard. A slow personal site attached to a bullet about performance work is a self-inflicted wound.

What a link does and doesn’t establish is covered in what a link to your code actually proves; what to put on a site of your own is in a personal site that earns the link.

Countering the “just UI” discount

Some reviewers — including some engineers who should know better — read frontend work as less technical by default. You cannot argue with that on a resume, but you can make it untenable.

The move is to put one bullet on the page whose technical content is unmistakable regardless of the reader’s prejudice: a concurrency problem, a caching strategy, a measured performance investigation, a piece of tooling you wrote. It does not need to be your most important work. It needs to be the bullet that makes the discount impossible to apply.

The check

Read your frontend bullets and ask whether any of them could only have been written by someone who debugged a browser.

If not, the missing material is almost certainly there in your memory — the render loop you profiled, the layout shift you traced to a late-loading advert slot, the state bug that only appeared on a slow connection. One of those, written specifically, changes how the whole page reads.