Frontend development is the layer between an API contract and the pixels a person actually touches: rendering, state, interaction and the performance of all three inside a browser engine. The measured reality of that work keeps shifting. The Web Almanac's 2024 crawl finds the median page now ships 613 kilobytes of JavaScript on desktop and 558 on mobile, up 14% in a year, with the median mobile page making 22 JavaScript requests. Interaction to Next Paint (INP) replaced First Input Delay as the responsiveness Core Web Vital in 2024, and only 74% of mobile origins score "good" against it, versus 97% on desktop. The web applications being built sit on that asymmetry, and hiring for frontend development is mostly about finding engineers who already understand it.
Challenges in Frontend Development Recruiting
React and Angular split web applications into separate labour markets
In the 2025 Stack Overflow survey, React remains the most used front-end framework at 46.9% of professional developers, with Angular at 19.8%, Vue.js at 18.4% and Next.js at 21.5%. Behind those numbers sit two different disciplines. React work is mostly composition: hooks, state ownership, render optimisation and an ecosystem that repackages itself every eighteen months. Angular work is a framework with a compiler, dependency injection and a change-detection model, which attracts teams that value a bounded set of choices. A candidate listing both rarely has production depth in either. The hiring filter to apply is migration pressure: a Vue.js shop replacing a legacy AngularJS admin, or a React codebase onboarding a design system, needs different people than a greenfield Next.js product. Meanwhile the installed web runs on jQuery, which still appears on 74% of crawled pages, so "framework experience" in a brief frequently means nothing about the codebase the hire will actually join. Frontend development hiring works better when the brief names the framework generation and the migration pressure around it, not just a library name.
JavaScript the language, TypeScript the type system
TypeScript has posted the most dramatic five-year rise in real-world usage across all languages, JetBrains reports, with JavaScript itself reaching its maturity plateau. The distinction matters at hiring because the two skills live at different altitudes. JavaScript depth means understanding the event loop, closures, hoisting and the prototype chain well enough to debug a timing bug in someone else's code. TypeScript depth means modelling the domain: discriminated unions, narrowing, module boundaries and a compiler that the team respects rather than silences with any. A CV that lists both usually has one. The probe: ask how they would type a reducer whose actions span three states, then ask why a stale closure fires in a setTimeout. Strong frontend candidates answer both, but only one comfortably.
Web performance lives in INP, not in a Lighthouse screenshot
The 2024 crawl shows mobile blocking time of nearly three seconds at the 75th percentile, and 5.95 seconds at the 90th, while long tasks are the main contributor to poor INP, and the median page ships 12 kilobytes of JavaScript that could have been minified. A good INP is 200 milliseconds or less, and the metric watches every interaction, not just the first one, which is why it punishes work the older metric forgave. None of this appears in a portfolio. Web performance experience means reading main-thread flame charts, splitting bundles so the first paint ships less JavaScript, deferring hydration until input arrives, and knowing which third-party script is eating the interaction budget. It also means knowing the frame budget cold: sixty frames a second leaves sixteen milliseconds for everything a click must do. It is a debugging discipline, not a checklist, and it transfers across frameworks in a way framework trivia does not. Screening for it means handing over a real trace and watching where the candidate starts.
Frontend architecture that survives the fourth product team
Frameworks change faster than the architecture built on them. The median page already requests 22 to 24 JavaScript files, third-party requests keep growing at the 90th percentile, and first-party unminified code accounts for 82.7% of wasted bytes. That complexity is organisational before it is technical: five teams shipping into one application produce duplicated state, three patterns for the same fetch and a build pipeline nobody owns. Frontend architecture is the discipline that decides the boundaries in advance: state ownership, server data contracts, module federation or its opposite, one codebase with strict review. Candidates for that seat are hired on evidence of decisions that outlived a feature: the shared state model they introduced, the migration they led, the abstraction they deliberately refused. Ask what they would refuse to build, and why; frontend architecture is as much the boundaries a team does not cross as the ones it does. A component-library resumé alone does not say it.
Responsive design is a device matrix, not a viewport
The desktop-to-mobile INP gap is the honest summary: 97% of desktop origins score good against 74% on mobile, a gap of more than twenty points that has narrowed only slowly. Responsive design therefore lives in the device matrix: the low-end Android phone on a 3G tower, the tablet with a split keyboard, the 200% zoom user, the screen reader that does not care about breakpoints. A candidate who has shipped for that matrix talks about tested devices, fallback layouts and the interaction that broke on one browser; they also talk about load order, font rendering and the fixed header that jumped on zoom. A candidate who has shipped for one viewport talks about media queries. The interview should ask which device hurt the most and what changed in the code. Real responsive design answers arrive with a bug report attached.
Hydration, long tasks and web performance a portfolio cannot show
Frontend claims compress into the same nouns: React, Angular, TypeScript, responsive design. Verification has to chase the work nobody screenshots. Walk a slow interaction end to end: where the long task came from, what hydration was doing at the time, which script could be deferred, what the bundle budget should be and who enforces it. Then ask about the states nobody designs for: the empty screen, the failed fetch, the second click that breaks the first, the long label that overflows the button in German. All of it is frontend work, and none of it photographs well, which is exactly why it separates people who have shipped from people who have styled. The cost of skipping this is real. A weak senior frontend hire normalises a growing bundle and an untested browser matrix across every team that consumes the components, and the fix lands months later as a rewrite nobody planned. Good assessment is the same discipline as good frontend architecture: name the constraints, then verify them against evidence the candidate personally produced.
References
- Web Almanac 2024: JavaScript — HTTP Archive. (accessed 2026-09-28)
- Web Almanac 2024: Performance — HTTP Archive. (accessed 2026-09-28)
- 2025 Stack Overflow Developer Survey: Technology — Stack Overflow. (accessed 2026-09-28)
- The State of Developer Ecosystem 2025: Coding in the Age of AI — JetBrains. (accessed 2026-09-28)
- Interaction to Next Paint (INP) — web.dev. (accessed 2026-09-28)