How I Interview Frontend Developers

Why I stopped asking trivia

Reciting a list of hook names tells me a candidate can memorize; it tells me nothing about how they will behave on Monday morning. I measure judgement, debugging skill and the ability to explain trade-offs.

The questions

• What happens between the URL and the first paint?
• When would you reach for `useEffect` to load data, and why is that usually the wrong default?
• A component re-renders every keystroke. Where do you start looking?
• Describe a layout problem you solved with `position: absolute`. When was it a mistake?
• How would you migrate a legacy class component without breaking the app?
• Your `npm ci` fails on the CI server but works locally. What do you check?
• Explain the difference between `LCP` and `TTFB` to a product manager.
• When was the last time you shipped something you were embarrassed about?

What I listen for

• Naming the actual browser steps beats quoting docs.
• A candidate who says "it depends" and then names the dependence is my favourite kind of engineer.
• Debugging confidence matters more than a perfect first answer. I want to hear how they think, not whether they guessed right.

The takeaway

Interviews should simulate the job: trade-offs, debugging and clear communication. Questions that reward those skills find engineers who actually ship.