Frontend Developer interview questions

I treat it as a data-driven decision, not trend-chasing.

• Map the team's real pain points against what the framework actually solves, not its marketing.
• Build a small proof-of-concept on the riskiest integration points; measure bundle size, runtime performance, and developer ergonomics.
• Present that data alongside migration cost, training time, and ecosystem maturity.
• If the numbers don't clearly justify the switch, improve the existing stack incrementally.

I used a strangler-fig migration that ran alongside normal delivery.

• New features were built in the target architecture while a shared adapter layer let old and new code coexist.
• Both ran in parallel behind a feature flag, so QA validated each migrated section independently.
• Over six months every critical path moved over, then we deleted the adapter layer.
• Feature delivery never paused because no sprint was blocked on migration.

I favor composition over configuration and design around real consumers.

• Build small, focused primitives users assemble rather than one component with thirty props.
• Treat the first two or three real consumers as the design input and extract shared interfaces into types.
• Keep escape hatches like renderProp or slot patterns so consumers override behavior without forking.
• Hide internal implementation behind a stable public surface so I can refactor internals without breaking callers.

I map each route to the rendering strategy that fits its content, not one strategy for the whole app.

• SSR fits frequently changing, personalized content but adds server cost and caching complexity.
• SSG wins for mostly stable content because it shifts work to build time and gives very fast TTFB.
• CSR is fine for authenticated dashboards where SEO is irrelevant, but it harms initial load.

I set concrete numbers, enforce them in CI, and document the rationale.

• Define hard limits, for example a 200 KB compressed initial JS bundle and LCP under 2.5 seconds on a mid-range device.
• Wire those numbers into CI so a pull request that exceeds the budget fails the build.
• Record the rationale in a shared ADR so teams understand why the limit exists.
• Review thresholds quarterly as the product evolves.

The event loop runs one task at a time, then drains microtasks before rendering, which shapes how I schedule work.

• Long synchronous tasks block the loop and make the page unresponsive.
• I break expensive computations into chunks with requestIdleCallback or scheduler.postTask.
• I defer non-critical work to microtasks via Promise.resolve.
• I avoid synchronous DOM reads and writes in the same task to prevent layout thrashing.

I build accessibility in from the start using ARIA authoring practices and real assistive-tech testing.

• Start with ARIA authoring practices to define expected keyboard navigation and role semantics for each pattern.
• Give every interactive component a focus management contract: where focus lands on open and on close.
• Test keyboard-only first, then with VoiceOver and NVDA, because the ARIA spec and real browsers diverge.
• Put accessibility requirements into each component's Storybook story as acceptance criteria, not a separate audit.

I sort state into categories and keep their boundaries sharp; the library matters less than that discipline.

• Server cache goes to React Query or SWR, global UI state to Zustand or a minimal Context, local ephemeral state to useState.
• Sharp boundaries prevent syncing server data into a global store and then managing staleness by hand.
• I compute derived state rather than storing it, which eliminates whole classes of sync bugs.

I follow semantic versioning strictly and make every breaking change easy to absorb.

• Any prop removal or behavior change is a major version bump.
• I send a deprecation notice in the previous minor version, with a codemod where feasible.
• I keep a CHANGELOG with migration guides, not just a diff.
• For large teams I run an office-hours session so consumers can ask questions before upgrading.

I find the cause before applying any fix, working from the profiler down.

• Start in the browser profiler to see whether the bottleneck is JavaScript, layout/paint, or network.
• If it is JavaScript, use the React DevTools Profiler to find what re-renders and why.
• The usual culprits are inline object or function literals, missing memoization on expensive values, or a context broadcasting to too many consumers.
• I fix the cause rather than wrapping everything in memo as a patch.

I use a three-tier token system fed from a single source of truth.

• Primitive tokens encode raw values like colors and spacing; semantic tokens map to roles like background-primary; component tokens reference the semantic ones.
• Themes swap only the semantic layer, so a dark theme redefines semantic tokens while primitives stay unchanged.
• I generate tokens from one source, usually Figma Variables or a JSON schema.
• I distribute them as CSS custom properties or platform constants through an automated build step.

I split by route and lazy-load heavy dependencies, guided by bundle analysis.

• Analyze the bundle with webpack-bundle-analyzer to find large deps not needed on the initial route.
• Use React.lazy and Suspense to split each route into its own chunk.
• Put heavy third-party libraries like a charting library behind a dynamic import inside the component that needs them.
• Watch for shared chunk bloat: if every route pulls the same large vendor, revisit lazy-loading or replacing it.

I keep E2E thin, deterministic, and reserved for critical journeys.

• Limit E2E to critical journeys like authentication and checkout; cover the rest with faster unit and integration tests.
• Run each test against a deterministic environment with seeded data so it doesn't depend on external services.
• Assert only observable outcomes, never implementation details.
• Quarantine flaky tests immediately, because known failures train teams to ignore red builds.

My main tools are documentation paired with visible proof and making the right path the default.

• To push accessibility-first work, I ran a two-hour workshop with real screen reader demos, then published a concise guide in the shared wiki.
• I made compliance easy by adding ESLint jsx-a11y rules to the shared config, so the right path became the default.
• I tracked adoption informally and recognized teams that shipped accessible components.
• That created social momentum without requiring mandates.

I tackle each metric separately and track them with real user monitoring, not just Lighthouse.

• For LCP, preload the hero image with link rel=preload, serve it in a modern format like AVIF, and never lazy-load it.
• For CLS, reserve explicit dimensions for every image and embed and avoid inserting dynamic content above existing content.
• For INP, profile long tasks during interactions and break them up or defer non-critical work.
• Track all three in real user monitoring because lab and field scores often diverge.

I prioritize debt by blast radius and cost to fix now versus later.

• Debt in a hot path, blocking delivery, or carrying security and accessibility risk gets fixed this quarter.
• Isolated, well-understood debt that costs only slightly more later goes to the backlog with a clear trigger for urgency.
• I resist debt drives disconnected from product work, because they rarely complete and cause context-switching pain.

I build the edge-case instinct through repetition, not a single lecture.

• Review a specific PR together and ask them to narrate their reasoning aloud.
• The gap is usually the habit of asking what could go wrong before writing the happy path, not knowledge.
• Assign a structured debugging exercise on a past bug report to build that instinct.
• In later reviews, point out the missed edge case and ask for a test before merging.

Cascade layers give you a controllable specificity hierarchy through the @layer rule.

• Styles in a layer declared later win over earlier layers, and un-layered styles win over any layered style by default.
• This controls priority without hacking specificity with extra selectors or !important.
• I use layers when integrating a third-party reset or UI library, putting their styles in a low-priority layer.
• That way my component styles always win without per-selector overrides.

Micro-frontends solve team autonomy and independent deployment, not performance.

• Recommend them only when multiple teams genuinely need independent deploys and monorepo coordination causes measurable pain.
• The costs are real: bundle duplication, shared dependency conflicts, integration test complexity, and orchestration overhead.
• For three to five frontend engineers a well-organized monorepo with clear ownership delivers the same autonomy without the operational complexity.

The pipeline runs in gated stages and stays under eight minutes.

• Stages: install and cache deps, type-check, unit and integration tests, build, visual regression with Chromatic or Percy, deploy to a preview URL.
• Each stage must pass before the next runs.
• Preview deployments are automatic on every pull request so reviewers verify UI without checking out code.
• Main deploys to staging automatically; production promotion is a manual gate.