Front End Developer Interview Questions for Hiring Managers

Open a commercial property search on a three-year-old Android phone, tab through its filter panel without a mouse, and change two filters faster than the API can answer. Those three actions test more of a front end developer’s skill than any definition of a closure, and they are where weak front end work shows up first for real users. The most useful front end developer interview questions ask candidates to reason through moments like these.

The 14 questions below use one example product throughout: a listing site for commercial real estate with a map, a filter panel, listing pages with photo galleries and an inquiry form that goes to the listing broker. Every question comes with notes on the points a capable front end developer usually raises. Use them as a basis for discussion rather than an answer key, because a candidate who argues for a different approach and explains it clearly may know your stack better than the notes do. A conversation shows how someone reasons about the interface; shipping on your product is where you learn how they build it.

Do You Need a Front End Specialist?

Decide this before writing the interview. One strong full-stack engineer often delivers more than a front end and back end pair, because every feature that crosses the API needs coordination between two people, as our comparison of backend and frontend developers explains. A dedicated front end developer earns the role when the interface itself carries distinct depth: a design system used across several products, demanding accessibility requirements, heavy data visualization or complex client-side state. Traffic and user counts are not, by themselves, a reason to split the role.

If the role is specialist work, weight the interview toward the groups below that match that depth. If it is general product work, use a subset here alongside backend questions.

Semantics and Accessibility Questions

Accessible markup is the foundation everything else sits on, and it is cheaper to get right in the first version than to retrofit.

1. How Would You Build the Filter Panel’s Property-Type Selector?

Good candidates start with native elements: a group of checkboxes inside a fieldset with a legend, or a select element, styled to the design. They reach for a custom widget only when the design needs behavior native controls cannot provide, and then they describe the keyboard behavior and ARIA roles that pattern requires.

Follow up by asking what ARIA adds to a div with a click handler. A precise answer says roles and states change what assistive technology announces but add no keyboard behavior, so the developer still has to build focus handling and key support.

2. What Has to Happen When the Inquiry Form Opens in a Modal?

Focus should move into the dialog, stay inside it while it is open, close on Escape and return to the button that opened it. A modal dialog element opened with showModal() provides much of this: it makes the rest of the page inert, closes on Escape and returns focus to the opening element when it closes. Source: web.dev, Learn HTML: Dialog

Then ask about the form inside it. Visible labels, error messages connected to their fields and a confirmation that screen readers announce are the details candidates with real accessibility experience mention without prompting.

3. Which WCAG 2.2 Changes Would Affect This Site?

WCAG 2.2 became a W3C Recommendation in October 2023 and added nine success criteria. Source: W3C, What’s New in WCAG 2.2 Several apply directly to a map-based search. Map zoom buttons and pin targets fall under Target Size (Minimum), which sets 24 by 24 CSS pixels with listed exceptions. A sticky header or cookie banner can hide a focused element, which Focus Not Obscured addresses. Panning the map by dragging needs a single-pointer alternative under Dragging Movements.

A candidate does not need to recite criterion numbers. Look for someone who can connect the guideline to a specific component and explain how they would test it, including a manual keyboard pass, since automated checkers find only part of the problem.

Rendering and Performance Questions

Performance questions should start from what the user feels and end with a measurement, not a list of optimization tricks.

4. Typing in the Search Box Feels Slow on Mid-Range Phones. How Do You Find Out Why?

This is an Interaction to Next Paint problem. INP breaks an interaction into input delay, processing time and presentation delay, and a good score is 200 milliseconds or less at the 75th percentile of page loads. Source: web.dev, Interaction to Next Paint A strong candidate profiles with CPU throttling, looks for long tasks on the main thread, and checks whether each keystroke re-renders the whole results list.

Fixes depend on the cause: rendering less on each keystroke, deferring the expensive filtering, yielding to the main thread, or moving work into a web worker. Debouncing the network request is reasonable, but it does not help if the slowness is rendering, and a candidate should say so.

5. The Map Needs to Show 20,000 Listings. What Do You Do?

Rendering 20,000 markers as DOM elements tends to overwhelm mid-range devices. Reasonable answers combine clustering at low zoom levels, drawing pins on a canvas or WebGL layer instead of as elements, and fetching listings by the visible map bounds rather than all at once. For larger datasets, aggregation on the server or vector tiles move the heavy work off the device.

That last option is not theoretical. For a geospatial research platform where a data visualization took 10 to 15 seconds to load a single view, we engineered a custom vector tile format to allow real-time filtering of millions of aviation waypoints.

6. Listing Photos Push the Page Around as They Load. What’s Wrong?

The images have no reserved space, so content shifts when each one arrives. Setting width and height attributes or a CSS aspect ratio lets the browser reserve the box before the file loads. Ask about the main listing photo as a follow-up: lazy-loading it delays the largest element on the page, while lazy-loading gallery images further down is sensible.

State and Data Questions

Most front end defects that reach users come from state that is in the wrong place or out of date.

7. Where Should the Search Filter State Live?

A strong answer puts the active filters in the URL. That makes searches shareable, keeps the back button working and survives a reload, which matters to brokers who send searches to clients. Transient interface state, such as whether a dropdown is open, stays local to the component, and server responses live in a data-fetching cache.

Putting everything into one global store is the answer to probe. It works, but it hides which state the URL should own and tends to grow until every change touches it.

8. Two Filter Changes Return Out of Order. What Does the User See?

If the slower, older request finishes last, its results overwrite the newer ones, and the user sees listings that do not match the filters on screen. Good answers cancel the previous request with an AbortController, or tag each request and ignore any response that is not for the latest one. Candidates should note that debouncing makes the race less frequent without removing it.

9. When Is an Optimistic Update the Wrong Choice?

Saving a listing to a shortlist is a good candidate for an optimistic update: the heart fills immediately and rolls back with a message if the server rejects it. Sending an inquiry to a broker is not. The user should see success only after the server confirms the inquiry was stored, because a false confirmation means a lead that nobody follows up. The candidate should frame the choice around the cost of being wrong.

Component and Design System Questions

These questions matter most when the engineer will own shared components that other developers build on.

10. A Designer Hands You a New Listing Card Variant. Do You Build a New Component or Extend One?

Look for a conversation before code: is this a new pattern, or a variation the existing card should support through its props and design tokens? Good candidates resist forking a component for a small visual change, since forks drift apart and every fix then needs making twice.

Duplication builds up faster than teams expect, especially with AI-assisted generation. In one Web3 product’s codebase, we found dozens of distinct but functionally identical components where one was needed, and we introduced rules and prompting guidelines so generated code followed a standardized component library.

11. How Do You Keep Styles From Leaking Across a Large App?

Any consistent scoping approach can work: CSS modules, a naming convention, cascade layers or utility classes. The signal is whether the candidate can explain the failure they are preventing, such as a broker dashboard style that breaks the public listing page, and how they would stop specificity escalating until every rule needs an override.

Browser Security and Resilience Questions

Front end code runs on hardware and networks you do not control, so it has to fail safely.

12. Brokers Write Listing Descriptions in a Rich Text Editor. How Do You Display Them Safely?

Rendering broker-supplied HTML directly is a cross-site scripting risk. A good answer sanitizes against an allowlist of tags and attributes on the server, keeps sanitization at render time as well, avoids raw HTML insertion in components, and adds a Content Security Policy as a second layer. Sanitizing only in the browser before submission is a weak answer, because anyone can call the API directly.

13. The Price-History Widget’s API Fails. What Should the Page Do?

The rest of the listing page should still work. Look for failure isolated to the widget, with an error boundary or equivalent, a short message and a retry, rather than a blank page. Then ask how they would know it happened: client-side error reporting tagged with the release, route and browser is the usual answer.

14. What Would You Test in This Front End, and How?

A balanced answer covers component tests for filter logic that query elements by role and label, a small number of end-to-end tests for the path from search to inquiry, visual regression checks for card variants, and automated accessibility checks backed by a manual keyboard and screen reader pass. A suite made entirely of snapshot tests is the pattern to question, since it records output without saying what should be true.

A Practical Assessment: Audit a Real Page

Give the candidate a staging copy of one page, such as a listing page with a few planted problems, and 30 to 45 minutes with the browser’s developer tools. Plant a clickable div with no keyboard support, an unlabeled input, a hero image without dimensions and a filter request that can return out of order. Ask for a ranked list of what they would fix and why.

This format resembles the job: most front end work starts in an existing interface with existing problems. Ranking shows judgment, and a candidate who puts accessibility and correctness above cosmetic issues is showing priorities you can rely on. For framework-specific depth, our React interview questions work as a separate round.

How Should Mid-Level and Senior Answers Differ?

Use the same questions at both levels and change the expectation. Treat the table as a way to organize what you heard, not as a forecast of how someone will perform.

Area	Mid-level evidence	Senior evidence
Accessibility	Uses native elements, labels forms	Designs keyboard patterns, tests with assistive technology
Performance	Fixes layout shift and obvious slow renders	Diagnoses INP from profiles on low-end devices
State	Keeps state local and correct	Decides what the URL, cache and components own
Components	Builds to the design system	Shapes the design system and prevents drift
Security	Avoids raw HTML insertion	Sets sanitization and policy for the whole app
Resilience	Handles errors in the component	Isolates failures and instruments the client

Red Flags in Front End Interviews

Ask a follow-up when a candidate builds controls from divs without mentioning keyboard support, treats ARIA as a fix for missing semantics, proposes debouncing as the answer to every performance question, stores filters only in memory, or trusts client-side sanitization. A candidate who has never tested on a slower device or with a screen reader may still be strong, but should be able to say how they would start.

One gap deserves a question, not a rejection. Repeated gaps in the area the role exists for are the real signal.

How Gun.io Approaches Front End Hiring

At Gun.io, we start with the interface problem rather than the title. If the work is general product development, we usually look for a strong full-stack engineer who can carry a feature from the API to the screen. When the interface needs its own depth, such as a shared design system, accessibility requirements or a data-heavy map, a front end specialist is the right call, and we look for evidence of that depth in the engineer’s actual work. AI tools make ordinary components and design-to-code faster to produce; design taste, UX judgment and accessibility remain the parts of front end work that separate engineers.

Engineers we work with are assessed by people, in interviews that cover technical capability and professional fit, and that assessment keeps going once an engagement is under way, since the client’s product is where the real evidence appears. The same thinking shapes how we place JavaScript and front end engineers, whether they join a client’s existing team or take ownership of a scoped interface build.

Frequently Asked Questions

Should I Ask Framework-Specific Questions in a Front End Interview?

Yes, in proportion to how much of the role depends on that framework. Frameworks change faster than browsers do, so keep most of the weight on HTML semantics, rendering, state and accessibility, which carry across React, Angular, Vue and whatever comes next.

Can a Back End Developer Handle Front End Work?

Many experienced engineers can, and a full-stack engineer often should. The gaps usually show in accessibility, browser performance on real devices and design judgment, so ask the same accessibility and performance questions you would ask a specialist rather than assuming either way.

How Do I Evaluate Design Sense in a Front End Developer?

Show the candidate a design with a missing state, such as no empty state for a search with zero results or no handling for a very long property name, and see what they notice and ask. Developers with good design sense find the gaps a static mockup cannot show.

What Should a Junior Front End Developer Know?

Semantic HTML, CSS layout with flexbox and grid, fetching data and handling its loading and error states, and debugging in browser developer tools. Junior candidates who build an accessible form correctly and explain what they would check next are showing the right foundation.

Does AI Change What to Ask a Front End Developer?

It shifts the weight. Assistants generate components and convert designs to code quickly, so spend less interview time on producing markup and more on reviewing it: accessibility, state placement, performance on slow devices and whether a generated component duplicates one you already have.

Do I Need a Separate Accessibility Specialist?

Most products need front end developers who handle accessibility as part of normal work, which is why it belongs in every front end interview. Products with complex interactive components or strict accessibility obligations may also need someone whose depth is accessibility itself.

Hire for the Parts of the Interface Users Feel

Ask questions that put the candidate on a slow phone, a keyboard and a flaky network, and treat their performance on your product as the evidence that settles the decision. If a front end hire is on your roadmap, walk us through the interface you need built, including the screens that matter most, the devices your users carry and who owns the design system.