17
Interview questions with listen-for notes
FRONTEND DEVELOPER INTERVIEW QUESTIONS
Frontend Developer Interview Questions
Frontend interviews chase framework trivia while the actual job is judgment: turning ambiguous designs into interfaces that are fast, accessible, and maintainable under changing requirements. Framework syntax changes yearly; the judgment is what you are hiring.
These questions test the four layers of frontend competence: product-quality instincts, component architecture that survives growth, the performance and accessibility craft that separates professionals from tutorial graduates, and design collaboration habits. The UI-build test task at the bottom shows you all four in ninety minutes.
- 17 questions
- Employer-side guide
- Includes a paid test task
At a glance
What this frontend developer interview kit covers
Every question comes with a note on what a strong answer sounds like, so a non-specialist can run the interview and still read the signal.
4
Interview stages covered
1
Paid test task blueprint
$5,500/mo
Median nearshore frontend developer rate
Before you interview
What a frontend developer interview has to establish
The real failure mode
The frontend is where your company is experienced, which makes this hire a product-quality decision. The interview must therefore test taste as well as code: what does the candidate notice in a janky interface, what do they consider unacceptable to ship, and where do they push back on a design that will not survive real content and real screens. Ask them to critique an interface live, ideally yours. Strong candidates see in layers: visual polish, interaction latency, edge-case content, accessibility, and they prioritize the problems rather than listing them flat.
What to test for
The second layer is architecture under change. Frontend codebases rot fast because UI requirements churn fast: the component that was clean at three variants is a swamp at eleven. Probe for scars: a component structure they regretted, how they decide what state lives where, what they extract and when. And because frameworks churn too, weight fundamentals over framework: candidates strong in JavaScript, browser behavior, and CSS mechanics transfer across framework versions; candidates who only know this year's API surface are renting their competence.
Stage 1
Product sense and craft
Frontend developers are custodians of experienced quality. Test what they notice and what they refuse to ship.
Open our site or app right now and critique it: what would you fix first, and why that first?
What to listen for: Layered seeing with prioritization: they distinguish cosmetic issues from friction that costs conversions, note loading behavior and responsiveness, and maybe catch an accessibility miss. Grade the ordering logic hardest. Diplomatic delivery is a bonus signal; they are critiquing your work to your face, which is a daily job skill.
Tell me about an interface you built that you are genuinely proud of. What made it hard, and what would a user never notice that you sweated over?
What to listen for: Craft pride in invisible things: latency masking, empty and error states, keyboard flows, resize behavior. The never-notice clause is the question; frontend quality is mostly invisible when done well, and candidates who sweat invisible things ship interfaces that feel good without users knowing why.
A designer hands you a beautiful mockup with one state: the happy path, full of perfect content. What is missing, and what do you do about it?
What to listen for: The states catechism: loading, empty, error, overflow content, long names, small screens, slow networks. Strong candidates treat missing states as a collaboration trigger, going back to the designer with specific questions rather than inventing or ignoring. This is among the most predictive daily-work questions on the page.
What is a design decision you pushed back on, and how did that conversation go?
What to listen for: Respectful, reasoned pushback: a usability or feasibility concern raised with evidence, a proposed alternative, and acceptance of the final call. Frontend developers who never push back ship beautiful mistakes; ones who push back badly burn the design relationship the role depends on.
Stage 2
Architecture and fundamentals
Test the structure under the pixels: component judgment, state discipline, and framework-independent fundamentals.
Describe a component or frontend codebase that grew painful. What made it rot, and what did you do or wish you had done?
What to listen for: Recognized rot mechanisms: prop explosion, state scattered across layers, styling drift, a component serving too many masters. The wish-I-had answer reveals their architectural values; the strongest candidates describe boundaries they now draw earlier.
How do you decide where state lives: component, shared store, URL, server? Walk me through the reasoning with a real example.
What to listen for: A decision framework applied to a specific case: locality by default, lifting deliberately, URL state for shareable and refreshable things, server state treated as cache rather than copied truth. State discipline is the single best predictor of frontend codebase health at year two.
Without naming a framework: what actually happens between a user clicking a link to your app and seeing an interactive page? Go as deep as you can.
What to listen for: Fundamentals depth: DNS and request basics, HTML parsing, render-blocking resources, script loading, hydration or initialization, when interactivity actually arrives. Depth here transfers across every framework churn; shallowness here means their knowledge is rented from the current framework's documentation.
Explain a CSS layout problem that took you embarrassingly long to solve, and what the mechanism turned out to be.
What to listen for: Honest war stories with mechanisms: stacking contexts, flexbox min-width defaults, collapsing margins, overflow traps. Every real frontend developer has these scars and laughs about them; candidates above admitting CSS struggle either avoid CSS or avoid honesty.
How do you use AI coding tools in frontend work, and where have they burned you or almost burned you?
What to listen for: Productive skepticism: assistants for scaffolding and speed, personal review for correctness, accessibility, and performance, and a story of catching generated code that looked right and was not. Frontend is where plausible-but-wrong AI output is most common; the burn story shows they review rather than trust.
Stage 3
Performance and accessibility
The professional layer. These questions separate developers who make interfaces work from developers who make them work well for everyone.
Users say the app feels slow. Walk me through your actual investigation: tools, order, and what you look for.
What to listen for: Measurement first: performance profiling, network waterfall, bundle analysis, distinguishing load performance from interaction performance, and checking real-user conditions rather than a dev machine. Then proportionate fixes: code splitting, image discipline, memoization where measured, not sprinkled. Vibes-based optimization is the anti-pattern to screen out.
What does accessibility mean in your daily practice, concretely? Not the ideal: what you actually do on every component.
What to listen for: Habits, not slogans: semantic elements before ARIA patches, keyboard operability checked by hand, focus management in modals and route changes, contrast checked at design handoff, labels on every input. Ask what they do when a design fails contrast; the answer shows whether accessibility survives contact with deadlines.
Tell me about the widest browser-and-device gap you have had to support, and the ugliest compatibility issue you solved.
What to listen for: Real-world range: old mobile browsers, embedded webviews, low-end devices. The solving story should include how they detected, isolated, and worked around it. Developers who have only shipped to modern Chrome on fast laptops have not met your actual users.
What do you check before you call a page done: your personal ship checklist?
What to listen for: An internalized checklist: states covered, keyboard pass, responsive pass, slow-network behavior, console clean, analytics events firing. The existence and specificity of the ritual is the answer; done-when-it-renders is the failure mode that generates your bug backlog.
Stage 4
Collaboration and remote habits
Frontend sits between design, backend, and product. Test the interface-role habits, remotely.
Describe your working loop with the last designer you collaborated with closely: handoff format, feedback cycles, and one conflict you resolved.
What to listen for: A real collaboration rhythm: early feasibility input before mockups harden, questions batched at handoff, implementation reviewed against design with tolerance negotiated. The conflict story shows whether the relationship survived disagreement, which is the actual test of design collaboration.
The API you need is not ready and the backend developer is heads-down. The feature is due. What do you do?
What to listen for: Unblocking craft: agree the contract early, mock against it, build states against realistic fake data, integrate when ready, and flag timeline risk immediately rather than at integration. Frontend developers who can only build against finished APIs serialize your whole team.
Working from Latin America with a US product team, how do you keep design reviews and quick UI feedback loops tight?
What to listen for: Exploiting overlap deliberately: live design reviews and pairing in shared hours, recorded walkthroughs for async review, preview deployments so anyone can click the work, screenshots and videos attached to every PR. Nearshore overlap makes same-day design iteration normal; their habits determine whether you actually get it.
What frontend work do you want to be doing in two years, and what would keep this role interesting for you?
What to listen for: A trajectory you can feed: design systems, performance specialty, full-stack breadth, mentoring. Frontend developers churn when the work flattens into ticket production; knowing their growth vector is your retention lever.
Beyond the interview
Paid test task: the component build
Pay finalists for a 90-minute, time-boxed build: a realistic component from your actual product domain, specified with a static mockup and deliberately missing states: say, a data table with filtering, or a multi-step form. Provide fake data with traps: long names, empty arrays, error cases. Ask for working code plus a short written note on decisions, shortcuts taken under the time box, and what they would do with another day. Score the states they handled unprompted, the keyboard and semantics baseline, code structure, and the honesty of the note. Explicitly permitted: AI assistants, with the requirement that they stand behind every line, which mirrors real work and shows you how they use the tools.
Red flags
Frontend Developer red flags that predict a bad hire
Any one of these is worth a hard second look. Two or more, and the polished answers elsewhere in the interview stop mattering.
Happy-path blindness
If the missing-states question and the test task both come back with only the sunny case handled, that is their definition of done, and your users live in the other states.
Framework fluency, fundamentals vacuum
Cannot explain what the browser does under the framework, or solve a layout problem without a library. When the framework churns, and it will, this developer churns with it.
Accessibility as an afterthought or a slogan
No concrete daily practices, no keyboard habit, no answer for the failing-contrast scenario. Retrofitting accessibility costs multiples of building it in, and the lawsuits are real.
Optimizes without measuring
Memoization sprinkled everywhere, or a rewrite proposed for a slowness nobody profiled, signals cargo-cult performance work that adds complexity without adding speed.
Cannot take design feedback in the critique exercise
Watch how they respond when you push back on their critique of your site. Defensiveness in that low-stakes moment predicts the design-collaboration friction at full scale.
FAQ
Interviewing a frontend developer: FAQ
What should a frontend developer test task look like?
A paid, time-boxed build of a realistic component with deliberately incomplete specification and trap-laden fake data, as described on this page. You learn more from which states they handle unprompted than from any algorithm exercise. Keep it to 90 minutes with an honesty note about shortcuts; unlimited-time tasks measure free time and polish, not judgment under real constraints, and the strongest candidates skip unpaid multi-day projects entirely.
How do I evaluate frontend candidates if I cannot judge the code?
Judge the observable product: run their test-task build yourself and try to break it with resizing, keyboard-only navigation, and weird input. Use the critique exercise, where you can grade prioritization and communication directly. Check fundamentals by watching for concrete mechanisms versus buzzwords in their answers. For the code itself, borrow a technical reviewer for one hour, or work with a staffing partner whose vetting includes senior frontend review.
Should I hire a frontend specialist or a full-stack developer?
Depends on where your product wins. If your differentiation is the interface, a complex dashboard, an editor, anything users touch all day, a frontend specialist pays for themselves in quality users can feel. If your frontend is standard forms-and-tables over a complex backend, full-stack coverage stretches further. Small teams often sequence it: full-stack first for coverage, frontend specialist when the interface becomes the bottleneck. The interview questions on this page work for the frontend half of either profile.
Are Latin American frontend developers strong for US product teams?
The talent pool is deep and the collaboration geometry is the best available offshore: frontend work is feedback-loop-intensive, with design reviews and quick iterations all day, and nearshore developers share those hours live. Argentina, Brazil, Mexico, and Colombia have large senior communities on modern stacks. Vet individuals with the fundamentals and states questions here, and test English at design-discussion level, since the role negotiates with designers and product constantly.
Keep planning
Tools for the rest of the hire
Budget first? See real frontend developer rates across Latin America or browse interview questions for other roles.
Ready To Move
Skip the screening: hire a pre-vetted frontend developer
These questions exist because unvetted hiring is risky. LavaStaff runs this screening for you: every frontend developer candidate is interviewed, tested, and reference-checked before you ever meet them, with contracting and payroll handled.