Questions to Ask a Front End Developer
For a hiring manager, tech lead or founder interviewing a front end developer. The questions follow the order a good interview takes: what the candidate has shipped, then HTML and CSS, JavaScript and framework decisions, accessibility, speed and testing, and how they work with designers and back end developers.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Their work
What is the last thing you built that people are using right now, and which parts of it were yours?
Why ask it
Open it together if it is public. A strong answer separates their own work, such as the checkout form or the navigation, from what a teammate, a template or a component kit supplied. If every sentence starts with 'we', ask which files they wrote.
Can you show me a piece of front end code you are proud of and tell me why?
Why ask it
The reason matters more than the code. Good reasons are about the next reader or the user: it handles the empty and error cases, it is easy to change, it works without a mouse. If their paid work is private, a side project or a component described on a whiteboard does the same job.
What is the hardest interface problem you have solved, and how did you solve it?
Why ask it
Good answers are about something a user could see or feel: a table with thousands of rows, a form with branching steps, a drag that had to work by touch. Ask what they tried first that did not work. Be wary when the hardest thing they can name is getting a tool installed.
Which browsers and devices did your last project have to work on, and how did you know it did?
Why ask it
Someone who has shipped to the public knows the support list and where it came from, usually analytics or a client's requirement. 'I test in Chrome' is the worrying answer. Follow with the last bug they saw in only one browser, which is often a story about Safari on an iPhone.
Tell me about a bug that only some users could see. How did you track it down?
Why ask it
Front end bugs live on other people's machines: an old phone, a browser extension, a slow connection, a zoomed screen. You want a method, such as error reports, narrowing by browser version and reproducing it on a real device. A candidate who can only fix what appears on their own laptop will leave those users stuck.
If you started your last project again, what would you build differently?
Why ask it
The best answers are structural and specific: state that was shared too widely, a component that grew twenty options, styles nobody dared delete. 'Nothing' is thin, and so is naming a newer framework without saying what it would have fixed.
How much of the look and behavior did you decide, and how much arrived in a design file?
Why ask it
Some front end developers build finished mockups faithfully, and others fill in everything the designer did not draw. Neither is a fault, but they are different hires. If you have no designer, you need the second kind, so ask to see something they designed themselves.
HTML and CSS
When do you use a button and when do you use a link?
Why ask it
A quick sorter. A link goes somewhere and a button does something, and a candidate who knows that also gets keyboard and screen reader behavior without extra code. Reaching for a div with a click handler in both cases tends to produce controls that cannot be used without a mouse.
How would you lay out a page with a header, a sidebar and a main area that stacks into one column on a phone?
Why ask it
Have them sketch it or talk it through. Listen for grid for the page, flexbox for rows of items, and starting from the narrow screen before adding breakpoints where the content needs them. Fixed pixel widths and a breakpoint per device model are dated habits.
You give a box a width of 300 pixels and the browser draws it 340 wide. What happened?
Why ask it
The box model, asked as a bug. By default the width covers the content only, so padding and border are added on top, and box-sizing: border-box makes the width include them. Someone who lays out pages every day answers in a sentence and can point to the box diagram in the browser's inspector.
How does the browser decide which CSS rule wins?
Why ask it
Specificity, source order and inheritance should take a solid candidate about a minute. The more useful half is how they stay out of the fight: low specificity, a naming convention, scoped styles or cascade layers. A candidate whose usual fix is !important has been losing that fight for a while.
A card in the design has a short title and a tidy photo. What do you do so it survives real content?
Why ask it
Real content is a forty-character surname, a translated button label and a missing image. Good answers mention wrapping, minimum and maximum sizes, cutting text off only where the full version is still reachable, and testing with ugly data. 'The copy should be shorter' passes the problem to someone else.
How do you organize CSS on a project that several people work on?
Why ask it
Modules, utility classes, a naming convention or styles written in JavaScript can all work. What you are checking is whether they can say which problem their approach solved and what it cost. Then ask how their last team removed styles that were no longer needed.
How do you serve images so they look sharp on a wide monitor and still load quickly on a phone?
Why ask it
A complete answer has several sizes offered with srcset and sizes, a modern format with a fallback, width and height set so the page does not jump, and lazy loading below the first screen. Scaling one large file down with CSS sends the full download to every phone.
What does semantic HTML mean to you, and where has it saved you work?
Why ask it
The definition is easy, so the second half does the sorting. Real answers sound like a details element in place of a custom accordion, a label that makes a checkbox easier to tap, or headings that give a screen reader user an outline. If no example comes, they have learned the term and not the habit.
How do you build a form so that mistakes are easy to see and fix?
Why ask it
Forms show care, or the lack of it, quickly. Look for labels tied to their inputs, an error in words next to the field instead of a red border alone, typed values kept after a failed submit, and input types that bring up the right keyboard on a phone.
Which newer CSS feature have you started using, and what did it let you delete?
Why ask it
Container queries, :has, nesting, logical properties and subgrid have all retired old workarounds. You are not grading the choice. You are checking that they notice when the platform moves, and how they confirm browser support before relying on something.
JavaScript
In the last app you built, what happens between a user clicking a button and the screen changing?
Why ask it
It is open on purpose: an event, a handler, a state change, a render, perhaps a network request. Where they slow down and go deeper shows what they understand. 'The framework handles it' is fine until the framework misbehaves, so ask what they would inspect if the screen did not update.
What is a closure, and when has one caused you a bug?
Why ask it
A function keeps access to the variables that were in scope where it was created, and most candidates can recite that. What you want is the bug: a timer or an event handler still reading a value that changed long ago. With no bug to tell, the answer comes from interview preparation more than from practice.
What can go wrong when two requests come back in a different order than they were sent?
Why ask it
The classic case is a search box where the result for an earlier keystroke overwrites a newer one. Look for cancelling the stale request or ignoring its response. It checks promises and async code through a bug they will meet on the job, with no trick in it.
A list still shows the old data after a save. What could be wrong?
Why ask it
There are several honest suspects: a cache that was never refreshed, the same data copied into two places, a request that finished out of order, a function holding an old value, list items without stable keys. Strong candidates name three or four and say which they would rule out first in the developer tools.
Which framework do you know best, and what is it bad at?
Why ask it
Praise for React, Vue, Angular or Svelte is easy to recite. A weakness, with the workaround they used, shows they have stayed with one long enough to hit its walls. If your stack is different from theirs, ask how long it took them to become useful the last time they switched.
When would you build something without a framework?
Why ask it
A content page, an email, a small widget that sits on someone else's site. A candidate who cannot think of a case will bring a heavy tool to every job. One who would avoid frameworks everywhere may resent your codebase, so ask how they feel about the stack you use.
How do you decide where a piece of state should live?
Why ask it
Good answers keep state close to where it is used, lift it only when two components need it, treat server data as a cache, and put filters and page numbers in the URL so a link can be shared. A global store for everything by default deserves a follow-up: what did that store look like after a year?
How do you decide when to split something into its own component?
Why ask it
Reuse is the obvious reason and not the best one. Better reasons are parts that change for different causes, a piece worth testing alone, or a file too long to keep in your head. Ask about a component they have met with far too many options and what they did with it.
What does the user see while data is loading, when there is none, and when the request fails?
Why ask it
A mockup usually shows the screen with perfect data, and the developer owns the other three states. Hope for a placeholder that does not flash, an empty state that says what to do next, and an error with a way to retry. Ask them to show you one in something they built.
How do you decide what is rendered on the server and what in the browser?
Why ask it
Sound answers start from the page, not the tool: content that has to appear fast and be found by search engines is one case, a dashboard behind a login is another. Listen for the cost of sending a page twice, once as HTML and again as JavaScript. If your product is only one of these, say so and stay there.
What does TypeScript catch for you, and what does it miss?
Why ask it
Skip it if you do not use TypeScript. A good answer names the wrong shape passed between components, a renamed field and a forgotten case, and admits that types say nothing about what an API sends at runtime. Scattering 'any' wherever the types get hard gives up most of the benefit.
How do you stop something a user typed from running as code on another person's screen?
Why ask it
The name for it is cross-site scripting, and it is the security problem that lands on the front end. Frameworks escape text by default, so the risk sits in the escape hatches: raw HTML inserted into the page, a link built from user input, a third-party script. 'The back end handles security' is not enough, because this attack runs in the browser.
Accessibility
How do you check that something you built works with a keyboard alone?
Why ask it
Anyone can run this test, including you: put the mouse away and press Tab. Listen for a visible focus outline, a sensible order, no dead ends, and Escape closing whatever opened. If they have never tried it, invite them to try on their own portfolio during the call.
Have you used a screen reader on your own work, and what did you find?
Why ask it
'Once, and it was humbling' beats a recital of guidelines. Typical discoveries are an icon button with no name, an image described by its file name, or a dialog that left the reader on the page behind it. For a junior candidate, curiosity counts for more here than experience.
When do you add ARIA attributes, and when do you leave them out?
Why ask it
The answer to hope for is a native element first and ARIA only where no element does the job, since a wrong role can be worse than none. Ask for one case where they needed it, such as tabs, a combobox or a status message that has to be announced.
How do you build a modal dialog that everyone can use?
Why ask it
This is a compact practical test. Focus moves into the dialog and stays there, Escape closes it, focus goes back to the button that opened it, and the title is announced. Using the native dialog element or a well-kept library is a fine answer if they can say how they checked that it does those things.
What do you do when a design has text that is hard to read or a control too small to tap?
Why ask it
It tests knowledge and nerve together. A good candidate measures the contrast or the tap area, takes the numbers to the designer and suggests an alternative. Building it as drawn without a word is one failure, and quietly changing the colors without telling anyone is the other.
Which accessibility standard did your last team work to, and who checked the work?
Why ask it
Many teams aim at a level of the Web Content Accessibility Guidelines. Whether a standard is required of your product depends on where you operate and who your customers are, so put that to your own legal or compliance contact, not the candidate. From the candidate, learn whether checking was part of every review or a scramble before an audit.
Speed and testing
A page feels slow on a phone. Where do you look first?
Why ask it
Measuring comes before guessing: a throttled run in the developer tools, the network waterfall, and numbers from real visitors if the team collects them. Oversized images, too much JavaScript, fonts and third-party scripts are the usual finds. If they propose a rewrite before opening the tools, ask what the rewrite would fix.
Which performance numbers do you watch, and what did you last do that moved one?
Why ask it
Expect the Core Web Vitals by name or by meaning: how soon the main content appears, how much the page shifts, how quickly it responds to a tap. Anyone can learn the acronyms, so weigh the change they describe: a real one comes with a before and an after.
Why does a page stop responding while a long piece of JavaScript runs, and what can you do about it?
Why ask it
The page's script, its drawing and its response to taps share one main thread, so a long task holds up everything else. Fixes to hope for are doing less work, breaking it into pieces that give the browser a turn in between, or moving it to a web worker. Then ask how they would find the long task, which is a recording in the performance panel.
How do you keep a JavaScript bundle from growing without anyone noticing?
Why ask it
Splitting code by route, loading heavy parts only when needed, reading a bundle report, and a size limit that fails the build are the working answers. Ask for the biggest thing they ever removed. A blank here often means someone else on the team looked after it.
Before you add a package from npm, what do you check?
Why ask it
What it adds to the download, whether it is still maintained, its license, how many other packages it pulls in, and whether the browser can already do the job. Which licenses are acceptable is your company's call, so tell them your rule. Installing a library for one small function without looking is how sites get heavy.
What do you test on the front end, and what do you leave untested on purpose?
Why ask it
Good answers have a shape: logic in unit tests, components tested the way a person uses them, and a few end-to-end tests on the flows the business depends on. What they choose to skip, and why, is where the judgment shows. 'QA handles it' and 'everything, to full coverage' are both worth a follow-up.
How do you write a component test that does not break every time the markup changes?
Why ask it
You are listening for elements found by role and label instead of class names, and checks on what the user sees instead of internal state. Tests written that way also fail when a button loses its accessible name, which is a useful side effect. Ask whether anyone on their last team read the snapshot files.
How do you catch a visual change you did not mean to make?
Why ask it
Options run from screenshot comparison in the build, through a component gallery such as Storybook, to a careful look at three screen widths. Any of them can suit a team of the right size. What you want is the story of a shared style that broke a page nobody opened, and the habit that followed.
After a release, how do you find out about errors happening in users' browsers?
Why ask it
A working setup has an error reporting service with readable stack traces, an alert when errors jump, and a way to roll back or switch a feature off. If the answer is that users write in, ask how long the last one took to surface. It matters most on a team where developers watch their own releases.
What do you check in your own work before you ask for a review?
Why ask it
A habit sounds like a short list said without thinking: narrow and wide screens, keyboard, slow network, long text, no data, a clean console, the diff read once. A long pause suggests the reviewer has been doing that job for them.
Team and fit
A designer gives you a mockup that would be hard to build as drawn. What do you do?
Why ask it
Hope for a conversation before any code: what the design is meant to achieve, a cheaper way to reach the same effect, perhaps a quick prototype to compare side by side. A fragile hack built in silence costs you later, and a flat 'that is not possible' costs you the designer's trust. Ask for the last compromise they reached and who gave up what.
What do you ask a designer about a mockup before you start building?
Why ask it
The useful questions are about what was not drawn: hover and focus styles, the widths between the ones mocked up, the longest label, what moves, and which pieces already exist as components. A candidate with that list ready has been caught out before and will save your designer a round of rework. It works well with a real mockup of yours on the screen.
How do you agree with a back end developer on what an API should return?
Why ask it
Look for a conversation before either side builds, a written contract or schema, and mock data so the front end is not left waiting. Good candidates also push back when one screen would need six requests. Ask what they did the last time the API arrived different from what was agreed.
Have you worked with a design system or shared component library, and what did you do when a component almost fit?
Why ask it
The 'almost' is where teams end up with five kinds of button. A good answer goes to the owners with the gap, extends the component for everyone, or accepts the standard one. Copying it into the feature folder and adjusting it is quick today and a cost at the next redesign.
How do you review someone else's front end code?
Why ask it
Reading the diff is half of it: a reviewer who pulls the branch, clicks through at a narrow width and tries the keyboard catches what the code view hides. Listen to the tone as well, for questions and reasons instead of verdicts. Then ask what their last review caught.
What has an AI coding tool gotten wrong in your front end work, and how did you catch it?
Why ask it
Policy differs from one employer to the next, so say what yours allows before you ask. A careful user has a story ready: generated markup that looked right and failed with a keyboard, an error state left out, a call to a function that does not exist. Someone who uses these tools daily and cannot recall a single miss should walk you through a recent pull request line by line.
Tell me about a time someone wanted a feature you thought would hurt the people using the site.
Why ask it
A popup on arrival, a video that plays by itself, a cancel link made hard to find. You are hoping for someone who brought evidence and an alternative, then either changed the decision or built it well and watched the numbers. Notice how they speak about the person who asked, because contempt there will reach your product team too.
How do you estimate a screen, and what usually makes your estimate wrong?
Why ask it
Experienced candidates know the visible layout is the small part. The rest is states, validation, small screens, accessibility, one stubborn browser and waiting for an API. Hand them one of your real screens and have them estimate it aloud: whoever prices only the happy path will be late.
New front end tools come out all the time. How do you decide which are worth learning?
Why ask it
You are after a filter. Sensible ones are waiting until a tool solves a problem they have, reading the release notes of what they already use, and trying something on a side project before proposing it at work. Ask what they looked at and chose not to adopt: someone who chases every release will want to rewrite your codebase, and someone with nothing to name may have stopped looking.
What kind of front end work do you want more of, and what would you rather not do?
Why ask it
One person lights up at layout detail and design systems, another at data-heavy application logic, and a third is drifting toward the back end. Compare the answer with what this job is week to week, and say so plainly if the mix is different. It is kinder than finding out in month three.
What do you want to ask about how we build things here?
Why ask it
What a candidate asks tells you where they have been burned. Questions about design handoff, browser support, the test setup or who owns accessibility suggest they have seen those go wrong. Leave real time for it and answer truthfully about the age and state of your codebase.
How to interview a front end developer
Practical guidance for the conversation itself
Before the interview
Decide which front end job you are hiring for
The title covers building marketing pages from a designer's files, engineering a data-heavy application, and maintaining a component library for other teams. Write down what this person will do in their first three months, then weight the groups to match. A content site leans on HTML and CSS and on Speed and testing. An application behind a login leans on JavaScript. Keep something from Accessibility and from Team and fit in every version.
Scale the questions to the level
For a junior candidate, stay with fundamentals such as button or link, the box that came out too wide, which CSS rule wins and requests arriving out of order, and give credit for curiosity. Skip the questions that need years of shipped work behind them. For a senior candidate, skip the definitions and spend the time on Their work, state, performance numbers and Team and fit, where you should hear trade-offs without having to ask for them.
Pick eight to ten, not the whole page
An hour holds about that many once follow-ups are counted. Take one or two from each group and mark three that every candidate will get, so you have something to compare afterwards. The rest are spares for wherever the conversation goes.
Look at their work first
Before the call, open their portfolio or a site they list on your phone, press Tab through it on a laptop and drag the window narrow. Ten minutes of that gives you real things to ask about, and it shows you their habits before they describe them.
If you do not write code yourself
A founder or a non-technical manager can still run most of this. Their work and Team and fit have notes you can judge without a technical background: specifics, ownership, how a disagreement was handled. For the other groups, borrow a developer you trust for one round, or ask the candidate to explain the answer as they would to a client. How clearly they do that is evidence too.
In the interview
Start with something they built
People are most at ease describing their own project, and it gives every later question something concrete to hang on. 'On that checkout page, where did the state live?' gets a better answer than the same question asked in the abstract.
Put a screen between you
Front end work is visual, so make the interview visual. Share one of your own pages or mockups and ask what they would want to know, how they would lay it out and where it could go wrong. Or have them open the developer tools on a public site and say what they notice. Either shows you more than a definition.
Ask about one real bug, not bugs in general
A question about how someone handles browser bugs invites a tidy policy. The last one they fixed comes with a device, a cause and an afternoon lost to it, and those details are hard to make up. When an answer to anything on this page stays general, ask for the most recent case and wait.
Let them say they do not know
The field is too wide for anyone to know all of it. Say at the start that 'I have not used that' is an acceptable answer, then ask how they would find out. Watching someone reason toward an answer is closer to the job than testing recall.
Reading the answers
Listen for the user
Strong front end developers keep coming back to the person on the other side of the screen: the slow phone, the keyboard, the long name, the failed request. Answers made only of tool names tell you what they have installed, not what they have built for anyone.
Credit trade-offs over right answers
Most of these questions have no single correct reply. 'It depends' is a good start when it is followed by what it depends on and which way they went last time. Be more cautious about the candidate for whom one tool or one pattern is always the answer.
Separate knowing your stack from being good
A strong developer who knows a different framework can usually learn yours, while a weak one who knows your framework stays weak. Unless you need output in the first week, weight HTML, CSS, the language and the browser above a match with your tools.
Write it down the same way for everyone
Before the first interview, note what a good answer to each of your three shared questions contains. Straight after each interview, write what the candidate said, in their words. Without that, the most likeable person in the room tends to win the comparison.
Mistakes to avoid
Asking trivia in place of work
Guessing the output of an odd JavaScript snippet rewards rehearsal. A list that shows stale data or a card that breaks with a long title rewards having done the job. Where a definition is worth asking for, such as a closure, ask for the bug that came with it. Keep the puzzles out and the everyday problems in.
Treating CSS and accessibility as beginner topics
It is easy to spend a whole senior interview on frameworks and state. Layouts that survive real content and interfaces that work without a mouse are among the hard parts of the job, so ask at least one question from each of those groups at every level.
Leaving out the designer and the back end
The front end sits between design and the back end, and much of the work is agreeing things with both. Someone technically strong who cannot talk a mockup through with a designer or settle an API with a colleague will ship slowly on any team. Take at least two questions from Team and fit, however well the technical ones went.
Doing all the talking
Leave ten minutes for their questions and describe your codebase as it is: its age, its tests, how designs reach developers. A candidate who accepts without that picture may not stay once they see it.