How to evaluate a frontend engineer beyond the coding test

What the coding test is actually good for

It establishes a floor, and that's worth something. Someone who can't write the function won't be saved by good judgment.

Its usefulness ends at the floor. Frontend engineers who fail usually implemented exactly what was handed to them, at scale, without mentioning that the empty state didn't 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, say a dashboard with four filled cards, and ask what they'd need before building it.

The answers separate 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 don't, and what the longest realistic string is in that title.

Every one of those is a bug. Ask now and it costs a four-minute conversation; skip it and a customer finds it in production.

2. A spec that breaks at scale

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

You're watching for whether they notice, and then for what they do about it. “That will be slow” is a diagnosis. “That'll be slow past about a thousand rows; here's the cheap version now and here's what we'd need if it grows” is engineering judgment. It's 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're invisible in 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'll 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.

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

5. Do they name the risk they're shipping with?

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

Someone who says “nothing, it's done” either hasn't thought about it or isn't being straight with you. Someone who names one thing, like a payload that might change shape or a flow nobody tried on a slow connection, is giving you what 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 people out rather than in. It tells you the floor is met, which is useful. It can't tell you whether they'll build the right thing, and that's where frontend hires fail.

How do you evaluate a frontend engineer if you're 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. Nobody can prepare that part in advance.