These frontend developer interview questions focus on the browser platform rather than any one framework: semantic HTML, accessibility, CSS layout, performance, caching and security. They are for hiring managers who want to know whether a candidate can build interfaces that are fast and usable by everyone, and for developers preparing for that conversation. Each question has what a good answer covers and, often, a red flag. Pick 6 to 8 across sections. If you also need framework depth, add questions from our React set.
What a strong frontend developer interview checks
- Semantics and accessibility: markup that works for keyboard and screen reader users.
- Layout: fluent use of Flexbox, Grid and container queries.
- Performance: Core Web Vitals, loading strategy, images and bundle size.
- Browser fundamentals: rendering, caching and how requests cross origins.
- Security: XSS, content security policy and safe token storage.
- Product sense: working well with designers and caring about real users.
Frontend developer interview questions: HTML and accessibility
1. Why use a button element instead of a div with a click handler?
What good looks like: a native button is focusable, responds to Enter and Space, announces itself as a button to screen readers, and can be disabled, all for free. A clickable div needs a role, a tabindex and key handlers to come close, and it often still misses something.
Red flag: "They look the same, so it doesn't matter."
2. How do you make a modal dialog accessible?
What good looks like: move focus into the dialog when it opens, keep focus inside it, close on Escape, and return focus to the trigger when it closes. Give it an accessible name. The native <dialog> element opened with showModal() handles focus containment, Escape and making the background inert, so it's often the best starting point.
3. What does WCAG 2.2 AA require for contrast, focus and touch targets?
What good looks like: text contrast of at least 4.5 to 1, or 3 to 1 for large text. Keyboard focus must be visible, and in 2.2 the focused item must not be fully hidden by things like sticky headers. Targets should be at least 24 by 24 CSS pixels or have enough spacing. Strong candidates test with a keyboard and a screen reader, not just an automated checker.
4. What are ARIA attributes for, and when should you avoid them?
What good looks like: ARIA adds roles, names and states where HTML has no native element, like a tab panel. The first rule is to use native HTML when it exists, because wrong ARIA is worse than none. For example, adding role="button" doesn't add keyboard behavior.
CSS and layout
5. When do you use Flexbox and when do you use Grid?
What good looks like: Flexbox lays items out along one axis and lets content size drive the layout, which suits toolbars and rows of tags. Grid controls rows and columns together, which suits page layouts and card galleries with aligned edges. They combine well: a Grid page with Flexbox inside each card.
6. What problem do container queries solve that media queries don't?
What good looks like: media queries respond to the viewport, but a card might sit in a wide main column or a narrow sidebar on the same screen. Container queries let a component respond to the size of its container, after you mark the parent with container-type: inline-size. That makes components truly reusable. They've worked in all major browsers since 2023.
7. Two CSS rules fight over the same element. How does the browser decide, and how do you keep it manageable?
What good looks like: origin and importance first, then cascade layers, then specificity (IDs over classes over elements), then source order. To keep it sane, use low-specificity selectors, order styles with @layer (for example reset, base, components, utilities), and use :where(), which adds zero specificity, for defaults that should be easy to override.
Red flag: fixing conflicts by adding !important everywhere.
Performance and the browser
8. What are the Core Web Vitals, and how would you improve each?
What good looks like: Largest Contentful Paint (good at 2.5 seconds or less): speed up the server, preload and prioritize the hero image, cut render-blocking resources. Interaction to Next Paint (good at 200 milliseconds or less), which replaced First Input Delay in 2024: break up long JavaScript tasks and do less work per interaction. Cumulative Layout Shift (good at 0.1 or less): reserve space for images, ads and embeds. A strong answer separates field data from real users and lab data from tools.
9. What's the difference between async and defer on a script tag?
What good looks like: both download without blocking HTML parsing. async runs as soon as it arrives, in any order, which suits independent scripts like analytics. defer runs after parsing finishes, in document order. Module scripts are deferred by default.
10. How do you serve images efficiently?
What good looks like: use srcset and sizes so each device downloads the right size, use modern formats like AVIF or WebP, and always set width and height to prevent layout shift. Lazy-load images below the fold, but never the main hero image. Give that one fetchpriority="high".
11. Compare client-side rendering, server-side rendering and static generation.
What good looks like: client-side rendering ships a mostly empty page and builds it in JavaScript, which is simple to host but slower to first content and weaker for SEO. Server-side rendering sends HTML per request, which is fast to first content but costs server time. Static generation builds HTML ahead of time, which is fastest and cheapest for content that rarely changes. Modern frameworks mix these per route and can stream HTML as data arrives.
12. How should you set caching headers for a typical web app?
What good looks like: give hashed static files (like app.3f9a1c.js) a long cache, such as Cache-Control: public, max-age=31536000, immutable, since a new build produces new filenames. Make the HTML revalidate on each request (no-cache with an ETag) so users pick up new builds. Never cache personalized responses in shared caches.
13. What is CORS, and what does it protect?
What good looks like: browsers block a page from reading responses from another origin unless that server allows it with headers like Access-Control-Allow-Origin. Requests with custom headers or methods trigger a preflight OPTIONS check first. CORS protects users' browsers, not your server, since tools like curl ignore it. With credentials, the server can't use a wildcard origin.
Security and practical scenarios
14. How do you prevent cross-site scripting in the frontend?
What good looks like: never insert untrusted strings as HTML. Use textContent or the framework's default escaping, and sanitize with a library like DOMPurify when you must render user HTML. Add a Content Security Policy with nonces to block injected scripts, and consider Trusted Types for large apps.
15. Where should a web app store an auth token?
What good looks like: an HttpOnly, Secure cookie with a suitable SameSite setting keeps the token out of reach of JavaScript, so XSS can't read it. Tokens in localStorage are readable by any script on the page. Cookies bring CSRF risk, which SameSite and CSRF tokens address. Strong candidates explain the trade-off instead of declaring one answer always right.
16. A page jumps around as it loads. How do you fix it?
What good looks like: find the shifting elements with DevTools or a layout-shift report. Then set image and video dimensions or an aspect-ratio, reserve space for ads and embeds, avoid inserting banners above existing content, and reduce font swap shifts with matched fallback fonts.
17. The JavaScript bundle grew to 2 MB. What do you do?
What good looks like: measure with a bundle analyzer to see what's in it. Split code by route with dynamic import(), remove duplicate or unused packages, replace heavy libraries with lighter ones, and check that tree shaking works. Set a size budget in CI so it doesn't creep back.
Behavioral (STAR)
18. Tell me about a design that didn't work on small screens. How did you handle it with the designer?
What good looks like: they raised it early with a quick prototype or screenshot, proposed options rather than just objecting, and reached a solution together. The Result shows the shipped design and how users responded.
19. Describe an accessibility problem you found and fixed.
What good looks like: how they found it (a keyboard test, a screen reader, a user report), the fix, and how they stopped it recurring, such as an automated check in CI or a shared component.
Red flag: no example at all for a senior frontend role.
A simple scoring rubric
Running this interview with AI
NTRVSTA's exam library includes JavaScript, React and Angular, and you can tailor the questions per role, so a frontend round can cover both the platform and your framework. The AI interviewer runs it live and changes difficulty as the candidate answers. Someone fluent in layout and accessibility moves on to rendering strategies and security, while someone shaky gets simpler follow-ups and an optional hint.
You receive a score breakdown and video snippets of the key answers, so your frontend lead can review in minutes. For background, read how AI interviews are scored and see our list of AI interview software. Related sets: React interview questions, JavaScript interview questions and QA engineer interview questions.
Questions
Should a frontend interview focus on a framework?
Spend most of it on the browser: HTML, CSS, accessibility, performance and security. Those skills carry across frameworks and are where many candidates are weakest. Add a framework-specific section only for the stack you actually use.
How do I test accessibility knowledge without a checklist quiz?
Give a real component, like a dropdown menu or a modal, and ask how a keyboard user and a screen reader user would experience it. Strong candidates talk about focus, roles, labels and testing with real assistive technology.
Is a take-home project better than a live interview for frontend roles?
Both work. A short take-home of two to three hours shows code organization and polish, and a live discussion afterwards checks that the candidate understands their own choices. Keep take-homes short and pay for anything longer.
Want to see how an adaptive AI interviewer handles a frontend round? Try a sample interview now, or book a 20-minute demo to set one up for your open role.
