Walk me through how you would optimise a React app's Largest Contentful Paint.

Performance is the question that separates senior from mid Frontend Engineers in 2026. The panel wants method, not memorisation. Strong candidates start by asking what the current LCP is, what the LCP element is (image, hero text block, video) and what the device profile looks like. They then walk through the ladder: server-render the LCP element, preload its resource, cut render-blocking CSS, defer non-critical JavaScript, optimise the image format and size, and verify with Lighthouse and real-device testing. Weak candidates jump to lazy loading or code splitting without identifying the bottleneck. The kill-shot is recommending compression alone or claiming you have never measured LCP. UK panels expect Core Web Vitals literacy at senior level.

How do you decide between React Server Components, client components and static pre-rendering?

This is the architecture question for 2026 Next.js interviews. The panel wants to hear that you choose by data freshness, interactivity needs and SEO requirements. Strong answers: server components for content that does not change per user (marketing pages, product pages), client components for anything with state or browser APIs (forms, dashboards, charts), static pre-rendering with revalidation for content that changes infrequently. Mention the partial pre-rendering pattern. Weak candidates say 'use server components everywhere' or describe an outdated pages-router mental model. The kill-shot is not knowing the difference between server and client components. If you only know pages router, prep app router thoroughly before any 2026 interview.

Tell me how you approach accessibility in a React component.

Accessibility in 2026 is not optional, and panels test for it directly. Strong answers cover: semantic HTML first, ARIA attributes only when semantics cannot express the pattern, keyboard navigation including focus management, screen reader testing with at least VoiceOver or NVDA, colour contrast checking, and respecting prefers-reduced-motion. Mention WCAG 2.2 AA as the UK target. Strong candidates demonstrate they have tested with real assistive tech, not just ESLint plugins. Weak candidates list ARIA roles without context or claim 'we use a component library that handles it'. The kill-shot is admitting you have never used a screen reader. UK companies, especially in regulated sectors, treat accessibility as a hiring filter.

How do you handle state in a complex React app — Context, Redux, Zustand, or something else?

State management answers reveal seniority. Strong candidates start by asking what kind of state — server state, URL state, form state, ephemeral UI state, persistent client state — because the answer differs for each. They then map: TanStack Query for server state, useState/useReducer for ephemeral, URL search params for shareable filters, Zustand or Jotai for cross-component client state. Mention React Context's re-render performance trap. Weak candidates default to 'Redux' for everything or say 'just use Context'. The kill-shot is recommending a single tool for all state types. UK senior frontend interviews now expect this mental model; junior frontend interviews increasingly expect it too.

Walk me through how you would design a design system from scratch.

Design system questions test architecture instinct and design partnership. Strong answers cover: token layer (colour, spacing, typography as JSON or CSS variables), primitive components (Button, Input, Box), composed components (Form, Card, Modal), and patterns (NavBar, ListView). Mention accessibility primitives, theming strategy, and how the design team will contribute. Strong candidates discuss versioning, deprecation paths and Figma integration. Weak candidates describe a Storybook setup without underlying token strategy or skip design partnership entirely. The kill-shot is not mentioning how designers and engineers stay in sync. Design systems are a cross-discipline product, and panels test whether you understand that.

Tell me about a time you cut bundle size on a production app.

Behavioural with technical depth. The panel wants a specific bundle-size war story with measurable before-and-after. Strong answers: 'The bundle was 1.4MB minified, INP was 480ms on mid-tier Android. I ran webpack-bundle-analyzer, found we were shipping the full Lodash and Moment.js. I replaced Moment with date-fns, switched to per-method Lodash imports, dynamically imported the chart library used on one page, and audited every npm package above 50KB. Bundle dropped to 380KB, INP improved to 180ms, conversion lifted 3 percent.' Weak answers describe generic optimisation without numbers. The kill-shot is having no story at all. Senior Frontend Engineers in 2026 should have at least one bundle-size war story to tell.

How would you migrate a legacy CSS codebase to a modern approach?

This is a question I see often at companies with ten-year-old products. Strong answers cover: audit existing CSS for token candidates (colours, spacing, type sizes), pick a target (CSS modules, Tailwind, vanilla-extract, or kept as CSS with custom properties), introduce alongside legacy without rewriting everything, set a deprecation policy for new code, and migrate component-by-component during regular feature work. Mention strangler-fig pattern. Weak candidates propose a big-bang rewrite or say 'I would just use Tailwind'. The kill-shot is underestimating how much CSS work is design-system work. UK panels at established companies test this scenario specifically because they live it.

Tell me about a time you disagreed with a designer on a UX decision.

Pure behavioural, but specific to frontend. The panel checks whether you can push back on design with engineering insight without being difficult. Strong answers describe a specific decision (animation that hurt performance, layout that broke at narrow viewports, interaction that failed accessibility), explain how you raised it (with prototype or numbers, not opinion), and how you reached resolution. Weak answers either show you always deferred to design or never collaborated. The kill-shot is bad-mouthing designers or describing a disagreement that ended badly. Strong Frontend Engineers in 2026 are design partners, not implementers; panels test the partnership instinct directly.

How do you test a React component beyond unit tests?

Testing strategy reveals seniority. Strong candidates describe the test pyramid for frontend: unit tests with React Testing Library for behaviour (not implementation), integration tests for full user flows, end-to-end tests with Playwright or Cypress for critical paths, accessibility tests with jest-axe, and visual regression tests with Chromatic or Percy for design-system components. Mention contract testing with the backend if you use TypeScript end-to-end. Weak candidates say 'we use Jest' and stop there. The kill-shot is testing implementation details (component state, internal methods) instead of user-visible behaviour. Senior Frontend Engineers know the difference, and panels in 2026 dig into it specifically.

How do you keep up with the frontend ecosystem without churning your stack every six months?

Process question that reveals judgement. Strong answers describe a filter: read the React core team blog and Vercel blog, follow specific engineers (Dan Abramov, Lee Robinson, Jason Miller) rather than trends, evaluate new tools by problem they solve not novelty, and require a real production benefit before introducing them. Mention that you wait for tools to mature past the hype curve. Weak candidates either claim to use every new tool or admit they have not learned anything new in two years. The kill-shot is name-dropping framework names without understanding their underlying ideas. UK panels at senior level want frontend engineers who can resist hype as much as adopt it.

Walk me through how you would build streaming UI for an LLM chat interface.

AI integration is now a regular frontend interview topic in 2026. Strong answers cover: server-sent events or streaming response handling, Suspense boundaries for partial UI, optimistic updates for the user message, error recovery (retry, regenerate), token-by-token rendering with smooth scrolling, and accessibility (announcing new content to screen readers). Mention prompt-injection display safety (rendering markdown safely). Weak candidates describe a polling loop or skip the accessibility piece. The kill-shot is not knowing what streaming UI even is. AI features are 2026's most asked-about scenario in frontend interviews; if you have not built one, build one before applying.

Why are you leaving your current role?

Standard closer, weighted heavily for senior frontend hires. Strong answers are forward-looking: you have shipped what you set out to ship, the next feature pipeline does not match your growth, you want a role with deeper performance work or design-system ownership, you want a 2026-stack environment if your current stack is dated. Weak answers attack your current employer or say 'pay'. The kill-shot is criticising teammates by name. UK frontend is a small community in London, Manchester and Bristol; everyone interviewing you knows your tech lead. Stay forward-looking and credible. The panel wants reassurance you will not have the same complaint about them in 18 months.

Interview Q's · Tech · UK 2026

Frontend Engineer Interview Questions UK

Frontend Engineer interviews in UK 2026 are sharper than they were three years ago. The frontend market matured, expectations rose, and the candidates who treat frontend as easier than backend get filtered out fast. Panels test React/Next.js fluency, but they also test performance instinct, accessibility judgement and design partnership, because the modern Frontend Engineer owns the full feature surface, not just JSX. The 12 questions below are the ones I see in real London-and-Manchester loops at fintech, e-commerce and SaaS companies. I have written each answer from the recruiter's side: what the panel is testing for, what a strong response looks like, and what mistake immediately ends the conversation.

By Alex · 12-year UK recruiter · 12 questions + recruiter answers

Question 1

Walk me through how you would optimise a React app's Largest Contentful Paint.

Performance is the question that separates senior from mid Frontend Engineers in 2026. The panel wants method, not memorisation. Strong candidates start by asking what the current LCP is, what the LCP element is (image, hero text block, video) and what the device profile looks like. They then walk through the ladder: server-render the LCP element, preload its resource, cut render-blocking CSS, defer non-critical JavaScript, optimise the image format and size, and verify with Lighthouse and real-device testing. Weak candidates jump to lazy loading or code splitting without identifying the bottleneck. The kill-shot is recommending compression alone or claiming you have never measured LCP. UK panels expect Core Web Vitals literacy at senior level.
Question 2

How do you decide between React Server Components, client components and static pre-rendering?

This is the architecture question for 2026 Next.js interviews. The panel wants to hear that you choose by data freshness, interactivity needs and SEO requirements. Strong answers: server components for content that does not change per user (marketing pages, product pages), client components for anything with state or browser APIs (forms, dashboards, charts), static pre-rendering with revalidation for content that changes infrequently. Mention the partial pre-rendering pattern. Weak candidates say 'use server components everywhere' or describe an outdated pages-router mental model. The kill-shot is not knowing the difference between server and client components. If you only know pages router, prep app router thoroughly before any 2026 interview.
Question 3

Tell me how you approach accessibility in a React component.

Accessibility in 2026 is not optional, and panels test for it directly. Strong answers cover: semantic HTML first, ARIA attributes only when semantics cannot express the pattern, keyboard navigation including focus management, screen reader testing with at least VoiceOver or NVDA, colour contrast checking, and respecting prefers-reduced-motion. Mention WCAG 2.2 AA as the UK target. Strong candidates demonstrate they have tested with real assistive tech, not just ESLint plugins. Weak candidates list ARIA roles without context or claim 'we use a component library that handles it'. The kill-shot is admitting you have never used a screen reader. UK companies, especially in regulated sectors, treat accessibility as a hiring filter.
Question 4

How do you handle state in a complex React app — Context, Redux, Zustand, or something else?

State management answers reveal seniority. Strong candidates start by asking what kind of state — server state, URL state, form state, ephemeral UI state, persistent client state — because the answer differs for each. They then map: TanStack Query for server state, useState/useReducer for ephemeral, URL search params for shareable filters, Zustand or Jotai for cross-component client state. Mention React Context's re-render performance trap. Weak candidates default to 'Redux' for everything or say 'just use Context'. The kill-shot is recommending a single tool for all state types. UK senior frontend interviews now expect this mental model; junior frontend interviews increasingly expect it too.
Question 5

Walk me through how you would design a design system from scratch.

Design system questions test architecture instinct and design partnership. Strong answers cover: token layer (colour, spacing, typography as JSON or CSS variables), primitive components (Button, Input, Box), composed components (Form, Card, Modal), and patterns (NavBar, ListView). Mention accessibility primitives, theming strategy, and how the design team will contribute. Strong candidates discuss versioning, deprecation paths and Figma integration. Weak candidates describe a Storybook setup without underlying token strategy or skip design partnership entirely. The kill-shot is not mentioning how designers and engineers stay in sync. Design systems are a cross-discipline product, and panels test whether you understand that.
Question 6

Tell me about a time you cut bundle size on a production app.

Behavioural with technical depth. The panel wants a specific bundle-size war story with measurable before-and-after. Strong answers: 'The bundle was 1.4MB minified, INP was 480ms on mid-tier Android. I ran webpack-bundle-analyzer, found we were shipping the full Lodash and Moment.js. I replaced Moment with date-fns, switched to per-method Lodash imports, dynamically imported the chart library used on one page, and audited every npm package above 50KB. Bundle dropped to 380KB, INP improved to 180ms, conversion lifted 3 percent.' Weak answers describe generic optimisation without numbers. The kill-shot is having no story at all. Senior Frontend Engineers in 2026 should have at least one bundle-size war story to tell.
Question 7

How would you migrate a legacy CSS codebase to a modern approach?

This is a question I see often at companies with ten-year-old products. Strong answers cover: audit existing CSS for token candidates (colours, spacing, type sizes), pick a target (CSS modules, Tailwind, vanilla-extract, or kept as CSS with custom properties), introduce alongside legacy without rewriting everything, set a deprecation policy for new code, and migrate component-by-component during regular feature work. Mention strangler-fig pattern. Weak candidates propose a big-bang rewrite or say 'I would just use Tailwind'. The kill-shot is underestimating how much CSS work is design-system work. UK panels at established companies test this scenario specifically because they live it.
Question 8

Tell me about a time you disagreed with a designer on a UX decision.

Pure behavioural, but specific to frontend. The panel checks whether you can push back on design with engineering insight without being difficult. Strong answers describe a specific decision (animation that hurt performance, layout that broke at narrow viewports, interaction that failed accessibility), explain how you raised it (with prototype or numbers, not opinion), and how you reached resolution. Weak answers either show you always deferred to design or never collaborated. The kill-shot is bad-mouthing designers or describing a disagreement that ended badly. Strong Frontend Engineers in 2026 are design partners, not implementers; panels test the partnership instinct directly.
Question 9

How do you test a React component beyond unit tests?

Testing strategy reveals seniority. Strong candidates describe the test pyramid for frontend: unit tests with React Testing Library for behaviour (not implementation), integration tests for full user flows, end-to-end tests with Playwright or Cypress for critical paths, accessibility tests with jest-axe, and visual regression tests with Chromatic or Percy for design-system components. Mention contract testing with the backend if you use TypeScript end-to-end. Weak candidates say 'we use Jest' and stop there. The kill-shot is testing implementation details (component state, internal methods) instead of user-visible behaviour. Senior Frontend Engineers know the difference, and panels in 2026 dig into it specifically.
Question 10

How do you keep up with the frontend ecosystem without churning your stack every six months?

Process question that reveals judgement. Strong answers describe a filter: read the React core team blog and Vercel blog, follow specific engineers (Dan Abramov, Lee Robinson, Jason Miller) rather than trends, evaluate new tools by problem they solve not novelty, and require a real production benefit before introducing them. Mention that you wait for tools to mature past the hype curve. Weak candidates either claim to use every new tool or admit they have not learned anything new in two years. The kill-shot is name-dropping framework names without understanding their underlying ideas. UK panels at senior level want frontend engineers who can resist hype as much as adopt it.
Question 11

Walk me through how you would build streaming UI for an LLM chat interface.

AI integration is now a regular frontend interview topic in 2026. Strong answers cover: server-sent events or streaming response handling, Suspense boundaries for partial UI, optimistic updates for the user message, error recovery (retry, regenerate), token-by-token rendering with smooth scrolling, and accessibility (announcing new content to screen readers). Mention prompt-injection display safety (rendering markdown safely). Weak candidates describe a polling loop or skip the accessibility piece. The kill-shot is not knowing what streaming UI even is. AI features are 2026's most asked-about scenario in frontend interviews; if you have not built one, build one before applying.
Question 12

Why are you leaving your current role?

Standard closer, weighted heavily for senior frontend hires. Strong answers are forward-looking: you have shipped what you set out to ship, the next feature pipeline does not match your growth, you want a role with deeper performance work or design-system ownership, you want a 2026-stack environment if your current stack is dated. Weak answers attack your current employer or say 'pay'. The kill-shot is criticising teammates by name. UK frontend is a small community in London, Manchester and Bristol; everyone interviewing you knows your tech lead. Stay forward-looking and credible. The panel wants reassurance you will not have the same complaint about them in 18 months.

How to use these answers

Frontend interviews in UK 2026 weight three things: technical depth (React/Next.js, performance, accessibility), design partnership (working with designers, not just implementing) and shipped product instinct (you have ship stories with numbers). The single biggest mistake I see Frontend Engineers make is treating frontend as easier than backend; modern panels actively test for the assumption and reject candidates who hold it. Prep with a real shipped feature you can talk through end-to-end, including the performance numbers, the accessibility decisions, and what you learned. Practise the system-design round on frontend-specific problems (image gallery, infinite scroll, design system) — not just generic system design. And make sure your portfolio is current; an outdated personal site is a credibility killer for senior frontend hires.

Related across UK Rights & Guides

Keep reading

Browse the JobLabs UK careers reference →

Pillars + free tools

Related job-search guides + calculators

Pillars

→ UK Career Change handbook — sector-switch playbook
→ UK CV deconstruction pillar — CV format + ATS-safe AI prompts
→ UK Interview Prep — competency pillar — STAR + 4-stage UK process
→ UK Cover Letter — recruiter-eye guide — five UK opening patterns

Free recruiter-built tools