Frontend developers
Frontend developers build the part of a product people actually touch. The work runs from component architecture and state management through to accessibility, performance and the browser behaviour nobody sees until it breaks. This guide explains what the role covers, when a team genuinely needs one, and how to tell a strong candidate from a plausible one.
What does a frontend developer do?
A frontend developer builds the interface layer of a web or mobile application — the screens, interactions and data-fetching that run in the user’s browser or device. The work covers translating design into working components, managing application state, handling loading and error conditions, meeting accessibility requirements, and keeping the interface fast on real networks and real hardware. It is a specialism in its own right rather than a lighter form of backend work.
The role sits between two disciplines that pull in different directions. Design supplies intent — layout, hierarchy, motion, tone — and the frontend developer has to realise it in a medium that varies by viewport, input method, font availability, connection quality and assistive technology. Backend supplies data, and the frontend developer decides when to fetch it, what to show while it is missing, and what to do when it never arrives.
Most of the difficulty is in states rather than screens. A single view typically has an empty state, a loading state, a partial state, an error state, an offline state and a success state, and a design file usually shows one of them. Judging which states matter and building them without turning the component into a decision tree is a large part of what separates experienced frontend engineers from people who can assemble a page.
The scope has widened considerably. Server-side rendering, streaming, edge execution and hydration mean a frontend developer now makes decisions that determine server cost and first-paint behaviour, not only client-side polish. Someone whose experience stops at the browser will struggle in a modern rendering architecture.
When teams need this capability
Frontend work is often absorbed by generalists until a specific pressure makes that expensive. These are the situations where a dedicated frontend developer usually starts to pay for itself.
The interface has outgrown its structure
Components have been copied rather than composed, state is threaded through props several levels deep, and a change in one screen breaks another. This is the most common trigger and the least visible from outside the codebase — velocity drops without any single feature looking difficult.
Accessibility has become a requirement, not an aspiration
A procurement questionnaire, a public-sector tender or a legal review turns WCAG conformance into a delivery item. Retrofitting accessibility into components built without it is substantially more work than building it in, and it needs someone who knows the difference between passing an automated scan and being usable with a screen reader.
Performance is measurably costing conversion
Core Web Vitals are failing in the field rather than in the lab, and the causes are distributed across bundle size, image handling, render-blocking resources and layout instability. Diagnosing that requires reading real user monitoring data, not running a synthetic audit once.
The team is migrating rendering strategy
Moving from a client-rendered application to server rendering, static generation or a hybrid changes data fetching, authentication, caching and error handling all at once. Teams frequently underestimate this because the visible output is unchanged.
Design and engineering have drifted apart
The design system exists in a design tool and separately, differently, in code. Someone has to own the translation layer — tokens, primitives, documented components — or every new screen re-litigates spacing and colour decisions that were supposedly settled.
Backend engineers are doing frontend work reluctantly
Capable engineers producing interfaces they are not equipped to judge. The output usually works and usually fails on accessibility, responsive behaviour and interaction detail — and the engineers themselves are the first to say so.
Core capabilities
Component architecture
Deciding what becomes a component, where the boundaries sit, and which props are worth exposing. The failure mode in both directions is expensive: too granular and every change touches twenty files, too coarse and each component grows a configuration flag per use case.
State management
Distinguishing server state, client state, form state, URL state and ephemeral UI state, and keeping each where it belongs. A large share of frontend complexity comes from server data being copied into client state and then drifting out of sync with the source.
Rendering strategy
Choosing between client rendering, server rendering, static generation, incremental regeneration and streaming per route rather than per application, and understanding the consequences for caching, authentication, personalisation and cost.
Accessibility
Semantic markup, keyboard operability, focus management, accessible names, colour contrast, motion preferences and correct use of ARIA — including knowing that the first rule of ARIA is to use a native element instead where one exists.
Performance
Bundle composition and code splitting, image format and sizing, font loading strategy, avoiding layout shift, and understanding what actually moves Largest Contentful Paint and Interaction to Next Paint as opposed to what merely looks like optimisation.
Responsive and adaptive layout
Building interfaces that work across viewport sizes, input methods, text scaling and container contexts, rather than at three fixed breakpoints that match the design file and nothing else.
Browser behaviour
Understanding the event loop, rendering pipeline, layout and paint, caching, storage, CORS and the specific ways behaviour differs across engines. This is the knowledge that turns an intermittent bug into a diagnosis rather than a workaround.
Testing
Component tests that assert behaviour rather than implementation, end-to-end coverage of the paths that matter commercially, visual regression where appropriate, and the judgement to know which of the three a given risk calls for.
Design collaboration
Reading a design critically — identifying the states it omits, the edge cases it assumes away and the constraints it does not know about — and feeding that back before implementation rather than during it.
Interface security
Preventing cross-site scripting through correct escaping and careful use of raw HTML injection, handling tokens without exposing them to script, and understanding that client-side validation is a usability feature and never a control.
Technology ecosystem
Common technologies in frontend engineering are listed below. This describes the landscape of the discipline as it is practised, not a claim about any particular engineer’s toolkit — and a strong frontend developer is generally better assessed on the depth of their reasoning about rendering, state and the browser than on the specific framework named in their most recent role.
Languages
- JavaScript
- TypeScript
- HTML
- CSS
Frameworks and libraries
- React
- Vue
- Angular
- Svelte
- Solid
Application frameworks
- Next.js
- Nuxt
- Remix
- Astro
- SvelteKit
Styling
- Tailwind CSS
- CSS Modules
- Sass
- CSS-in-JS
- Design tokens
State and data
- TanStack Query
- Redux Toolkit
- Zustand
- Apollo Client
- tRPC
Testing
- Vitest
- Jest
- Testing Library
- Playwright
- Cypress
Build and tooling
- Vite
- Turbopack
- webpack
- ESLint
- Storybook
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
Frontend candidates are unusually easy to assess badly. Portfolios show finished surfaces and say nothing about the decisions underneath, and framework familiarity is the easiest thing to test and among the least predictive. These are the areas worth probing instead.
Component architecture judgement
Ask how they decide what becomes a component and when they would deliberately duplicate code rather than abstract it. Premature abstraction is at least as damaging as duplication in interface code, and engineers who have maintained a component library for a few years tend to have views on this that engineers who have only consumed one do not.
- Can describe a component they made more configurable and later regretted
- Distinguishes presentational and container concerns without treating it as dogma
- Talks about the API a component exposes, not only what it renders
Accessibility depth
Automated tooling catches roughly a third of real accessibility issues, so an engineer whose entire approach is running a scanner has a gap they may not know about. Look for someone who has actually operated an interface by keyboard and with a screen reader.
- Reaches for native elements before ARIA attributes
- Can explain focus management in a modal or a route change
- Knows contrast requirements without looking them up, and applies them to interactive states
- Treats motion preferences and text scaling as requirements rather than extras
Rendering and data-fetching tradeoffs
Ask when they would choose server rendering over client rendering, and what it costs. A strong answer covers caching, personalisation, authentication and infrastructure spend — not only SEO, which is the answer people give when they have read about the topic rather than lived with it.
- Chooses strategy per route rather than per application
- Can articulate what hydration actually costs
- Considers the failure mode when the data source is slow or unavailable
Performance under real conditions
Distinguish candidates who optimise against a lab score from those who work from field data. The former will make a synthetic number improve; the latter will make the product faster for the people using it, which is not always the same change.
- References real user monitoring, not only synthetic audits
- Understands the difference between load performance and interaction responsiveness
- Can name a specific cause of layout instability and how they fixed it
Debugging capability
This is the most reliable differentiator available and the most commonly skipped. Ask for a specific, difficult, intermittent bug and listen for method: how they narrowed it, what they ruled out, how they confirmed the fix addressed the cause rather than the symptom.
- Describes forming and testing a hypothesis rather than changing things
- Comfortable in browser developer tools beyond the console
- Distinguishes the root cause from the trigger
Testing judgement
The question is not whether they write tests but which tests they consider worth writing. Look for someone who can articulate why a particular test would have caught a particular class of failure, and who does not test implementation details that make refactoring expensive.
- Tests behaviour a user could observe
- Has an opinion on where end-to-end coverage stops paying for itself
- Treats a flaky test as a defect rather than a nuisance to retry
Working with design
Strong frontend engineers push back on designs constructively and early. Ask what they do when a design omits an error state or specifies something the platform handles badly — the answer reveals whether they see themselves as an implementer or a collaborator.
- Identifies missing states before starting implementation
- Can explain a platform constraint without being dismissive of the intent
- Has worked with a design system on both sides of the boundary
Interview questions worth asking
Questions that reveal reasoning rather than recall. These are offered as guidance for your own interview process — you assess every candidate yourself, and nobody joins your team without that assessment.
Walk me through a component you designed that turned out to be wrong. What did you change, and what would you do differently now?
What a strong answer shows
Self-correction and real maintenance experience. Engineers who have only built new features rarely have this story; engineers who have maintained an interface for years always do. Listen for whether the lesson generalised.
A page scores well in a lab audit but users report it feels slow. How do you investigate?
What a strong answer shows
Whether they distinguish load metrics from interaction responsiveness, and whether they reach for field data. Strong answers consider long tasks, main-thread blocking, and the gap between a fast first paint and a page that responds to input.
How do you decide between server rendering, static generation and client rendering for a given route?
What a strong answer shows
Architectural judgement rather than framework defaults. The reasoning should cover data freshness, personalisation, authentication, caching and cost — and should treat the choice as per-route.
What happens when a keyboard user tabs through the interface you built most recently?
What a strong answer shows
Whether accessibility is practised or asserted. A candidate who has genuinely done this will describe focus order, visible focus indicators and focus management on navigation. One who has not will answer in generalities.
Describe how you manage server data in a client application. Where do you keep it and how do you know it is still correct?
What a strong answer shows
Understanding of the most common source of frontend complexity. Strong answers treat server state as a cache with invalidation rules rather than as application state that happens to have come from a network call.
Tell me about an intermittent bug that only reproduced for some users. How did you find it?
What a strong answer shows
Debugging method under genuine uncertainty. Look for narrowing, instrumentation and hypothesis-testing — and for the candidate distinguishing what triggered the bug from what caused it.
You are handed a design with no empty state, no error state and no loading state. What do you do?
What a strong answer shows
Whether they collaborate or comply. The strongest answers involve raising it before implementation and proposing specific states, rather than either inventing them silently or building only what was drawn.
What is on your team’s frontend codebase that you would remove if you could, and why is it still there?
What a strong answer shows
Technical judgement plus organisational realism. Engineers who can only describe what they would add have usually not carried the cost of what they built.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- A product team is modernising a mature frontend while continuing to ship features. The existing interface works, but component boundaries have blurred, accessibility gaps have surfaced during a procurement review, and the team cannot take on the migration without stopping roadmap delivery.
- Approach
- Additional frontend capacity works inside the team’s existing engineering workflow — their component standards, their review process, their release cadence and their architectural direction. The internal engineers keep ownership of product decisions and technical direction; the additional capacity absorbs migration work alongside them rather than running a parallel track.
- What this adds to the team
- The team gains delivery capacity without transferring product ownership or architectural authority. Decisions about what the interface should become stay with the people who own the product.
Related disciplines
Frequently asked questions
- What is the difference between a frontend developer and a full-stack developer?
- A frontend developer specialises in the interface layer and generally has more depth in accessibility, performance, browser behaviour and component architecture. A full-stack developer works across interface and server, usually with broader coverage and less depth at either end. Teams building an interface-heavy product often benefit more from frontend depth; teams shipping features end to end across a small surface often benefit more from full-stack breadth.
- Do frontend developers need to know design?
- They do not need to produce design, but they need to read it critically — recognising missing states, understanding hierarchy and spacing intent, and knowing when a specified interaction will behave badly on a real device. Frontend engineers who can hold a substantive conversation with a designer produce noticeably better interfaces than those who implement exactly what they are given.
- How important is framework experience when hiring?
- Less than it appears. An engineer with strong fundamentals in state, rendering, accessibility and browser behaviour typically becomes productive in an unfamiliar framework within weeks, because the underlying concepts transfer. Framework-specific knowledge is the easiest thing to test and among the least predictive of long-term contribution — though it matters more for a short engagement than a long one.
- What seniority does a team need for frontend work?
- It depends on what is unresolved. Work with settled architecture and a documented design system can be delivered well at mid level. Work that involves establishing component architecture, choosing a rendering strategy or leading a migration needs someone who has carried the consequences of those decisions before, because the cost of getting them wrong lands months later.
- Is accessibility work a separate specialism?
- Some of it is — complex ARIA patterns and assistive-technology testing benefit from a specialist. But the majority of accessibility defects come from ordinary decisions made without accessibility in mind: non-semantic markup, unmanaged focus, insufficient contrast, keyboard traps. Those are the daily work of a competent frontend developer, not a separate discipline, and treating accessibility as somebody else’s job is what creates the backlog in the first place.
- When does a team need more than one frontend developer?
- Usually when the interface has more than one independent surface under active development, or when a migration needs to proceed alongside feature delivery. A single frontend developer supporting several product teams tends to become a bottleneck and a single point of knowledge, which is a risk that grows quietly.
- How do frontend developers work with an existing engineering team?
- In a staff augmentation arrangement they work within your engineering workflow — your standards, your review process, your architecture and your sprint priorities. You direct the work day to day. Talent.ID handles the employment relationship, payroll and employee benefits.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.