Use these questions to interview Frontend Engineer candidates at {{Company name}}. Pair the fundamentals and UI implementation groups with a live coding session — building a small interactive component reveals more than any amount of discussion. Let candidates use their preferred framework and normal tooling; you are hiring for how they think, not what they memorized.

JavaScript, TypeScript, and framework fundamentals

• Walk me through how you decide what state lives where in a component tree. Use a real feature you built.
• Explain a nasty bug you hit with asynchronous code — races, stale closures, cancelled requests. How did you fix it?
• How do you type a component API in TypeScript so misuse fails at compile time? Show me a real example.
• What does your framework actually do when state changes? Walk me through the update cycle.
• Tell me about a time you worked outside the framework — direct DOM, web APIs, workers. Why was it necessary?
• Live exercise: build a debounced autocomplete with keyboard navigation and loading states.

What good looks like: strong candidates reason about state ownership and data flow before reaching for tools, explain the framework's rendering model in their own words, and handle the async edge cases in the live exercise — out-of-order responses, rapid input, unmount during fetch — without prompting. Framework vocabulary without a mental model underneath is the most common false positive in frontend hiring.

UI implementation and CSS

• How do you structure CSS on a large project — methodology, tokens, and what you do when it breaks down?
• Live exercise: implement this design accurately, including the responsive behavior between breakpoints.
• Tell me about the most complex layout you have built. What made it hard?
• How do you handle a design that looks great in the mock but breaks with real content — long names, empty lists, RTL?
• What is your approach to animation — when to use CSS, when JavaScript, and when nothing?
• How do you keep visual consistency across a codebase touched by many engineers?

Performance

• Walk me through a real performance problem you fixed. How did you measure before and after?
• What actually makes a page feel slow to a user? Which metrics do you watch, and which do you ignore?
• How do you keep a bundle from growing indefinitely? What have you actually removed or split?
• Tell me about optimizing a long list or a data-heavy view. What techniques did you use?
• When did you last profile rendering performance, and what did you find?

What good looks like: the best answers start with measurement — a profiler trace, a specific metric, a number before and after — and connect performance to user experience rather than lab scores. Candidates who only recite optimization techniques without a story of applying one under real constraints are describing blog posts, not experience.

Accessibility and quality

• Walk me through making a complex component accessible — a modal, a combobox, a data table. What did keyboard and screen-reader support require?
• What accessibility checks are part of your normal workflow, not a special audit?
• Tell me about an accessibility bug that shipped. How was it found, and what changed?
• How do you decide what to test on the frontend, and at what level — unit, component, end to end?
• Tell me about a flaky test you fixed properly instead of deleting.

Collaboration with design and product

• What do you do when the design mock is missing states — errors, loading, empty, overflow?
• Tell me about pushing back on a design that would be disproportionately expensive to build. How did the conversation go?
• How do you review another engineer's frontend PR — what do you look at first?
• Describe working within a design system: contributing, consuming, and when you broke from it.