Frontend developer interview questions, with worked answers

How to use these questions

Say the short answer out loud first: that is your opening half minute. Then pick two or three points from the full answer and add one screen you built yourself: what was slow or broken, what you measured, what you changed. Interviewers listen for measurements and for the user, not for a list of libraries.

What a frontend developer is expected to know

• The language: JavaScriptAsked in 54% of frontend developer ads (as of 5 Nov 2026).The language of the browser: closures, promises, the event loop, and reading a stack trace calmly. in depth, and TypeScriptAsked in 48% of frontend developer ads (as of 5 Nov 2026).Types for props, API responses and state, so mistakes show in the editor before they reach users. for anything that more than one person changes.
• The page: semantic HTML and CSSAsked in 59% of frontend developer ads (as of 5 Nov 2026).Semantic HTML, Flexbox and Grid, responsive layouts, and CSS that a team can still change next year., Flexbox and Grid, and layouts that work from a small phone to a wide screen.
• A framework: ReactAsked in 37% of frontend developer ads (as of 5 Nov 2026).Components, hooks, state and effects; knowing why a component renders, and how to stop it rendering too often., AngularAsked in 41% of frontend developer ads (as of 5 Nov 2026).Common at banks, insurers and large companies: modules, services, RxJS streams and strict structure. or Vue.jsAsked in 24% of frontend developer ads (as of 5 Nov 2026).A lighter framework popular with agencies and smaller product teams; components and reactive state., and why it renders what it renders.
• Data: calling REST APIsAsked in 33% of frontend developer ads (as of 5 Nov 2026).Call APIs well: loading and error states, retries, caching, and agreeing the response shape with backend., loading and error states, and caching what the user has already seen.
• Quality: component tests (unit testingAsked in 11% of frontend developer ads (as of 5 Nov 2026).Test components by what the user sees and does, not by their inner workings.), a few end-to-end tests (test automationAsked in 5% of frontend developer ads (as of 5 Nov 2026).End-to-end tests in a real browser for the few flows that must never break, such as checkout.), accessibility and page speed.
• Working together: reading designs in FigmaRead a design file: spacing, tokens, states and variants, and spot what the design forgot., GitAsked in 35% of frontend developer ads (as of 5 Nov 2026).Small branches, clear commits and reviews; resolving a merge conflict without losing work. reviews, and CI/CDAsked in 25% of frontend developer ads (as of 5 Nov 2026).Every change is built, tested and previewed automatically, so a release is boring. previews of every change.

The browser and page speed

What happens in the browser between typing an address and seeing the page?

What they check: that you know the steps the browser takes, so you can tell which one is slow.

Short answer: "The browser finds the server, downloads the HTML, and starts building the page. It fetches the CSS and scripts the HTML names, works out the layout, and paints the pixels. Scripts can block that work, so I keep the first view small and load the rest later."

The full answer: First the address is looked up (DNS) and a secure connection is opened. The HTML arrives and is read top to bottom into a tree of elements, the DOM. CSS is read into rules; the browser needs it before it can paint, so it is render-blocking. A script without async or defer stops reading until it has run. Then the browser works out the size and place of every box (layout) and paints them. Later changes repeat some of these steps; changing a size makes the browser lay out again, which is costly in a long list. Rendering well means sending less, sooner.

A weak answer: "The server sends the page and React shows it." Follow-up: "Which of these steps does a big script slow down?" Downloading, reading and running it: the main thread is busy, so the page cannot respond to the user.

A product page loads slowly on phones. How do you find out why, and how do you fix it?

What they check: that you measure before you change anything, and know the usual causes.

Short answer: "I measure on a mid-range phone and a slow network, not on my laptop. I look at the Core Web Vitals: when the main content appears, how fast the page reacts to a tap, and whether things jump around. Then I fix the biggest cause first and measure again."

The full answer, in six steps:

1. Measure real users. Field data from real visits shows the truth; a lab test on a fast laptop hides the problem. Core Web Vitals are Google's three measures: Largest Contentful Paint (when the main content appears), Interaction to Next Paint (how quickly the page reacts) and Cumulative Layout Shift (how much things move).
2. Find the biggest item. Usually the hero image or the main heading. Send that image in the right size and a modern format, and tell the browser to fetch it early.
3. Cut the script. Look at what each page downloads. Split the bundle so each page loads only its own code, remove unused libraries, and load chat widgets and trackers after the page is usable.
4. Free the main thread. Long tasks over fifty milliseconds make taps feel slow. Break them up, or move heavy work off the main thread.
5. Stop the jumps. Give images and adverts a fixed space before they load, so content does not move under the reader's thumb.
6. Keep it fast. Add a performance budget to CI/CDAsked in 25% of frontend developer ads (as of 5 Nov 2026).Every change is built, tested and previewed automatically, so a release is boring., so a change that makes the bundle much larger fails its check before release.

A weak answer: "I would add a loading spinner." A spinner hides slowness; it does not remove it.

Follow-up: "The marketing team adds three tracking scripts. What do you do?" Measure their cost, load them after the page is interactive, and agree a budget with marketing so the cost is visible.

Server-side rendering, static pages or rendering in the browser: how do you choose?

What they check: that you match the rendering to the page, not to a fashion.

Short answer: "Pages that must be found by search engines and show fast, such as product pages, are rendered on the server or built ahead as static pages. Screens behind a login, such as a dashboard, can render in the browser. Many apps mix the two."

The full answer: Client-side rendering sends an almost empty page and builds it with JavaScript; simple to host, but the first view waits for the script, and search engines see less. Server-side rendering builds the HTML for each request, so the content shows at once and SEOPages that search engines can read: server rendering, titles, links and fast loading. is easier, but it needs a server and hydration, where the browser attaches the JavaScript to the server's HTML. Static generation builds pages ahead of time: fastest of all, for content that changes rarely. Frameworks such as Next.js let each page choose.

A weak answer: "Always server-side rendering, because it is faster." Follow-up: "The server-rendered page shows quickly but buttons do nothing for two seconds. Why?" Hydration has not finished; send less JavaScript, or make the important parts interactive first.

What is the event loop, and why does a long task freeze the page?

What they check: that you understand how JavaScript runs in the browser.

Short answer: "JavaScript in the page runs on one main thread, one task at a time. The event loop takes the next task from a queue when the current one finishes. If a task runs for a long time, clicks, typing and painting all wait, so the page freezes."

The full answer: Timers, network replies and user events each put a task in a queue. Promises run in a separate, faster queue that empties after each task. The browser paints between tasks, so a loop over ten thousand items blocks the screen until it ends. Fixes: do less work, split it into smaller pieces that yield to the browser, show long lists only as they scroll into view, or move heavy work to a web worker, which runs on its own thread.

A weak answer: "JavaScript is asynchronous, so it never blocks." Follow-up: "Does an async function run on another thread?" No. It runs on the same thread; it only pauses while it waits.

Layout and accessibility

How do you build a page layout that works on a small phone and a wide screen?

What they check: responsive design that is planned, not patched.

Short answer: "I start with the small screen and add space and columns as the screen grows. Flexbox lays out items in one row or column; Grid places them in rows and columns at once. I use sizes that adapt instead of fixed pixels, and test with real content."

The full answer: Mobile first keeps the base styles simple. Breakpoints, the widths where the layout changes, follow the content, not popular phone sizes. Grid suits the page frame and card lists; Flexbox suits a toolbar or a row of buttons. Images get several sizes so a phone does not download a desktop picture. Container queries let a component adapt to the space it is given, not the whole screen. Test long words, large text settings and landscape phones.

A weak answer: "I use a CSS framework so it is responsive." Follow-up: "A German product name breaks your card layout. What do you do?" Allow words to wrap, let the card grow, and test with the longest real names, not the design's sample text.

How would you build a custom dropdown that everyone can use?

What they check: accessibility in practice: keyboard, screen readers and focus.

Short answer: "First I check whether the native select element will do, because it is accessible for free. If not, I follow the published pattern for a listbox: it opens and moves with the keyboard, focus is visible and goes back to the button when it closes, and a screen reader hears the name, the state and the chosen option."

The full answer, in five steps:

1. Use a real button to open it, so Enter and Space work and it can be reached with Tab.
2. Name and state. The button says what it chooses and whether the list is open, with ARIA attributes (labels the browser passes to screen readers) only where HTML has no element for it.
3. Keyboard. Arrow keys move through the options, Enter chooses, Escape closes; typing a letter jumps to an option.
4. Focus. Focus moves into the list when it opens and returns to the button when it closes, and is always visible.
5. Test it. With the keyboard only, with a screen reader, and with an automated check; then fix contrast and touch target size.

A weak answer: "I add an aria-label and it is accessible." A label alone does not make a list work with a keyboard.

Follow-up: "Why does it matter beyond good practice?" WCAG, the web's accessibility guidelines, is the standard most laws point to; in the EU, the European Accessibility Act (EU) makes it a legal duty for many shops and services, and US companies face lawsuits.

State, data and components

Where should state live in a React app?

What they check: that you keep state close to where it is used, and tell server data from screen state.

Short answer: "As close as possible to the component that uses it. If two siblings need it, I lift it to their parent. Data from the server goes in a data-fetching cache, not a global store. A global store is for the little that is truly shared, such as the signed-in user."

The full answer: State in ReactAsked in 37% of frontend developer ads (as of 5 Nov 2026).Components, hooks, state and effects; knowing why a component renders, and how to stop it rendering too often. is data that, when it changes, changes the screen. Kinds differ: what is typed in a form, whether a menu is open, what the server sent, what is in the address bar. The address bar is often the best place for filters and tabs, so a link opens the same view. Server data has its own problems, such as caching, refetching and stale results, which libraries such as TanStack Query solve. Context passes values down without props, but every reader renders again when it changes, so it suits values that change rarely.

A weak answer: "I put everything in Redux." Follow-up: "Two tabs show the same list and one edits it. How do they stay in step?" Both read the same cached query, and the edit updates or refetches it.

A component re-renders too often and typing feels slow. How do you fix it?

What they check: that you find the cause with tools, and know what makes React render.

Short answer: "I record it in the profiler to see which components render and why. Usually state sits too high, or a new object or function is created on every render and passed down. I move the state down, or keep those values stable, and only then reach for memo."

The full answer: A component re-renders when its state changes, when its parent re-renders, or when a context it reads changes. A re-render is not always a problem; it becomes one when an expensive tree renders on every key press. Fixes, in order: keep the typing state in the input's own component; split a large context; make long lists render only the rows on screen; then memoise the expensive child so it skips renders when its props are the same.

A weak answer: "I wrap every component in memo." That adds work and hides the cause. Follow-up: "Memo did not help. Why?" A prop is a new object each time, so the comparison always fails.

How do you load data for a screen, with loading, errors and a slow network?

What they check: that you design every state of the screen, not only the happy one.

Short answer: "Every screen that loads data has four states: loading, empty, error and loaded. I design all four with the designer, show a skeleton instead of a jumping spinner, let the user retry an error, and cancel a request the user no longer needs."

The full answer: Agree the shape of the response with the backend, and type it in TypeScriptAsked in 48% of frontend developer ads (as of 5 Nov 2026).Types for props, API responses and state, so mistakes show in the editor before they reach users.. Cache what was loaded so going back is instant. Debounce a search box so it does not send a request for every letter, and ignore an old reply that arrives after a newer one. For a slow or flaky network, show what you already have and say clearly what failed. Some teams use GraphQLAsk the server for exactly the fields a screen needs; used by some product companies instead of REST. so each screen asks for exactly the fields it shows.

A weak answer: "I fetch in an effect and set the state." Follow-up: "The user types fast and the results flicker between old and new. Why?" Replies arrive out of order; cancel the old request or ignore its reply.

What does TypeScript catch for you, and what does it not?

What they check: that you use types as a tool, and know where they stop.

Short answer: "It catches wrong props, missing fields and typos while I write, and makes large changes safe. It does not check what arrives at run time: an API can still send something else, so I check data at the edge of the app."

The full answer: Types disappear when the code is built; the browser runs plain JavaScript. So a response typed as a user can still be an error page. Validate data where it enters, for example with a schema library, and let types flow from there. Turn on strict mode, avoid the any type, which switches checking off, and generate types from the API's description where you can, so frontend and backend agree.

A weak answer: "With TypeScript we do not need tests." Follow-up: "A team wants to move a large JavaScript app to TypeScript. How?" File by file, strict for new code, starting with shared code and API calls.

How do you test a form component so the tests do not break with every design change?

What they check: testing behaviour the user sees, not the inside of a component.

Short answer: "I test what the user does and sees: type in the field labelled email, press send, see the error message. I find elements by their label or role, not by a class name, so a new design does not break the test, but a broken form does."

The full answer: Most frontend tests should be component tests of this kind, which run fast and also check that labels exist, so they help accessibility. A small number of end-to-end tests run the real app in a browser for flows that must never break, such as sign-up and payment. Visual tests compare screenshots for shared components. Snapshot tests of the markup break with every change and are usually approved without a look.

A weak answer: "I check that the component's state is set." Follow-up: "An end-to-end test fails one run in ten. What do you do?" Find out why, usually waiting for a fixed time instead of for the element; never just run it again until it passes.

Security in the browser

How do you protect a web app from cross-site scripting, and where do you keep a login token?

What they check: that you know the main frontend risk and do not create it yourself.

Short answer: "Cross-site scripting, XSS, is when an attacker's script runs in your page, usually through text a user entered. Frameworks escape text by default, so I never insert raw HTML from users. I add a Content Security Policy. A login is safest in a cookie the script cannot read, not in local storage."

The full answer: XSS lets the attacker act as the user: read their data, send requests in their name. The danger points are the few places that insert HTML directly, links built from user input, and third-party scripts. A Content Security Policy tells the browser which scripts may run. An HttpOnly cookie cannot be read by any script, so an XSS cannot steal it; with cookies, the backend also needs protection against forged requests from other sites (CSRF).

A weak answer: "The backend handles security." Follow-up: "Marketing wants to paste HTML from an editor into the page. What do you do?" Clean it with a well-tested sanitiser that keeps only safe tags, on the server as well.

Senior, staff and architect questions

How do you work with designers on a screen that the design system does not cover?

What they check: for senior roles, working with design as a partner, and protecting consistency.

Short answer: "I talk to the designer early, before it is built. Often an existing component with a new variant does the job. If it is truly new, we design it once, for every state, and add it to the design system so the next team does not build it again."

The full answer: A design system is the shared set of components, design tokens (named colours, spacing and type sizes) and rules that keeps a product consistent. One-off components drift: different spacing, missing focus states, no dark mode. Ask what problem the new design solves; review the FigmaRead a design file: spacing, tokens, states and variants, and spot what the design forgot. file for states the mock-up forgot (empty, error, long text, keyboard focus); and agree who owns the new component.

A weak answer: "I build exactly what the design shows." Follow-up: "The deadline is tomorrow." Build it with existing parts now, note the gap, and plan the proper component.

How would you build a design system that several product teams use?

What they check: for lead and staff roles, thinking in platforms and in people who adopt them.

Short answer: "Start from the components teams already copy between them, build them once with designers, accessible and documented, and publish them as a versioned package. Adoption is the hard part, so I make the shared component the easiest choice."

The full answer: Begin with tokens and the ten components every screen uses: buttons, inputs, dialogs, tables. Build them with accessibility tested in, document each with examples, and version the package so teams upgrade when they choose, with clear notes on what changed. Measure use across products. Give teams a way to ask for changes, and a small core team that answers fast. A design system nobody uses is a cost; one everybody uses saves weeks per screen.

A weak answer: "I would build a full component library first and then launch it." Follow-up: "A team says the system slows them down." Find the component that blocks them, and fix or extend it quickly, or let them build it inside the system with a review.

Several teams work in one large frontend app, and builds and releases are slow. Would you split it into micro-frontends?

What they check: for staff and frontend architect roles, weighing a big change honestly.

Short answer: "Only if the problem is teams blocking each other's releases, and cheaper fixes have failed. Micro-frontends let each team build and release its own part of the page, but they cost speed, consistency and tooling. I would first try clear module boundaries, faster builds and ownership rules in one repository."

The full answer: A micro-frontend is a part of the product, such as checkout or account settings, built and deployed by one team on its own. The gains are team independence and smaller releases. The costs: the same library loaded twice, different versions of shared components, harder end-to-end testing, and more for the user's phone to download. Measure first: build time, how often teams wait for each other, release frequency. If you split, split by business area, share the design system and one version of the framework, and keep a single shell for routing.

A weak answer: "Yes, micro-frontends are the modern way." Follow-up: "Leadership wants it done this year." Move one area first, measure page speed and release time, and decide on the rest from that.

How do you move a large app from an old framework to a new one without stopping feature work?

What they check: for lead, staff and frontend architect roles, planning a long change with low risk.

Short answer: "Screen by screen, not in one rewrite. Old and new run side by side; new screens are built in the new framework, and old ones move when they need changing anyway. I track progress and set a date to remove the old framework."

The full answer: A big rewrite stops the business for months and usually ships late. The strangler approach puts a thin shell around the app that sends each route to the old or the new code. Move shared parts first: the design system, API calls, sign-in. Agree with the product manager which screens move with planned feature work, so the move pays for itself. Watch page speed, because two frameworks at once add weight, and keep the time with both short. A team moving from AngularJS to AngularAsked in 41% of frontend developer ads (as of 5 Nov 2026).Common at banks, insurers and large companies: modules, services, RxJS streams and strict structure., or from an old jQuery app to ReactAsked in 37% of frontend developer ads (as of 5 Nov 2026).Components, hooks, state and effects; knowing why a component renders, and how to stop it rendering too often., follows the same plan.

A weak answer: "We freeze features for six months and rewrite." Follow-up: "How do you convince the engineering manager to fund it?" Show the cost of staying: hiring, security updates that have stopped, and how long features take today.

Your CV for these questions

Interviewers ask about what your CV says, so put the work behind these answers on it, one line per result, in the words the ads use:

Then score your CV against a real frontend job: the result shows which of these screens and measurements the job asks for, and which your CV leaves unproved.