Skip to content
How it worksUse casesIntegrationsPricingFAQBlog
Try it free
Blog/Frontend Developer Interview Questions for Hiring Teams

Frontend Developer Interview Questions for Hiring Teams

Frontend developer interview questions for hiring teams: 15 questions with follow-ups, strong and weak answers, and how to run them at volume.

9 Nov 20269 min readFacts checked 9 Nov 2026
Contents
Fifteen frontend developer interview questions, grouped by what they testA strong answer measures first, and a weak one names a toolOne follow-up chain shows where the real answer startsRun the interview for every applicant without losing the follow-upKeep four checks with peopleQuestionsSources
Try Tracy on your own role.First 3 results free.Try it free (opens in a new tab)

TLDR Tracy AI Interviewer interviews every frontend applicant on browser and performance trade-offs and follows up on each answer, so your engineers read how candidates reason, not a list of frameworks.

Use the 15 frontend developer interview questions below, grouped by what they test, each with a follow-up and what to listen for.

A recording, a timestamped transcript and a written assessment per question sit behind every result, and your team decides.

Next step: paste five of these questions into a Tracy interview.

We make Tracy AI Interviewer.

A frontend opening draws a hundred applicants whose CVs list React, TypeScript and "performance optimisation". Two of your engineers can interview them between sprints. The CV says which tools someone has touched. It does not say whether they would measure a slow page before rewriting it. Frontend developer interview questions have to test that gap.

These are written for the hiring manager or lead who runs the interview. They ask for judgement about browsers, state, accessibility and delivery, and each one has a follow-up and a note on what a strong answer contains. They suit mid-level and senior roles; for a five-year candidate, ask the follow-up every time. Candidates can use them to prepare too.

Tracy AI Interviewer runs the part that does not scale. She asks each applicant in their own field, follows up on what they just said and waits for the end of the thought, with a coding task inside the same interview when you want one. For the wider engineering version, see software engineer interview questions, and for the process, technical interviews.

Fifteen frontend developer interview questions, grouped by what they test

For each group, pick one or two questions. Ask the follow-up only after the first answer, and write down what a strong answer contains before the first candidate joins. Questions about experience should be answered with a real project, so ask for the project.

Group 1: browsers and performance

AskFollow up withListen for
1. A page feels slow on a mid-range phone. Where do you start?What would you measure before changing anything?Measures first with a profiler trace or field data, and separates network from main-thread time. Names a finding, not a tool list.
2. What happens between typing a URL and seeing a page?Which step have you actually made faster?The order is roughly right and the depth sits where they have worked: caching, render-blocking resources, hydration.
3. A list of 5,000 rows scrolls badly. What are your options?What does each option cost you?Virtualisation, pagination, memoisation. Names the costs: find-in-page, screen readers, scroll position.

Group 2: JavaScript and state

AskFollow up withListen for
4. Describe a bug you caused with closures, async code or stale state.How did you reproduce it?A real case with reproduction steps, the fix and a test added afterwards.
5. Where should state live in an app you own?When did you last move it, and why?Local, shared and server state kept apart. Avoids "put everything in a store".
6. Two requests return out of order and the screen shows old data. What now?How would you test that?Cancels or ignores the stale response, uses request identifiers, tests with delayed mocks.

Group 3: CSS and accessibility

AskFollow up withListen for
7. How do you build a modal that works with a keyboard and a screen reader?What breaks first in a custom one?Focus moves in and returns, a label, Escape closes it. Prefers the native element where it fits.
8. A layout breaks at one width only. How do you find out why?What stops it coming back?Reads computed styles, prefers flexible sizing to more breakpoints, adds a visual or component test.
9. When do you reach for JavaScript instead of CSS?A time you removed script for CSS?A concrete case. Knows what CSS now does alone and what still needs script.

Group 4: frameworks and tooling

AskFollow up withListen for
10. Which framework feature do you avoid, and why?When did avoiding it cost you?A reasoned rule with an exception, not a taste.
11. How do you decide whether a dependency is worth adding?What did you last remove?Bundle size, maintenance, licence and the alternative of writing ten lines.
12. What should a component test cover?What do you leave untested?Behaviour a user sees, not implementation details. Names what is too costly to test.

Group 5: working with others

AskFollow up withListen for
13. A design cannot be built as drawn. What do you do?How do you tell the designer?Proposes an option with a trade-off and says it early, with a screenshot or a prototype.
14. You review a pull request with 900 changed lines. How?What do you ask the author to do?Asks to split it, reads tests first, comments on risk before style.
15. Tell me about something you shipped and later regretted.What would have caught it earlier?Owns the decision, names the missed signal, describes a check they now run.

Table 1. The 15 questions, each with a follow-up and what to listen for (written by us).

A strong answer measures first, and a weak one names a tool

The difference shows up in the second answer. These pairs are written by us as examples of how it sounds, not quotes from real candidates.

Weak answerStrong answer
Question 1, the slow page"I would add lazy loading and memoise everything.""I would record a trace on a mid-range phone first. If the main thread is busy I look at scripts, if not at the network."
Question 6, out-of-order requests"I would add a loading spinner.""The old response arrives last and overwrites the new one. I would cancel the old request and test it with a delayed mock."
Question 7, the modal"I would use a library for it.""Focus goes in, comes back to the button, Escape closes it. I would check it with the keyboard before calling it done."

Table 2. Example weak and strong answers (illustrative, not from real candidates).

Listen for ownership. "We used a library" tells you about the team. "I tested it with the keyboard and found the focus bug" tells you about the person.

One follow-up chain shows where the real answer starts

This is an illustration with sample data, not a real interview. The candidate is fictional. It shows the shape of what Tracy runs: an opening question from your list, the answer, and a follow-up built on it. It starts from question 1.

Tracy: A page feels slow on a mid-range phone. Where do you start?

Candidate (fictional): With a trace on the phone. I want to know if it is the network or the main thread.

Tracy: The trace shows the main thread busy for two seconds. What do you look at next?

Candidate: The longest tasks. Last time it was a date library parsed on load, so I split it out and measured again. The first paint moved by a second.

Tracy: What did you do to keep it from coming back?

Candidate: A budget on the bundle in the build, so a pull request fails if it grows.

The first answer is the textbook one. The fourth shows whether it ever happened. Roy Junyoung Jang, Director, Residency & Investment at Antler Korea, says Tracy "sometimes brings up exactly those questions I might have forgotten to ask, which has been a pleasant surprise."

Transcript card: slow page on a phone, candidate says trace first, Tracy asks what they look at next.
Capability: Tracy asks a follow-up built on the candidate's own answer. Value: your engineers see whether the work was done, not recited. Illustration with fictional data, not a real interview. Illustration with fictional sample content.

A follow-up built on the candidate's own answer shows whether they have done the work.

Run the interview for every applicant without losing the follow-up

A live call for every applicant does not survive a hundred of them.

  • Questions from the role. Paste the frontend job description and Tracy drafts questions on browsers, state and accessibility that you edit or replace with your own. See the product page.
  • A coding or debugging task. It sits in the same interview, with follow-ups on approach and trade-offs, for example why a search box should wait before it calls the server.
  • CV check, as a setting. With it on, Tracy can read the CV and ask about what it claims, so "performance optimisation" becomes a question about the trace, the bundle or the budget. See how the CV check works.
  • No scheduling. Each candidate opens a link, with no account, and is told on the join screen that the conversation is recorded and transcribed. See the participant experience.
  • Evidence per result. A recording, a timestamped transcript and a written assessment per question, so your engineer can check a keyboard-focus answer against what was said. See AI interview reports.

Pricing is $1 per credit, one credit per started 20 minutes of an interview that produced a result, so a 34-minute interview costs $2. The first 3 results are free with no card, there are no seats, and a session with no answers is never charged. See pricing. Send us one role and we will build the interview plan in days.

Recreated Tracy result for a fictional frontend candidate: four assessments, the 04:58 question highlighted.
Capability: a recording and timestamped transcript sit behind every Tracy result. Value: your engineer checks the evidence before deciding. Illustration, not a screenshot, with fictional data. Illustration with fictional sample content.

A reviewer can open the recording and transcript behind each assessment.

Keep four checks with people

  1. Your own engineer. Have one score five or six transcripts blind. If they disagree with the written assessments, fix the questions before inviting the next hundred.
  2. The component. Tracy asks why the candidate built it that way and what it costs. Whether it meets your standard is a reviewer's call.
  3. Integrity signals. Tracy captures tab changes, gaze, face detection, delay before answers, fullscreen exits and external screens, and shows the evidence to a person. A signal is not proof. See AI interview cheating detection.
  4. The decision. A person decides from the evidence.

For ten applicants, a call with one of your engineers is a reasonable choice; see AI interview vs human interview. When a hundred apply, interview hours are the limit. Run one open frontend role and read the recording and report for three applicants before you widen it.

Questions

What are good frontend developer interview questions?
Ask about measuring a slow page, where state lives, keyboard and screen-reader behaviour, dependencies and how they review code. Keep the follow-up beside each, and ask for a real project.
What are frontend developer interview questions for 5 years of experience?
Ask the follow-ups every time. A five-year developer should name a project, the measurement, the fix and what they changed afterwards. Questions 1, 5, 10 and 14 separate that depth from a listed skill.
How do you test frontend skills without a take-home?
Put a short coding or debugging task inside the interview and ask about approach and trade-offs. Tracy can run that task in the same interview, with follow-ups on the candidate's own reasoning.
Can an AI interviewer interview frontend developers?
Yes. Tracy asks questions in the candidate's field, follows up on what they said and waits for the answer. Your team gets the recording, transcript and an assessment per question, and a person decides.

Create a Tracy interview for this exact role from these questions, then read the recording and report; the button opens the Connect page. Or send us one role and we will build the interview plan, with a recording and report you can check. Try it free · Book a demo

Sources

  • Tracy AI Interviewer home page, customer proof, retrieved 9 Nov 2026.
  • Tracy AI Interviewer pricing, retrieved 9 Nov 2026.
  • Tracy AI Interviewer Connect page, retrieved 9 Nov 2026.
Start today

Let Tracy take the next interview.

Run your first 3 interviews free, or book a demo and watch Tracy work through your own questions.

Try it free (opens in a new tab)Book a demo (opens in a new tab)

Your first 3 results are free. No card needed.

Tracy AI Interviewer

Video interviews that follow up in the person's own field, with evidence behind every result.

Try it free (opens in a new tab)

Product

  • How it works
  • Integrity signals
  • API and MCP
  • Pricing

Use cases

  • Expert vetting
  • Applications
  • Hiring at volume
  • Technical interviews
  • Customer research
  • People teams

Resources

  • Blog
  • Compare
  • Tracy vs HeyMilo
  • Book a demo (opens in a new tab)
  • Help
  • Support

Legal

  • Privacy policy
  • Terms of use
Your expert interviewer.
© 2026 Tracy AI Interviewer. All rights reserved.