Senior Frontend Developer Interview Questions & Answers

THE QUESTIONS

Real questions, senior answers

1. 01

   What is Webpack used for?

   It's a module bundler: it parses your imports and exports, builds a dependency graph from your entry point, and combines hundreds of files into deployable bundles.

   The alternative — a script tag per file — stopped being practical the moment applications grew past a handful of modules.

   Module bundlersDependency graph
2. 02

   What is tree shaking, and when does it NOT work?

   Dead-code elimination at bundle time: the bundler drops modules — and parts of modules — that nothing imports. Default since Webpack 5.

   The catch: it only works with static ES module imports. CommonJS require() calls are dynamic, evaluated at runtime, so the bundler can't prove what's unused. One CJS dependency and that subtree ships whole.

   Dead code eliminationESM vs CommonJS
3. 03

   What are the trade-offs of CSS-in-JS?

   The win: dynamic styles driven by JavaScript state, and generated class names that end specificity conflicts.

   The costs: your CSS rides inside the JS bundle, so it can't be cached separately and gets parsed late — hello cumulative layout shift. Debugging hashed class names is worse. And in React, every styled element is another component in an already deep tree.

   Mitigation: extract the styles at build time and serve them from the CDN like ordinary CSS.

   styled-componentsCachingCLS
4. 04

   What is an error boundary component?

   A component that localizes failures: when a child throws — say a data fetch renders bad state — the boundary catches it and renders a fallback instead of letting the whole tree unmount.

   One broken widget shouldn't take down the page. Boundaries make the blast radius a design decision.

   Error handlingFault isolation
5. 05

   Why can't you pass an async function directly to useEffect?

   Because useEffect's return value must be the cleanup function — the thing that removes event handlers so re-renders don't stack them up.

   An async function always returns a promise, and React doesn't know what to do with a promise where a cleanup function belongs. Define the async function inside the effect and call it.

   useEffectCleanup functions
6. 06

   An app has fetched data, auth state, and global user settings with complex transitions. How do you organize state?

   Three different homes. Fetched data stays in component state, lifted only when siblings need it. Auth goes in context — it's genuinely global, everything checks roles and permissions.

   Settings with non-trivial transitions want the reducer pattern — useReducer with context, or a small store — because complex state transitions need one deterministic, testable transition function.

   State placementContextReducer pattern
7. 07

   What's the difference between essential and derived state?

   Essential state changes on its own — the items in a cart. Derived state can be computed from it — the subtotal, the VAT.

   Keep only essential state in your hooks and compute the rest. Every redundant state variable is a future sync bug.

   Essential stateDerived values
8. 08

   What are the drawbacks of putting state in React context?

   Every consumer re-renders whenever the context value changes. Lift independent state into one context and you've coupled unrelated components' render cycles.

   Split contexts by change pattern, and keep state as close to where it's used as possible. Context is a broadcast tool, not a default store.

   Context re-rendersState locality
9. 09

   You inherit a React app with zero tests. How do you approach testing it?

   End-to-end tests first: they cover features, and they survive refactors because they don't care how the code is shaped. Then unit tests on reusable components with real logic — not on whether an image renders.

   Integration tests go on the critical paths: login, payments. The balance matters because e2e failures tell you something broke; unit tests tell you where.

   Testing pyramidE2E first
10. 10

    What is code coverage, and how much is appropriate on the frontend?

    The percentage of code that executes while tests run — not the percentage that's meaningfully verified.

    On the frontend, 60-70% is the honest target: below 60 the suite isn't trustworthy, above 80-90 you're writing tests for the metric. Mandated 95% produces test theater — we've watched it happen.

    Coverage targetsTest quality
11. 11

    What causes a bad First Contentful Paint, and how do you fix it?

    The usual suspects: a huge client-rendered JS bundle, no CDN (uncompressed, uncached assets), and a pile of render-blocking CSS.

    Triage in order of leverage: CDN with caching and compression first. Then audit the bundle and drop dead weight. Then code-split by route — with the product manager, pick the pages that must be fast — and lazy-load the rest.

    FCPCDNCode splitting
12. 12

    When would you introduce server-side rendering — and when not?

    SSR pays off when the product is sensitive to loading speed or SEO: e-commerce, media. The user gets real HTML instantly.

    For a SaaS dashboard behind a login, it's complexity without payoff — client-side rendering is fine. Teams that rushed to SSR have rolled it back; treat it as a product decision, not a default.

    SSR trade-offsSEOProduct thinking