8 exercises — practice structuring strong English answers to senior frontend interview questions: performance optimisation, application architecture, accessibility, testing strategy, component libraries, state management, cross-browser compatibility, and mentoring.
How to structure Senior Frontend Engineer interview answers
Performance questions: lead with measurement (Core Web Vitals: LCP, CLS, INP) → identify root cause → apply targeted fix → validate with waterfall analysis
Architecture questions: feature-based folder structure mirrors team topology → separate server state (TanStack Query) from client state (Zustand) → enforce module boundaries with tooling
Accessibility questions: semantic HTML first, ARIA only when necessary → integrate into PR checklist and Definition of Done → automate with axe-core in CI → test with real screen readers
Testing questions: apply the frontend testing pyramid → React Testing Library for integration (query by role, not implementation) → Playwright for E2E → visual regression for design systems
Mentoring questions: build capability, not dependence → Socratic pairing (junior drives) → PR reviews explain the why behind changes → scaffold ownership gradually from scoped tasks to full projects
0 / 8 completed
1 / 8
The interviewer asks: "How do you approach performance optimisation on the frontend?" Which answer best demonstrates senior-level depth?
Option B is the strongest: it leads with measurement before action, covers all three Core Web Vitals with the specific cause-and-fix for each, demonstrates DevTools proficiency (scheduler.yield for long tasks), and ends with network waterfall analysis. The Core Web Vitals vocabulary: LCP (Largest Contentful Paint) — measures loading performance; target <2.5s. Common causes: slow server response, render-blocking resources, unoptimised images. CLS (Cumulative Layout Shift) — measures visual stability; target <0.1. Common cause: images without dimensions, dynamically injected content. INP (Interaction to Next Paint) — replaced FID in 2024; measures responsiveness to all interactions throughout the page lifecycle; target <200ms. Code splitting — splitting the JS bundle into smaller chunks loaded on demand (React.lazy, dynamic import()). Lazy loading — deferring load of off-screen images and components until needed. Network waterfall — the timeline of all network requests; render-blocking resources appear as bottlenecks at the top. Option C is factually correct but shallow. Option D covers bundle optimisation well but ignores runtime performance and Core Web Vitals specifics.
2 / 8
The interviewer asks: "How do you architect a large React application for scalability?" Which answer best demonstrates architectural thinking?
Option B is the strongest: it introduces feature-based folder structure with the key insight that it mirrors team topology (Conway's Law), enforces module boundaries via tooling, precisely distinguishes server state from client state with the right tools for each, and acknowledges micro-frontends as the next scalability lever. Key architectural vocabulary: Feature-based folder structure — organising code by business domain, not by file type (not components/, hooks/ but rather auth/, dashboard/, checkout/). Each feature is self-contained. Module boundaries — enforced rules about which modules may import from which. Prevents the "big ball of mud" as the codebase grows. Server state vs client state — a critical distinction: server state (remote data, loading/error status, cache invalidation) is fundamentally different from client state (UI toggles, form input). Conflating them into Redux leads to over-engineering. TanStack Query (React Query) — the standard for server state: fetching, caching, background refetching. Zustand — lightweight client state store; simpler than Redux for most use cases. Micro-frontends — independently deployable frontend modules, often via Webpack Module Federation. Right for large organisations with many teams. Conway's Law — systems tend to mirror the communication structure of the teams that build them; smart architects design with this in mind.
3 / 8
The interviewer asks: "How do you make accessibility a first-class concern in your team?" Which answer best demonstrates a systematic approach?
Option B is the strongest: it reframes accessibility as a process concern (not just a technical checklist), correctly identifies semantic HTML as the foundation, names the specific integration points (Definition of Done, PR checklist), mentions the key testing tools with specific screen reader names, adds CI automation, and crucially states the limitation of automated tools (30–40% coverage) — showing genuine expertise. Key accessibility vocabulary: WCAG (Web Content Accessibility Guidelines) — the international standard; Level AA is the typical legal and industry target. WCAG 2.2 is the current version. Semantic HTML — using <button> for buttons, <nav> for navigation, <h1>-<h6> for headings, etc. The correct element gives browsers and assistive technology the right behaviour for free. ARIA (Accessible Rich Internet Applications) — attributes that supplement HTML semantics when native elements are insufficient. The ARIA Authoring Practices Guide shows correct patterns. First rule of ARIA: don't use ARIA if a native HTML element can do the job. VoiceOver — Apple's built-in screen reader (macOS/iOS). NVDA — free screen reader for Windows (very common among actual screen reader users). axe-core — the leading open-source accessibility engine; powers axe DevTools, Lighthouse, and many CI tools. Definition of Done — integrating accessibility into the team's shared definition ensures it's never deferred.
4 / 8
The interviewer asks: "Explain your approach to testing in a frontend codebase." Which answer best describes a mature testing strategy?
Option B is the strongest: it introduces the key insight that the frontend testing pyramid differs from the backend, explains the rationale behind React Testing Library's philosophy (test by role/label, not implementation details), names the specific tools with precision, includes visual regression testing as a senior-level concern, and ends with the critical principle of high confidence over high coverage. Frontend testing vocabulary: Testing pyramid — the classic model (many units, fewer integration, fewest E2E). On the frontend, integration tests (RTL component tests) often form the largest layer because they give the best confidence-to-cost ratio. React Testing Library (RTL) — the standard for testing React components. Its philosophy: query by accessible role, label, or text — not by CSS class or internal state — so tests resemble real user interaction and survive refactors. Vitest — the modern alternative to Jest; native ESM, faster, better TypeScript support. Playwright — the current leading E2E test framework; cross-browser, fast, reliable. Visual regression testing — capturing screenshots of UI components and diffing them on each build. Chromatic — Storybook's cloud service for visual regression. Testing implementation details — the anti-pattern of asserting on internal component state or checking which functions were called, rather than what the user sees and can do. Implementation detail tests break on refactors even when behaviour is unchanged.
5 / 8
The interviewer asks: "How do you manage shared component libraries across multiple teams?" Which answer best demonstrates design system ownership?
Option B is the strongest: it frames the library as a product with a governance model, defines clear scope boundaries, covers the full release lifecycle including deprecation strategy, names the key tooling with purpose, and adds the human element (office hours) that distinguishes a senior engineer who thinks about adoption from one who thinks only about code. Design system vocabulary: Semantic versioning (SemVer) — MAJOR.MINOR.PATCH. MAJOR = breaking API change; MINOR = new backward-compatible feature; PATCH = backward-compatible bug fix. Breaking changes require a major version bump so consuming teams are not surprised. Storybook — the industry-standard tool for developing, documenting, and visually testing UI components in isolation. Chromatic — visual regression testing integrated with Storybook; catches unintended visual changes on every PR. Contribution model — who can contribute to the library, what the review process is, what belongs in the library vs. in a product codebase. Without this, shared libraries either become a dumping ground or a bottleneck. Deprecation cycle — keeping old APIs working with warnings before removing them, giving consuming teams time to migrate. Design tokens — the abstraction layer below components: named values for colour, spacing, typography that can change across themes without touching component code. Option C covers tokens well but misses governance. Option D is process-focused but lacks the technical depth.
6 / 8
The interviewer asks: "How do you handle state management in a complex frontend application?" Which answer best demonstrates architectural judgment?
Option B is the strongest: it leads with the core conceptual distinction (server state vs client state) and explains why conflating them causes over-engineering, then applies the right tool to each category, follows the principle of locality (keep state close to where it's used), and gives Redux a fair nuanced assessment rather than dismissing it. State management vocabulary: Server state — data that originates on the server and is fetched asynchronously. Has unique characteristics: it can be out of date, multiple components may need the same data, it has loading and error states. Best managed with a dedicated tool. Client state — purely client-side data: modal open/closed, form drafts, theme preference. Does not need to be synchronised with a server. Best managed with lightweight tools. TanStack Query (React Query) — the standard library for server state. Key features: automatic caching, background refetching when the window regains focus, stale-while-revalidate pattern, query deduplication, optimistic updates. Zustand — minimal client state store. No boilerplate, no providers needed (unless SSR), very small bundle. Stale-while-revalidate — show cached (stale) data immediately while fetching a fresh version in the background; users see instant responses. Locality principle — state should live as close as possible to where it's used. useState → Context → global store. Elevating state unnecessarily causes re-renders and coupling.
7 / 8
The interviewer asks: "How do you approach cross-browser and cross-device compatibility?" Which answer best demonstrates a systematic strategy?
Option B is the strongest: it articulates progressive enhancement as the philosophical foundation, explains why feature detection is superior to UA sniffing (fragile and spoofable), ties browser support matrix to real analytics data rather than assumptions, shows that Browserslist drives the build toolchain automatically, covers both automated (Playwright CI) and manual (BrowserStack) testing, and demonstrates iOS-specific knowledge that shows real mobile experience. Cross-browser compatibility vocabulary: Progressive enhancement — build a working baseline for all browsers, then add enhancements for capable browsers. The opposite is graceful degradation (start with the full experience, degrade for older browsers). Feature detection — checking whether the browser supports a feature before using it (CSS @supports, JS typeof, Modernizr). More reliable than user-agent sniffing. User-agent sniffing — inferring browser capabilities from the User-Agent header. Fragile because UA strings are complex, inconsistently formatted, and easily spoofed. Browserslist — a config file (e.g., > 0.5%, last 2 versions, not dead) that specifies your supported browser range. Babel, PostCSS/Autoprefixer, ESLint, and other tools read it automatically. BrowserStack — cloud platform for testing on real browsers and devices. Safe-area-inset — CSS environment variables (env(safe-area-inset-bottom)) for handling notched iPhone displays. Touch targets — interactive elements should be at least 44×44px (Apple) or 48×48dp (Material Design) to be reliably tappable.
8 / 8
The interviewer asks: "How do you mentor junior frontend engineers effectively?" Which answer best demonstrates senior-level leadership?
Option B is the strongest: it articulates the core philosophy (building capability vs solving problems), explains the specific technique for PR reviews (why, not just what), describes the Socratic pairing method, introduces the scaffolded ownership progression, and adds the often-overlooked practices of tracking growth explicitly and involving juniors in architecture discussions. Senior-level mentoring vocabulary: Socratic method — guiding through questions rather than giving answers. "What do you think happens if we call this function twice?" rather than "Don't call this function twice." Develops the junior's reasoning, not dependence on the senior. Scaffolded ownership — the deliberate progression of increasing responsibility: well-defined task → ambiguous task → full feature → small project. Matches challenge to current capability. PR review as teaching — the most high-leverage mentoring touchpoint in a software team. The best review comments explain the principle behind the change ("We avoid this pattern because it makes testing harder") not just the fix. Explain the why — juniors who only hear "change X to Y" don't build judgment. Juniors who hear "change X to Y because of principle Z" start to internalise the decision-making process. Involvement in architecture discussions — even as observers, juniors who sit in on architecture discussions absorb the vocabulary and reasoning patterns that accelerate their growth. Options C and D describe caring, available managers but lack the structured capability-building philosophy that distinguishes a senior mentor.