How to evaluate a design engineer

Why this role is hard to interview for

A design engineer sits between two functions that each have their own interview tradition. Run the engineering one and you measure implementation. Run the design one and you measure craft. Neither touches the decision that defines the job.

That decision is almost always about whether something should exist. Every design system dies the same way — not from bad components, but from forty of them where twelve would have done.

1. New, variant, or neither?

“Just add a variant to the button component, it is a one-line change.” Give them that request and one screenshot, and ask what they would do.

The weak answer adds the variant, because it is a one-line change and the person asking is a colleague. The strong one asks what problem the new button solves, whether an existing variant covers it, and whether the real issue is that the design used the wrong component in the first place.

Watch specifically for whether they consider saying no to a peer. Plenty of good engineers cannot.

2. Consistency against shipping

This is the daily trade and it has no correct answer, which is exactly why it discriminates. Ask about a time they let something inconsistent ship.

Someone who says it never happened is either inexperienced or holding a line that stops teams shipping. Someone who describes the trade — what shipped, why the exception was worth it, and what they did about it afterwards — is showing you a functioning version of the job.

3. A design that ignores the system

Hand them a mockup with three off-system spacings and a colour that does not exist in the tokens, and ask them to reply to the designer.

The failure modes are silent implementation — which puts the divergence in production forever — and a rules-based refusal, which teaches designers to stop asking. The good version separates the deliberate departures from the accidental ones, because usually two of the three were accidents and one was a real need the system does not cover yet.

4. Explaining a constraint to a designer

Ask them to explain, to someone with no engineering background, why a specific interaction would be expensive.

This is the part of the job that most affects everyone around them. An explanation that lands changes what gets designed next month; one that does not gets filed as “engineering said no” and the same request comes back in a quarter.

5. Which debt, on purpose

Ask what they have shipped knowing it would need redoing, and why that was the right call.

The answer tells you whether they think in quarters or in sprints. A design engineer who has never taken deliberate debt has probably been slowing a team down; one who cannot articulate why a particular piece of debt was worth it has been taking it accidentally.

Frequently asked

What is the difference between a design engineer and a frontend engineer?

Overlapping skills, different centre of gravity. A frontend engineer owns whether the thing works at scale; a design engineer owns whether it should look and behave this way at all, and whether the system can carry it. Hire by which of those decisions you need made, not by the title — plenty of people do both jobs under either name.

Do I need a design engineer if I already have a design system?

Having one is not the hard part. Keeping it from growing to forty components where twelve would do, and deciding which exceptions are worth it, is — and that is a judgment role, not a maintenance one.

Should I review their GitHub?

Briefly. It shows what they merged, which is useful for confirming a craft floor. What it cannot show is what they talked the team out of, and in this role that is most of the value.