Engineering and data
Frontend developers build the parts of a website or app that people see and click. A first interview should answer three questions. Do they care about details users only notice when they go wrong? Can they find bugs in the browser with a clear method? Can they work well with designers and product managers? It adds to your technical interview. It doesn’t replace it.
Follow-up questions check whether the candidate knows why an interface behaves the way it does, not just which building blocks they used.
What to look for
The questions
Ask them in order. Listen for real details: what happened, what the candidate did, and how it ended.
Strong answer
Names specific details, like loading and error states, using it with only a keyboard, long text or small screens, and says how they handled each.
Weak answer
Talks only about how it looked, or about which framework they used.
Strong answer
Recreates the problem by slowing their browser down to phone speed, and uses the browser’s built-in tools to see what’s slow. Checks the size of the code and images, and parts of the page that redraw for no reason. Measures before and after the fix.
Weak answer
Guesses one fix, like adding caching, without measuring anything.
Strong answer
Cut it down to the smallest example that still broke, found the real cause in the CSS or in how that browser behaves, and fixed it without piling on extra rules.
Weak answer
Added fixed widths or one-off exceptions until it looked right, and can’t say why it broke.
Strong answer
Talks about controlling where the keyboard focus goes, closing on the Escape key, the right labels for screen readers, using the browser’s built-in elements where possible, and testing with a real screen reader.
Weak answer
“We add alt text”, or treats accessibility as a task for later.
Strong answer
Keeps state, the data a screen keeps track of, close to where it’s used, and shares it more widely only when other parts need it. Treats data from the server differently from things like which tab is open. Has an example of getting it wrong.
Weak answer
Puts everything in one shared place for the whole app to be safe, or can’t explain the choice.
Strong answer
Raises it before building, suggests sensible options, and checks the result with the designer instead of deciding everything alone.
Weak answer
Builds exactly what’s in the mockup and ships it, or quietly invents the missing states.
Strong answer
Explained the cost in terms the product team cares about, like time or risk, offered another option, and reached a decision together.
Weak answer
Said no without offering another option, or said yes and missed the deadline.
Strong answer
Starts from a real problem on their team, and gives an example of one tool they took on and one they passed on, with reasons.
Weak answer
Lists the newest frameworks they want to try.
Before the interview
Short form questions the candidate answers before the interview. You read the answers next to the interview. They aren’t scored.
Listen for
Avoid
Use this in LessRounds
Paste the questions into a scripted interview, where the AI reads each question word for word. Add the skills from the scorecard, then share one link. Every frontend developer candidate gets the same questions. You get a score for each skill, with the candidate’s own words that explain it.
No. A spoken first interview tells you how someone thinks about interfaces and bugs. Keep coding for your technical interview, where you can see the code properly.
Ask how they’d build a specific part, like a pop-up dialog, for someone using only a keyboard. People who’ve done it talk right away about where the keyboard focus goes and about the browser’s built-in elements.
Start with 100 free credits, enough for about 20 interviews. No credit card or sales call needed.