How to get hired as a frontend developer in 2026-27

What "frontend developer" means on a 2026 posting, and which ladder you are on

Six titles describe this job and they are not interchangeable in pay or in interview format. 'Frontend Developer' and 'Web Developer' skew toward implementing designs someone else owns, often inside a CMS or an existing system, and are frequently placed on a lower-paying job family. 'Frontend Engineer' and 'UI Engineer' sit on the software engineering ladder, with the same levels and bands as backend engineers at the same company, and usually a harder loop. 'Design Engineer' is newer and real: you own the visual and interaction layer and the system behind it, working directly with design, often in a design-systems or product-prototyping team. 'Full Stack' postings are often frontend jobs with an API attached, so read the responsibilities rather than the title. Work out which one you are actually applying to, because the job family on the requisition is the single biggest lever on your offer and it is close to impossible to change after you accept.

The fastest read is the framework line. A posting that names React and TypeScript in the first two bullets is a mainstream product job and your preparation is standard. Angular in the first bullet means enterprise: finance, insurance, healthcare, government, large internal tooling, long-lived applications, and a team that cares more about testing and upgrade paths than about novelty. Vue or Nuxt usually means a mid-market product company or an agency with a stable stack. Svelte or Astro usually means a small team or a content-heavy site, and a short interview process. A posting that names no framework at all, only 'HTML, CSS, JavaScript, WordPress', is a different job again: cheaper, faster-moving, closer to marketing, and the segment most exposed to site builders and generation tools.

The second read is the ownership verbs. Implement, slice, convert, assist, maintain means they will supervise you and your job in the loop is to show you can be trusted with a screen. Own, define, drive, establish, lead means they expect you to make calls about component APIs, state architecture and what the team stops doing. Partner with design, contribute to the design system, define tokens means the design-engineer flavour, and your portfolio matters more than your algorithms.

The third read is what sits behind the UI, because it determines what you spend your week on. GraphQL, a BFF layer, or REST endpoints owned by another team means integration and caching work. A headless CMS (Contentful, Sanity, Storyblok) means content modelling and editor experience. Storybook, tokens, visual regression and a published package means design systems. Core Web Vitals, SEO and conversion means commerce or media, where your work is measured in revenue and you will be asked for numbers. WCAG, Section 508 or VPAT means public sector or a vendor selling into it, where accessibility is a contractual deliverable rather than a nice-to-have.

Four employer types hire frontend developers and they are four different jobs. Product companies give you depth, a real codebase, on-call in some cases, and the slowest hiring process. Agencies and consultancies give you breadth, many projects, fast hiring and shallow ownership; excellent for a first job and a portfolio, limiting after three years. Enterprise in-house (banks, insurers, hospital systems, logistics, government contractors) gives you stability, Angular or an older React codebase, and accessibility and browser-support requirements stricter than anything a startup imposes. Government, education and health systems have the most durable accessibility budget in the market right now and typically draw fewer applicants per posting than recognisable product brands.

• Entry and early career signals: '0-2 years', 'under guidance of senior engineers', 'convert designs to responsive pages', 'maintain existing components', a degree listed as required, no mention of architecture.
• Mid-level signals: '3-6 years', 'own features end to end', 'review code', 'contribute to our design system', a stated testing expectation, performance or accessibility named as a responsibility.
• Senior and above signals: 'define frontend architecture', 'set standards across teams', 'mentor', 'make build-versus-buy decisions', 'partner with design leadership', and a loop that includes a system design round.
• Design-engineer signals: Figma named alongside the stack, tokens, Storybook, motion and interaction detail, a prototyping expectation, a portfolio explicitly requested.
• Lower-ladder signals worth noticing before you apply: the title 'Web Developer' or 'Web Designer', WordPress or a page builder as the primary tool, 'marketing website' as the product, and a stated range that sits well under software engineering ranges in the same city.
• Red flag on a senior posting: twenty-five technologies listed with no depth anywhere, which usually means one person is expected to be the entire engineering function.

The frameworks and fundamentals that still get interviews

React is still the default and is named on more frontend postings than any other framework, with Next.js the meta-framework most often paired with it. If you are choosing one thing to learn deeply for maximum optionality in 2026-27, it is React with TypeScript. Learn it as it is now, not as the 2021 tutorials teach it: hooks rather than classes, Server Components and the App Router model if your target employers use Next.js, the newer form and action patterns, and the React Compiler reducing the hand-written memoisation that interview advice used to obsess over. Knowing why you would still reach for useMemo, and why in most code you no longer need to, is a better answer than reciting rules.

Do not conclude that React is the only employable choice. Angular is the quiet giant of enterprise frontend, the postings are real, and the applicant pool per posting is thinner because fashion moved away from it and the applications did not. If you learn it, learn the current model (signals, standalone components, the built-in control-flow syntax, the modern router and forms) rather than the NgModule-heavy patterns most tutorials still show, because that gap is exactly what interviewers probe. Vue with Nuxt holds a solid mid-market and is strong in Europe and Asia. Svelte, Solid and Astro are genuinely good and genuinely thin on postings; treat them as a second framework, not a first bet. Pick your framework by searching live listings in the market you can actually work in, counting how many name each one, rather than from online discourse.

TypeScript is table stakes above entry level. A candidate who writes only JavaScript is screened out of a large share of mid-level work, and you will be asked to read types far more often than to write clever ones. Know generics, unions and discriminated unions, narrowing, the practical difference between a type and an interface, how to type a component's props including children and polymorphic cases, and what unknown is for. You do not need type-level puzzles. You do need to never write any in an interview without saying why.

The fundamentals outlast the framework and are what separates people in the technical rounds. The event loop, microtasks, and the ordering of promises against timers. Closures, and why a stale value appears in a callback. Prototypes and this binding. Event bubbling, capture and delegation. The DOM as an API: querySelector, dataset, classList, MutationObserver, IntersectionObserver, ResizeObserver, AbortController. Native forms, constraint validation, and why a native submit beats a click handler. HTTP caching headers, CORS as a browser behaviour rather than an error message, cookies versus tokens and where each is safe to store, and what a Content Security Policy does to your inline script. Every one of these appears either as a question or as the cause of a bug you will be asked to find. MDN and web.dev are the references to learn these from; BigFrontEnd.dev and Frontend Mentor are reasonable places to drill them under a timer.

Modern CSS has quietly removed whole categories of JavaScript, and interviewers notice when a candidate still solves them the old way. Container queries let a component respond to its own container rather than the viewport, which is what you actually want in a design system. :has() gives parent and sibling conditions without class-toggling effects. Cascade layers make a third-party stylesheet tractable. Subgrid aligns across cards without magic numbers. clamp() and fluid type remove most breakpoints. dvh fixes the mobile viewport bug people still ship JavaScript for. prefers-reduced-motion is a one-line respect for a real accessibility need. View transitions animate state and route changes natively, though support differs between same-document and cross-document use, which is exactly the kind of thing to check on Baseline in MDN or on caniuse rather than in a blog post from 2022. Be able to say when you would still not use a feature.

Know the rendering models well enough to argue about them, because the frontend system design round is largely this. Client-side rendering, server-side rendering, static generation, incremental regeneration, streaming and React Server Components are different answers to where data is fetched, what the user sees first, how much JavaScript ships, and what breaks when the server is slow. The useful interview sentence is not 'we used SSR'. It is 'this page is SEO-critical and content changes hourly, so static with revalidation, and the personalised rail streams in afterwards, which keeps LCP on the static content'.

On tooling, learn the layer rather than memorising brands. Vite is the default dev server and build tool in new work and webpack is what you meet in older codebases, so expect to touch both. Vitest has largely displaced Jest in Vite projects; React Testing Library remains how component tests are written; Playwright has become the default end-to-end tool in new projects, with Cypress still widespread. ESLint moved to flat config, and Biome is a credible single-tool alternative. Storybook is how design systems are documented and reviewed. Tailwind dominates new styling work, CSS Modules remain common, and runtime CSS-in-JS has fallen out of favour in new React code because it fights server rendering (styled-components is in maintenance), so check a styling library's current maintenance status before you build on it. None of this is worth listing as a wall of nouns; it is worth being able to say what you chose and what it cost.

• Learn in this order if you are starting: HTML semantics and forms, CSS layout (flex, grid, container queries) and the cascade, JavaScript fundamentals including async behaviour, the DOM and browser APIs, TypeScript, then one framework deeply, then testing, then performance and accessibility as measurable disciplines.
• If your stack does not match a posting you want, apply anyway at mid-level and above and say the true thing: 'three years of production Vue, I have built two things in React, here is the one that is deployed, and here is what I found genuinely different'. Framework transfer is normal and employers know it. Faking current React experience does not survive a build round.
• Build one thing that is hard for a specific reason rather than five tutorials: an offline-capable app with conflict resolution, a virtualised table over 100,000 rows, a collaborative editor, a fully keyboard-accessible complex widget, an internationalised interface including a right-to-left locale.
• Learn to read a flame chart in the Chrome DevTools performance panel. Record an interaction on your own site, find the longest task, and work out what is in it. This is the highest-leverage debugging skill in the role and almost nobody arrives with it.
• Ask what browsers and what minimum device the product supports. The answer tells you how much of your modern CSS knowledge you will actually be allowed to use, and it is a question that marks you as experienced.

Accessibility and performance: the two kinds of proof that move a hiring decision

These are the two things a frontend candidate can prove with evidence that nobody else in the loop can produce, and they are a common reason a specific candidate is picked over an equally pleasant one. Both are measurable, both are checkable against your own live work, and both are attached to money: accessibility through regulation and procurement, performance through conversion, search and ad revenue.

Start with the regulation, because it explains where the funded jobs are. The Department of Justice's ADA Title II rule sets WCAG 2.1 Level AA as the technical standard for web content and mobile apps of state and local governments. Compliance has been required since 24 April 2026 for public entities serving 50,000 or more people, and is required from 26 April 2027 for smaller entities and special district governments. That means the first wave is now in remediation-and-enforcement territory rather than preparation, and the smaller-entity wave is close enough that counties, school districts, transit agencies and their vendors are hiring and contracting for it now. Section 508 covers federal agencies and their vendors, which is why a VPAT or accessibility conformance report turns up in procurement documents; its standards incorporate WCAG 2.0 Level AA, although agencies commonly procure to 2.1 AA in practice. In the EU, the European Accessibility Act has applied since 28 June 2025 to a list of consumer products and services including e-commerce, banking and e-books, with EN 301 549 as the referenced standard and transitional allowances for certain existing contracts and self-service terminals. US private-sector litigation over inaccessible websites continues independently of all of that. The practical consequence for your search: state and local government, public universities, school districts, health systems, transit agencies, their contractors, and any company selling consumer services into the EU have an accessibility line in the budget right now.

Now the part that matters in an interview, because 'I know accessibility' means nothing and every candidate says it. Concretely, you should be able to do a keyboard-only pass of a page and narrate what is wrong: what is not reachable, where focus goes when a dialog opens and where it returns when it closes, whether focus and page title are handled after a client-side route change, whether a custom control responds to the keys its native equivalent would. Reach for semantic HTML first and ARIA second, and be able to quote the first rule of ARIA back: if a native element does the job, use it. Know that the WAI-ARIA Authoring Practices Guide exists and have implemented at least two of its patterns (combobox, tabs, disclosure, menu, dialog) rather than inventing your own. Run a real screen reader rather than only an automated scan: NVDA is a free download for Windows and pairs with Firefox or Chrome, VoiceOver is built into macOS (Command plus F5) and iOS, and JAWS is what you will meet in enterprise. And say the honest thing about tooling: axe and Lighthouse catch a meaningful subset of issues, mostly contrast, missing accessible names and bad structure, and they cannot tell you whether a flow is usable. WebAIM's annual accessibility report on the top million home pages is the right place to point someone who thinks automated scanning is sufficient.

Four WCAG 2.2 success criteria are worth naming by hand because they catch out teams that learned 2.1: target size of at least 24 by 24 CSS pixels for pointer targets, focus not obscured by sticky headers or cookie banners, an alternative to dragging movements, and accessible authentication that does not demand a cognitive function test such as transcribing a code from memory. Also internalise reflow, which requires content to work at 320 CSS pixels wide without two-dimensional scrolling, and text resizing to 200 percent without loss of content. Both are testable in your browser in ten seconds, and both break the fixed-height, fixed-font interfaces that get generated by default.

Performance is the other half, and the thing to know is what is measured and how. The Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, assessed at the 75th percentile of page loads and reported separately for mobile and desktop. The commonly cited good thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1. INP replaced First Input Delay in March 2024, which matters more than it sounds: the metric moved from the first interaction to every interaction, so a page that passed on the old metric and janks on every filter click now fails. Understand the difference between field data (the Chrome User Experience Report, or your own real-user monitoring) and lab data (Lighthouse, WebPageTest), and never present a Lighthouse score as if it were what users experienced.

The levers worth knowing, roughly in order of payoff: image format, dimensions and priority, including fetchpriority on the LCP image and not lazy-loading anything above the fold; font loading strategy, preload and font-display, where a lot of CLS hides; the amount of JavaScript shipped to the route and the cost of hydrating it; third-party tags, usually the worst offender and usually not in your control, so learn to measure and present their cost to whoever can remove them; long tasks broken up to protect INP; and explicit dimensions or aspect-ratio on anything that loads late. Put a budget in CI so a regression fails a pull request instead of being discovered in a quarterly review.

On credentials: there is no required certificate for either discipline. The IAAP credentials (CPACC, WAS, and CPWA for both) do appear in public-sector and vendor postings and are a reasonable investment if you are aiming at that market deliberately. For performance there is no credential at all, only numbers. In both cases the artefact beats the badge: a one-page write-up of an audit you ran, the findings, what you changed and the re-measurement is worth more in an interview than any course certificate, and you can produce it this month on a site you already have access to.

• The fastest credibility test, and you should run it on your own portfolio before anyone else does: tab through it end to end, zoom text to 200 percent, narrow the window to 320 pixels, open it on a real mid-range phone over a throttled connection, and run PageSpeed Insights (pagespeed.web.dev) to see whether you have field data at all. Fix what you find before you link it.
• How to state accessibility work so it counts: the standard and level (WCAG 2.1 AA), how it was verified (automated scan, manual keyboard pass, which screen reader, third-party audit), the volume of findings, and the outcome. 'Accessibility-minded' is not evidence.
• How to state performance work so it counts: metric, before, after, population and method. 'LCP p75 4.1s to 1.9s in CrUX over six weeks' is checkable. 'Improved performance by 60 percent' is not.
• Learn to read and fill in a VPAT or accessibility conformance report if you are targeting the public sector or a vendor selling into it. Very few candidates can, and it is often the actual deliverable.
• Do not overclaim. If you have never used a screen reader, say you have done keyboard and automated testing and have not yet done screen-reader testing. Interviewers in this area ask one follow-up question and it exposes a bluff immediately.

How frontend hiring actually works, stage by stage

Who screens you first depends on the size of the employer, and it changes what you should optimise. At companies above roughly two hundred people, a technical recruiter reads the resume against the posting's vocabulary and level, and your portfolio may not be opened until later. At smaller companies, agencies and most startups, the first reader is the hiring manager or a founder, and they open your live links before reading a word of your bullets. That asymmetry is why a frontend candidate needs both a keyword-legible resume and two or three deployed things that load fast: you cannot know which door you are walking through.

Before you invest hours in preparation, ask one question in writing, because the answer determines everything: is the coding round data structures and algorithms, or a UI build? These preparations do not transfer. Large employers with a single standardised loop will put a frontend specialist through the same algorithmic screen as everyone else, and strong frontend engineers fail it for want of three weeks of practice. Product companies with a frontend-specific loop will ask you to build an accessible combobox in a browser sandbox, and strong algorithmic candidates fail that because they have never managed focus. Ask the recruiter: how many rounds, what each one is, which editor or sandbox, and whether AI assistance is permitted and in what form. A recruiter who cannot answer will find out, and the question reads as professional rather than demanding.

The build round is the centre of a frontend loop and it is a different exam from a backend coding round. You get 60 to 90 minutes, usually in CodeSandbox, StackBlitz or a prepared repository, with a deliberately small-sounding brief: an autocomplete with keyboard navigation, a data table with sorting and selection, a modal, a star-rating widget, an image carousel, a form with validation, a todo list with a twist. The brief is small because the grading is not about volume. It is about whether you clarify requirements before typing, whether you reach for semantics and native behaviour before building from divs, whether keyboard and focus work, whether you handle loading, empty and error states, whether you debounce and cancel in-flight requests, and whether you leave behind a component API someone else could use. Narrate throughout. Finish something working rather than half of something elegant, then say what you would do next and what you deliberately skipped.

Take-home norms have shifted and you should know the current etiquette. Multi-day unpaid take-homes became harder for employers to defend, partly because an assistant now finishes a typical one quickly, which collapsed their signal. What replaced them: shorter timeboxed exercises, paid trial work in some markets, and most usefully an 'extend this existing application' round where you are dropped into a small unfamiliar repository and asked to add a feature or fix a bug. That round is the most honest simulation of the job and the most common place candidates are surprised, because reading someone else's component tree under time pressure is a skill of its own. If you are given a take-home, ask for the timebox and respect it, ask explicitly whether AI tools are allowed, write a short README saying what you prioritised and what you left out, and do not spend fourteen hours on a four-hour brief, which reads as poor judgment rather than dedication.

The agency and contract path is a legitimate and under-discussed route in, especially for a first or second job. Agencies, digital consultancies and staffing vendors hire frontend developers constantly, often with one or two conversations and a small paid trial, and sometimes within a week. You will build a portfolio faster than anywhere else and you will go a mile wide and an inch deep. Know the contract shapes: W-2 contract through a staffing vendor (taxes withheld, sometimes benefits, usually a fixed term), 1099 or your own entity (you handle taxes and there is no unemployment coverage, so price accordingly), and contract-to-hire (get the conversion terms in writing, including target date and salary band, because a vague conversion promise is worth nothing). Agency work is a strong two years and a weak five.

Expect two to six weeks end to end at a product company, longer in government and large enterprise where a requisition can sit waiting for approval, and days at an agency. The slowest stages are usually the gap before the recruiter screen and the gap after the final round while a committee or a budget holder decides. Keep every process running until an offer is signed.

• Recruiter screen (20 to 30 min). Graded on level match, stack vocabulary, location and work authorisation, compensation expectations, and whether you can describe your last project in two minutes without jargon. Have a one-sentence answer to 'what do you own?'
• Portfolio or work review (sometimes instead of a screen). Graded on whether your live links work, load fast and survive a phone, and whether you can say what was hard about one of them.
• JavaScript and browser fundamentals round (30 to 45 min). Graded on async behaviour, closures, the DOM, event handling, and whether you can implement a small utility (debounce, throttle, an event emitter, a deep clone, a promise pool) and then describe its edge cases.
• UI build round (60 to 90 min, the core stage). Graded on requirement clarification, semantics, keyboard and focus, states, component API, and whether you verify rather than assume. Working beats elegant.
• Frontend system design round (45 to 60 min, mid-level and up). Graded on rendering strategy, data fetching and caching, state placement, component boundaries, pagination or virtualisation at scale, error and offline behaviour, bundle strategy, and what you would measure. Less about boxes and arrows than about trade-offs you state out loud.
• Debug or extend-an-existing-app round (increasingly common). Graded on method: reproduce first, read the component tree, form one hypothesis, use the devtools you claim to use. The round that most rewards real experience.
• Accessibility round (common in enterprise, public sector, and any team that has been audited). Graded on whether your knowledge is procedural rather than vocabulary: here is a component, make it usable by keyboard and screen reader, and tell me which standard you are meeting.
• Code review round (growing). You are given a diff, often of generated code, and asked what is wrong. Graded on what you notice and in what order: correctness and accessibility before naming and formatting.
• Cross-functional round with a designer or PM (frontend-specific, often decisive). Graded on whether you can disagree with a design on usability or feasibility grounds, propose an alternative, and leave the designer feeling helped rather than overruled.
• Hiring manager or behavioural round (45 to 60 min). Graded on ownership, how you handle a late design change or a shipped regression, and whether your stories contain decisions rather than chronology.

Frontend interview questions, and what each one is actually grading

These are the questions in roughly the words they are asked in. Prepare them out loud, to a timer. For the build prompts, actually build each one at least once in a blank sandbox with no assistance, then once more with your usual tooling, because the two modes feel entirely different under observation.

On behavioural prompts, every strong frontend answer has the same shape: the constraint, the decision you made, the alternative you rejected, what it cost, and how you knew it worked. The specific frontend failure mode is answering in chronology ('then the designer sent new files, then we rebuilt the header') with no decision anywhere in it. Two minutes maximum, decision in the first thirty seconds.

On the system design round, do not start drawing. Spend the first five minutes on requirements: who uses this, on what device and connection, how much data, is it SEO-relevant, does it need to work offline, what is the accessibility and browser support floor, how large is the team that will maintain it. A candidate who asks whether the table needs to support 200 rows or 200,000 before choosing virtualisation has already passed most of the round.

Do not bluff a technology you have not run. 'I have not shipped that; here is what I would want to find out before committing to it, and here is the closest thing I have done' is a strong answer in this discipline, where the follow-up questions are concrete and a fabricated opinion collapses in one exchange.

• 'Build an autocomplete or typeahead.' Grading: debouncing, cancelling stale requests with AbortController, keyboard navigation with arrow keys, Enter and Escape, the combobox ARIA pattern or a native alternative, announcing result counts, handling no results and errors, and not losing the user's typing while a request is in flight.
• 'Build an accessible modal or dialog.' Grading: whether you use the native dialog element or know why not, focus moved in on open and restored on close, focus trapped while open, Escape to dismiss, the rest of the page inert, scroll handling, and labelling. This single component separates people who have read about accessibility from people who have done it.
• 'Build a data table with sorting, selection and pagination.' Grading: semantic table markup, sortable column headers with aria-sort, keyboard operation, whether you virtualise and at what row count, how selection state is modelled, and what happens to selection across pages.
• 'Render a list of 100,000 items.' Grading: whether you reach for virtualisation, how you keep scroll position and keyboard focus stable, what you do about variable row heights, and whether you mention that the real fix may be not sending 100,000 items.
• 'Build a streaming chat or assistant output panel.' Grading: how you consume a stream (server-sent events or a ReadableStream), how you avoid layout thrash and scroll-jump on every chunk, cancellation on navigation or a new query, what the UI does at five seconds and at thirty, retry and edit affordances, and whether the streaming region is announced accessibly instead of read out token by token.
• 'Implement debounce, throttle, a simple event emitter, or a promise pool.' Grading: correctness at the edges (leading and trailing calls, cancel, this binding, errors inside the pool) and whether you test one case out loud.
• 'Explain the event loop, and tell me the output order of this snippet.' Grading: microtasks versus macrotasks, where promises and timers sit, and whether you can explain why a long synchronous task blocks paint and therefore hurts INP.
• 'What is a closure, and where has one bitten you?' Grading: not the definition, the real anecdote. A stale value captured in a handler or an interval is the expected answer.
• 'How does React decide what to re-render, and how would you find out why something re-rendered?' Grading: reconciliation, keys, referential identity of props, and whether you name a real tool (the React DevTools profiler) rather than guessing.
• 'Where would you put this piece of state?' Grading: the instinct to colocate, the distinction between server data (cached, revalidated, belongs in a query library) and genuine UI state, and whether you reach for a global store by reflex. A candidate who says 'most of what people put in Redux is cached server data' is answering well.
• 'CSR, SSR, static or streaming for this page, and why?' Grading: whether your reasons are SEO and crawlability, time-to-first-content, data freshness, personalisation and JavaScript cost, rather than a preference for a framework.
• 'This page jumps around while it loads. Why?' Grading: CLS causes named concretely: images without dimensions, late-loading fonts, injected banners and ads, content inserted above the fold, animation of layout-affecting properties.
• 'Our search page feels slow when you click a filter. Diagnose it.' Grading: that you reach for the performance panel and INP rather than guessing, look for long tasks, excessive re-renders and synchronous layout, and ask whether the slowness is in the network or on the main thread.
• 'Make this component accessible.' Grading: semantics first, then names and roles, then keyboard, then focus, then contrast, and whether you say which standard you are satisfying. Bonus for noticing an ARIA attribute doing a job a native element would do better.
• 'Here is a pull request. What is wrong with it?' Grading: order of attention. Correctness and accessibility before formatting. On generated code: div soup, missing keyboard support, a hardcoded string that breaks localisation, a duplicate of a component that already exists in the design system, an unnecessary client-side dependency.
• 'How would you design a component library or design system?' Grading: tokens and theming, the component API surface and what you deliberately do not expose, composition over configuration, versioning and the upgrade path for consumers, documentation in Storybook, visual regression testing, and how you handle the team that needs a one-off exception.
• 'How do you support multiple languages?' Grading: externalised strings, pluralisation and number and date formatting through Intl, right-to-left layout with logical properties, text expansion breaking a fixed-width layout, and locale-aware routing.
• 'How do you test a frontend?' Grading: a sensible pyramid, testing behaviour rather than implementation details, queries by accessible role and name rather than test IDs everywhere, what belongs in end-to-end versus unit tests, and whether you have ever deleted a flaky test rather than fixing it.
• 'Tell me about a time a design was not implementable as drawn.' Grading: whether you proposed an alternative rather than just saying no, and whether the designer would describe you as a good partner.
• 'Tell me about something you shipped that broke.' Grading: ownership without theatre, how you detected it (error monitoring and real-user metrics, or did a user tell you?), how fast you recovered, and the systemic change afterwards.
• 'What are your questions for us?' Ask five: what the first ninety days looks like; how a change reaches production and how long that takes; what the browser and device support floor is; whether accessibility and performance have owners, budgets and measurements or only good intentions; and how design and engineering actually hand off work.

The resume and the portfolio: what gets read and what gets ignored

Begin with how the resume is physically read, because it explains the formatting rules. Applicant tracking systems extract the text layer from your PDF and flatten it into one stream, and a decorative two-column layout can interleave two columns into nonsense. The rule is not 'never use columns'. The rule is that the extracted text must read in the right order, and that is testable in thirty seconds: open your PDF, select all, paste into a plain text editor, and read what comes out. If it is scrambled, that is what the screen read. Skill bars extract as nothing, graphics extract as nothing, and a header placed inside an image extracts as nothing, which is how people end up submitting an application with no name on it.

Structure, deliberately boring: name and contact including the live portfolio URL and GitHub; an optional two-line summary only if you are changing direction; experience in reverse chronological order; a skills block grouped as Languages / Frameworks / Styling / Testing / Tooling / Accessibility and Performance; education; then projects, which move above experience if you have little or none. Every bullet should read as what you did, to what, with what measured result. The frontend-specific trap is describing the visual output instead of the engineering: 'built a responsive dashboard' says nothing, because every candidate built a responsive dashboard. 'Rebuilt the dashboard's data layer: 14 blocking requests reduced to 3, LCP p75 3.8s to 1.6s, and the table now virtualises at 50,000 rows without losing keyboard focus' says what you are.

Now the portfolio, where frontend differs from every other software role: your work is visible, which cuts both ways. The 2026 complication is that a polished personal site is cheap to generate, so a beautiful portfolio is no longer evidence of anything and a plain one is not disqualifying. What is evidence: something deployed that other people use, which loads fast on a mid-range phone, works with a keyboard, and comes with two paragraphs explaining the constraint you were under and the decision you made. Three strong projects with real write-ups beat twelve thumbnails. Run the obvious checks on your own site before you link it, because a hiring manager who finds a six-second LCP and an unreachable nav on the site of someone claiming performance and accessibility skill has learned everything they need.

The case study shape that works is short and has five parts: what the thing is and who uses it, the constraint (a device, a connection, a deadline, an audit, a legacy system, a data volume), what you decided and what you rejected, the measurement before and after, and what you would do differently. Four hundred words. Screenshots help, a short video of the interaction helps more, a link that works helps most. If your best work is behind a login or under NDA, do not describe it vaguely: rebuild a sanitised slice of the hard part as a public demo, or write the case study without identifying the client and without the proprietary data. Interviewers accept 'I cannot show the code, here is the problem and here is a public reimplementation of the tricky part' without hesitation.

On open source: contributions are not required and their absence is not held against you, but frontend has an unusually good on-ramp. Accessibility fixes, documentation and small component bugs in design-system repositories are mergeable by a newcomer and genuinely useful, and a merged fix in a library a hiring manager has heard of is a stronger signal than any certificate. A drive-by typo fix is not a signal, and nobody is counting your green squares.

If you are coming from an adjacent field, lead with the thing that transfers and remove the ambiguity about whether you can code. Designers moving into frontend have the strongest story in the market right now, since the design-engineer path exists largely for them, so lead with shipped code rather than Figma files and be explicit that you want to build. QA engineers bring testing and browser-matrix knowledge, so lead with the automation you wrote. Marketers and CMS implementers bring conversion and analytics instincts that commerce teams value, so lead with a performance or A/B result and name the engineering you did. In every case, one deployed project with real users removes the 'can they actually do it' question faster than any paragraph of explanation.

• Good bullet: 'Led WCAG 2.1 AA remediation of the customer portal (React, TypeScript): 112 third-party audit findings closed, keyboard and NVDA passes added to the release checklist, re-audit passed with no AA failures.'
• Good bullet: 'Cut route JavaScript from 480KB to 160KB by code-splitting the editor and removing two date libraries; INP p75 340ms to 120ms in real-user monitoring.' Use your own real figures; a number you cannot source in the interview is worse than no number.
• Weak bullet: 'Developed pixel-perfect, responsive, cross-browser user interfaces using modern frontend technologies in an Agile environment.'
• Ignored entirely: skill bars and percentages, 'HTML5 and CSS3' as a skill, a list of twenty-eight technologies, design-tool logos, commit counts, 'passionate about clean code'.
• Put stack nouns where a keyword match cannot miss them: in the bullets where you used them, and again in a grouped skills block. Name the era if it matters (App Router, Angular signals), because it tells a reader how current you are.
• List AI tooling plainly if you use it, then let a bullet about review and verification do the real work. 'Used Claude Code and Copilot' is a tool list; 'introduced a review checklist for generated components that caught missing focus management and duplicate components before merge' is a skill.
• Test your own site the way an interviewer will: PageSpeed Insights for field data, a tab-through, a 200 percent text zoom, a 320 pixel width, and a real phone on a throttled connection.

Where the frontend jobs are, and how to reach a human

Most frontend searches are constrained by where the candidate looks rather than by skill. Aggregator postings from recognisable product brands are the most contested square metre of the market, and that is where most candidates spend most of their effort. Go to the applicant tracking systems directly instead: Greenhouse (boards.greenhouse.io and job-boards.greenhouse.io), Lever (jobs.lever.co) and Ashby (jobs.ashbyhq.com) host a large share of technology postings and index well, so a search of your framework plus your city plus one of those hostnames surfaces roles before they reach the aggregators. Apply the day a posting appears where you can; on high-volume frontend postings the shortlist is often formed from the first wave of applicants.

Make a deliberate pass through the segments that are unglamorous and under-applied, because frontend work there is both plentiful and funded in 2026-27. State and local government and their contractors, where the ADA Title II deadline for large entities has already passed and remediation is now an obligation rather than a plan, and where smaller entities and special districts face April 2027. Public universities and school districts, same reason. Health systems and health technology, where accessibility and browser support floors are strict. Insurance, banking and credit unions, where Angular codebases need people who will take them seriously. Logistics, manufacturing and utilities, where internal tooling is ugly and important. Commerce and media, where Core Web Vitals are attached to revenue and a candidate who can show measured LCP and INP improvement gets hired quickly. These are not consolation prizes: 'remediated a benefits enrolment flow used by 400,000 residents to WCAG 2.1 AA' is a stronger line than most consumer app work.

Three role shapes inside frontend are growing and worth targeting by name, because the competition is thinner than for 'frontend developer': design systems and platform frontend (tokens, component libraries, Storybook, consumer upgrades across teams), design engineering (prototyping and high-craft interaction work next to design), and AI product frontend (streaming interfaces, agentic UIs, evaluation and feedback surfaces). Each has a searchable title and each rewards a portfolio over an algorithms score.

On referrals, what works is narrower than 'network more'. Find the engineer on that team, not a recruiter. Send three sentences: what you built, one specific and non-flattering observation about their product's frontend (a real accessibility or performance finding, politely stated, is the highest-conversion opening a frontend candidate has), and the ask. A note that says 'your checkout has a 4.2s LCP on mobile, mostly an unoptimised hero image and a blocking third-party tag; I fixed the same pattern at X, here is the write-up' gets answered at a rate nothing else matches. Do not send a twenty-finding audit and do not be condescending about it.

If you need visa sponsorship, treat it as a filter on your target list rather than a line in your cover letter. Read each posting's authorisation language before spending an hour on an application: 'must be authorized to work in the US without sponsorship' and 'US person' requirements on government work are real and will not bend. Cap-exempt employers (universities, affiliated nonprofit research organisations, nonprofit and government research organisations) can file H-1B petitions outside the annual cap, which makes them reachable at any time of year and a disproportionately good target. Policy, fees and process in this area moved during 2025 and 2026 with litigation still running, so take dates and costs from the agency's own current pages and an immigration attorney rather than from any article, including this one.

Run the search as a pipeline with stages, not a stream of applications, and act on where you lose. No replies at all means the resume or the target list is wrong. Screens that do not convert means your two-minute story and level framing are wrong. Build rounds that do not convert means practise in a sandbox under a timer. Final rounds that do not convert means the behavioural and cross-functional answers need rehearsing out loud. Fixing the wrong stage is the most common way candidates spend three months without moving.

• Search the ATS hosts directly with your stack plus your city, and search the newer titles as well as the obvious one: 'design engineer', 'UI engineer', 'design systems engineer', 'web accessibility engineer', 'frontend platform engineer'.
• Public-sector postings mostly live on their own job boards, not on aggregators. Check your state, county and city career sites, your state university system, and the contractors named in their procurement records.
• Agencies and consultancies hire year-round and fast. List twenty in your metro, apply directly, and expect a trial exercise rather than a five-round loop.
• The highest-conversion cold outreach available to a frontend candidate is one real, specific, politely stated performance or accessibility finding about the product, plus evidence you have fixed the same class of problem before.
• Interview early for jobs you do not want. The build round is a performance skill and it decays; your first two will be your worst two.
• After a rejection you cared about, reply once: thank them, ask to be considered for other requisitions, ask what would make you stronger. Diarise a re-application in six to twelve months.

What to be paid, and what to actually say

Do not negotiate off a number from an article, this one included, not because pay is unknowable but because the real figures are published, dated and easy to pull yourself. Four sources, in order of usefulness. BLS Occupational Employment and Wage Statistics: code 15-1254 for web developers and 15-1255 for web and digital interface designers, where lower-titled frontend work is counted, and 15-1252 for software developers, where frontend engineers on a software ladder are counted; take the median and the 10th-to-90th spread for your metro rather than the national figure, and remember the release lags the market by about a year. State pay-transparency postings, now required in a growing list of states, so check both your state and the employer's headquarters state rather than any list in an article. The US Department of Labor's foreign labor certification disclosure data, published quarterly from LCA filings, which gives employer-filed base salaries by exact title, internal level and worksite city for employers that sponsor. And for public technology companies, the crowd-sourced levelling databases, which are directionally useful for tier and level even where individual entries are stale.

The largest lever on frontend pay is not your skill, it is which job family the requisition sits in. 'Web Developer' and 'Frontend Engineer' at the same company, doing overlapping work, are frequently on different ladders with different ranges, and the gap can exceed what any negotiation will recover. So ask early, in writing, before you invest four or five hours in a loop: what level is this requisition, what job family does it sit in, and what is the range at that level? A recruiter who will not answer is telling you something. If you are already inside a company on the lower ladder, the move that pays is a transfer to the engineering family, which usually requires the loop you would have sat as an external candidate, so sit it.

Understand the three components before you talk. Base salary is what a lender looks at and what raises compound on. Bonus is typically a target percentage against company and individual performance, and at agencies it is often zero. Equity is where employer tier dominates: at a public company it is a dated grant with a vesting schedule you can value; at a private company it is options or units whose worth depends on a strike price, a valuation, a preference stack and an exit that may not happen, so ask for the strike price, the latest valuation, total shares outstanding, and the vesting and post-termination exercise terms, and value it at zero in your own planning until you have them.

Contract rates are separate arithmetic and frontend is heavily contract-staffed, so learn it. An hourly rate is not a salary divided by 2,080: as a 1099 contractor you cover self-employment tax, health insurance, unpaid time off, unbilled time between engagements, and your own equipment and software. An independent rate has to sit meaningfully above the equivalent salaried hourly figure to be equal, and a W-2 contract through a vendor sits in between. Ask what the vendor's markup is if you can; it is sometimes negotiable and it is always larger than candidates assume.

Two questions specific to 2026-27, cheap to ask before you accept and expensive afterwards. First, is pay location-adjusted, and to what: if the role is remote and the range is tied to a metro tier, a future move changes your salary, and you want the policy in writing rather than described. Second, what is the actual onsite expectation, measured in days per week and enforced how, because stated and practised hybrid policy have diverged at a lot of employers and frontend roles are often among the more remote-friendly, which is worth real money to you.

On mechanics, the short version. When the recruiter asks your expectations in the first call, try not to name a number first: 'I would rather not anchor before I understand the level and the scope. What is the range at the level you are hiring for?' If a form forces a number, give a range whose bottom you would genuinely accept and say where it came from. With one offer and no competing process, the honest lever is scope, level and start date rather than a bluff about a rival offer, because recruiters check and a collapsed bluff costs you goodwill you will need at your first review. And get it in writing before you resign anything: level, job family, base, bonus target, equity grant with vesting and the valuation it was struck at, start date, location and onsite policy. A verbal offer is a plan, not a job.

• Pull your own numbers: BLS OES 15-1254, 15-1255 and 15-1252 for your metro; your state's pay-transparency postings; DOL foreign labor certification disclosure data for sponsored roles; levelling databases for public-company tiers.
• Ask before the loop, not after the offer: what level, what job family, what range at that level.
• If the title offered is 'Web Developer' but the work described is engineering, ask whether the requisition can be opened on the engineering ladder. Sometimes it can, and it is worth more than any raise you will get in the next two years.
• For contract work, price in self-employment tax, insurance, unpaid leave and bench time before comparing an hourly rate to a salary.
• Get the location-adjustment policy and the real onsite expectation in writing, in days per week.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Frontend developer
• Frontend engineer
• UI engineer
• Design engineer
• Web developer
• Semantic HTML
• CSS
• JavaScript
• TypeScript
• React
• React 19
• React Hooks
• React Server Components
• Next.js
• App Router
• Angular
• Angular signals
• Vue 3
• Nuxt
• Svelte
• Astro
• React Native
• Redux
• TanStack Query
• Zustand
• State management
• Component architecture
• Component API design
• Design system
• Design tokens
• Storybook
• Tailwind CSS
• CSS Modules
• CSS Grid
• Flexbox
• Container queries
• Responsive design
• Cross-browser compatibility
• Progressive enhancement
• Server-side rendering
• Static site generation
• Streaming SSR
• Hydration
• Code splitting
• Bundle size optimization
• Vite
• Webpack
• ESLint
• Monorepo
• Core Web Vitals
• Largest Contentful Paint
• Interaction to Next Paint
• Cumulative Layout Shift
• Lighthouse
• Chrome DevTools
• Real user monitoring
• Chrome UX Report
• Performance budget
• Web performance optimization
• Web accessibility
• WCAG 2.1 AA
• WCAG 2.2
• WAI-ARIA
• ARIA Authoring Practices
• Section 508
• ADA Title II
• EN 301 549
• VPAT
• Accessibility remediation
• axe DevTools
• NVDA
• JAWS
• VoiceOver
• Keyboard navigation
• Focus management
• Screen reader testing
• Jest
• Vitest
• React Testing Library
• Playwright
• Cypress
• Visual regression testing
• End-to-end testing
• REST API integration
• GraphQL
• Apollo Client
• Headless CMS
• Internationalization
• Localization
• RTL support
• Git
• Code review
• CI/CD
• Figma
• Web security
• Content Security Policy
• AI-assisted development
• GitHub Copilot
• Cursor
• Claude Code
• LLM streaming UI
• Server-sent events
• Technical SEO

Mistakes that cost people this job

Questions people ask