Should I stop running coding tests?

No — keep one, keep it short, and use it to rule out rather than to rule in. What it establishes is that the floor is met, which is genuinely useful. What it cannot establish is whether they will build the right thing, and that is where frontend hires actually fail.

How do you evaluate a frontend engineer if you are not technical?

The five behaviours above are all legible without reading code. Whether they ask about empty states, whether they cut scope or quality, whether they can explain a constraint to a designer — none of that requires you to assess an implementation. For the code itself, borrow thirty minutes of an engineer you trust.

Is a take-home project better than a live coding session?

It measures something different and it costs you candidates. A take-home now also measures how much unpaid time someone had that week and how well they use a model. If you keep one, cap it hard and change a requirement partway through — that part cannot be prepared in advance.

How to evaluate a frontend engineer beyond the coding test

By Sergio Gualda · 8 min read · Updated 14 August 2026

A coding test answers whether someone can build it. It does not answer whether they should have — whether they spot the states a design forgot, how they respond to a spec that breaks at scale, what they cut when the date moves, and whether they name the risk they are shipping with. Those are the decisions that make a frontend hire expensive or excellent, and none of them appear in an algorithm exercise.

What the coding test is actually good for

It establishes a floor, and that is worth something. Someone who cannot write the function will not be saved by good judgment.

But the floor is where its usefulness ends. Frontend engineers rarely fail because they could not implement something. They fail because they implemented exactly what was handed to them, at scale, without saying that the empty state did not exist and the list would break at two thousand rows.

1. Do they see the states the design forgot?

Hand them a clean happy-path design — a dashboard with four filled cards — and ask what they would need before building it.

The answer separates immediately. A weak candidate asks about the framework and the API shape. A strong one asks what this looks like empty, what happens while it loads, what happens when one card fails and the others do not, and what the longest realistic string is in that title.

This is not pedantry. Every one of those is a bug that will be found in production by a customer instead of in a conversation that cost four minutes.

2. A spec that breaks at scale

Give them a requirement that is fine at ten records and pathological at ten thousand — a client-side sort, a select-all, an animation on every row.

You are watching for whether they notice, and then for what they do about it. “That will be slow” is a diagnosis. “That will be slow past about a thousand rows, here is the cheap version now and here is what we would need if it grows” is engineering judgment, and it is the difference between someone who blocks and someone who ships.

3. What goes first when the date moves

Halve the timeline mid-conversation. Frontend has a specific failure pattern here: the first things cut are usually accessibility, empty states and error handling, because they are invisible on the demo.

The strong answer cuts scope instead — fewer features, fully built — and says out loud which capability is being dropped. Watch for whether accessibility is treated as polish. If it is, you will be retrofitting it under legal pressure in eighteen months.

4. Pushing back on a design without blocking it

Give them a design that ignores a real constraint and ask them to write the reply to the designer.

Two ways to fail: build it silently and let it break, or refuse and escalate. The good version names the specific problem, offers the version that works, and keeps the release moving. This is a communication skill and it is the single best predictor of whether a frontend engineer will be pleasant to work with.

5. Do they name the risk they are shipping with?

Everything ships with something unresolved. Ask what they would flag to the team on the day of release.

Someone who says “nothing, it is done” has either not thought about it or is not being straight with you. Someone who names one specific thing — this breaks if the payload changes shape, this is untested on slow connections — is giving you the thing that makes an on-call rotation survivable.

Frequently asked

Should I stop running coding tests?: No — keep one, keep it short, and use it to rule out rather than to rule in. What it establishes is that the floor is met, which is genuinely useful. What it cannot establish is whether they will build the right thing, and that is where frontend hires actually fail.
How do you evaluate a frontend engineer if you are not technical?: The five behaviours above are all legible without reading code. Whether they ask about empty states, whether they cut scope or quality, whether they can explain a constraint to a designer — none of that requires you to assess an implementation. For the code itself, borrow thirty minutes of an engineer you trust.
Is a take-home project better than a live coding session?: It measures something different and it costs you candidates. A take-home now also measures how much unpaid time someone had that week and how well they use a model. If you keep one, cap it hard and change a requirement partway through — that part cannot be prepared in advance.