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.

Key takeaways

• Drop trivia questions and measure judgement, debugging skill and the ability to explain trade-offs instead.
• Ask questions that mirror the job, from what happens between the URL and first paint to a failing npm ci.
• Reward candidates who name real browser steps over those who quote documentation back at you.
• Treat an honest it depends, followed by naming the dependence, as a strong signal.
• Value debugging confidence and visible reasoning more than a perfect first answer.

FAQ

Q: Why stop asking questions like which hooks exist? A: Reciting hook names only shows someone can memorise, and it says nothing about how they behave on Monday morning. The questions that matter measure judgement, debugging skill and the ability to explain trade-offs, which is what the job actually demands.

Q: What does a strong answer look like when a candidate is stuck? A: I want to hear how they think, not whether they guessed right. Naming the actual browser steps beats quoting docs, and a candidate who says it depends and then names the dependence is my favourite kind of engineer.