Skip to content
Aethel

AI interview prep for frontend developers

Frontend interviews test more than components. An AI screen will ask why a page got slow, how state got out of hand, what broke for keyboard and screen reader users, and what happened when a design met real content. Here are the questions to expect, two worked answers, the habits that weaken frontend answers, and free practice at your level.

Practice frontend questions free

Entrevista con IA para desarrolladores frontend: esta guía en español

What AI screens ask frontend developers

  1. Performance users could feel

    “Tell me about a page or app that felt slow. How did you measure it, and what did you change?”

    Listening for: A real metric (Largest Contentful Paint, Interaction to Next Paint, bundle size) measured on real devices, the cause, and the change that followed from it.

  2. State that got out of hand

    “Describe a time state management in your app became hard to reason about. What did you do?”

    Listening for: The bug or confusion it caused, the options you weighed (lifting state, a store, caching server data), and why you picked one.

  3. Accessibility

    “Tell me about an accessibility problem you found and fixed.”

    Listening for: Who was affected, how you found it (an audit, a screen reader, a user report), the fix, and how you kept it from coming back.

  4. Design meeting real content

    “A design looked right in the mockup but broke with real data. What happened?”

    Listening for: Long names, translations, empty states, slow networks, and how you and the designer settled it.

  5. One browser, one device

    “Describe a bug that only happened in one browser or on one device.”

    Listening for: How you reproduced it, the root cause, and how you tested the fix across devices.

  6. Testing a user interface

    “How do you decide what to test in a user interface?”

    Listening for: A case where a test caught something real, and the balance you chose between unit, integration and end-to-end tests.

  7. Shipping a big change

    “How did you roll out a large UI change without breaking things for users?”

    Listening for: Feature flags, a gradual rollout, the metrics you watched, and the plan if they went the wrong way.

Worked example: a slow product page

Each example shows a weak and a strong answer to the same question. The “With Aethel's rules” lines apply Aethel's published scoring rules, one concrete example of how an AI interview can judge an answer.

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “Tell me about a page that felt slow. How did you measure it, and what did you change?”

Weak answer

“Our app was kind of slow, so I optimized it. I used memoization and lazy loading and made the bundle smaller, and our Lighthouse score went up a lot. Performance is really important to me and I always keep it in mind when I build things.”

Why it is weak: No page, no users, no starting point. Three techniques are listed with no link to a cause, and a lab score from a developer laptop says little about what users felt. "Went up a lot" is not a result an interviewer can weigh.

With Aethel's rules: Situation 0, reasoning 0, result 1: 1 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“I worked on the product page of an online furniture store, about 400,000 visits a month, most of them on mid-range Android phones. Field data showed Largest Contentful Paint at about 4.8 seconds on mobile, and mobile conversion was half the desktop rate. A performance trace showed the main product image was requested only after 600 kilobytes of JavaScript for a 3D room viewer had loaded and run, although fewer than 5 percent of visitors opened the viewer. I moved the viewer behind a click and loaded it on demand, served the main image in a modern format at the right size for each screen, and preloaded it. I considered rendering the whole page on the server instead, but our product data came from a client-side API and that change would have taken a quarter. Over the next month, mobile LCP at the 75th percentile dropped to about 2.1 seconds, and mobile add-to-cart rose by about 9 percent, which our analytics team confirmed in an A/B test.”

Why it is strong: It names the page, the traffic and the devices, uses field data instead of a lab score, and traces the delay to one cause. The fix follows from the cause, an alternative is weighed with a reason, and the result is measured on users, with a business number someone else confirmed.

With Aethel's rules: Situation 2, reasoning 2, result 2: 6 of 8 points, which is 87 on Aethel's fixed scale. A real score can differ.

What comes next: Expect: how did you keep the 3D viewer fast for the people who did open it? Loading it while the browser is idle, or when the pointer approaches the button, is one answer worth having.

Worked example: a form screen reader users could not finish

Made-up exampleWritten by Aethel to show the difference. Not a real candidate, and not scored by the AI.

Question: “Tell me about an accessibility problem you found and fixed.”

Weak answer

“Accessibility is something I care a lot about. I always use semantic HTML and add alt text to images, and I run Lighthouse to check the accessibility score. On my last project we got the score to 100.”

Why it is weak: Good habits, but no problem and no person affected. An automated score of 100 does not mean a screen reader user can finish the task, and an interviewer will often ask exactly that.

With Aethel's rules: Situation 0, reasoning 0, result 1: 1 of 8 points, and with no specific case the area is at most 60 on Aethel's scale.

Strong answer

“At a health insurer I worked on the online claim form, used by about 15,000 members a month. A member who is blind wrote to support that she could not submit a claim, so I tested the form with VoiceOver and NVDA myself. The date picker was a custom grid that a screen reader could not enter, and validation errors appeared as red text that nothing announced. I replaced the date picker with three labeled fields for day, month and year instead of patching the grid, because the grid would still have been slow for keyboard users and gave no benefit for a date of birth. I tied each error to its field and moved focus to a summary of errors on submit. Then I added an automated accessibility check to the form's end-to-end tests and wrote a short checklist for the team's pull requests. The member submitted her claim the next week, the form passed our monthly screen reader audit from then on, and support tickets about it fell from about 30 a month to 4.”

Why it is strong: It starts from a real user and a real task, shows the problem was reproduced with actual assistive technology, and explains a design choice (replace rather than patch) with its reason. The result covers the person who reported it, the numbers after, and how the fix was kept from regressing.

With Aethel's rules: Situation 2, reasoning 2, result 3: 7 of 8 points, which is 91 on Aethel's fixed scale. A real score can differ.

What comes next: A natural next question: how did you decide what the error summary says, and in what order? Having listened to it with a screen reader is the detail that makes this answer credible.

Common mistakes in frontend answers

  • Quoting a lab score as the result. A Lighthouse score from your laptop is a starting point. Interviewers trust field data from real users: LCP, INP, error rates, conversion.
  • Listing hooks and libraries. Naming memoization, a state library or a new framework is not a reason. Say what problem it solved and what you gave up.
  • Treating accessibility as alt text. Talk about a task a real person could not finish, how you tested it with a keyboard or a screen reader, and what changed.
  • Leaving out the designer and the user. Frontend work is shared with design and product. An answer with no conversation in it misses the collaboration part of the question.
  • No rollout story. Big UI changes need flags, staged releases and metrics to watch. Say how you would have known the change was hurting users.
  • Thinking only in desktop terms. If most of your users are on phones, say so, and say which devices and networks you tested on.

Numbers worth having ready

An interviewer places a case by its numbers. Find these for each of your cases before a frontend interview; rounded is fine:

  • LCP, INP and CLS at the 75th percentile, from field data if you have it
  • JavaScript bundle size before and after, in kilobytes
  • The share of users on mobile, and the slowest devices or networks you supported
  • Error rate from your front-end monitoring
  • Conversion, task completion or support tickets tied to the page
  • How many screens, components or teams shared the code you changed

Practice frontend questions free

Pick a level, type an answer to each question, and read the quick check after each one. Free, no account, nothing saved, and not a score.

Questions from frontend developers

Will an AI interviewer ask me to build a component live?

Some screening tools include a coding task, so ask beforehand. Aethel's interview does not: you talk through components and pages you built, and why you built them that way.

How do I talk about design work without showing it?

Describe it in words: what the screen does, who uses it, what changed and why. Name the constraint that shaped it, such as a very long product name or a slow network. The interviewer cannot see your screen, so the constraint does the work a screenshot would.

I mostly build internal tools. Is that strong enough?

Yes, if you can place it: how many employees used it, what task it sped up, and how you measured that. Internal users are real users, and they are easier to ask what changed.

Should I talk about CSS problems or only JavaScript?

Either. A layout that broke with right-to-left text, or a design system change that touched 200 screens, can be stronger than a state management story. Choose the case where you made the most decisions.

More developer guides

Start from the developer guide, Prepare for an AI interview as a developer, or read what Aethel's software engineering interview covers.