How to evaluate a design engineer
By Sergio Gualda · 8 min read · Updated
Evaluate a design engineer on the decisions nobody logs: when a component should be new, a variant, or shouldn't exist at all; how they trade system consistency against shipping this week; what they do with a design that ignores the system; and which debt they choose to take on. A GitHub profile shows what they merged. Most of this role's value sits in what never got built.
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. Design systems tend to die the same way: forty components where twelve would have done, most of them perfectly well built.
1. New, variant, or neither?
“Just add a variant to the button component, it's a one-line change.” Give them that request and one screenshot, and ask what they'd do.
The weak answer adds the variant, because it's 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 design used the wrong component in the first place.
Watch for whether they consider saying no to a peer. Plenty of good engineers can't.
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 justified, 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 doesn't exist in the tokens, and ask them to reply to the designer.
One failure is silent implementation, which puts the divergence in production forever. The other is a rules-based refusal, which teaches designers to stop asking.
The good version separates intentional departures from accidental ones. Usually two of the three were accidents and one was a real need the system doesn't cover yet.
4. Explaining a constraint to a designer
Ask them to explain, to someone with no engineering background, why a particular 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 doesn't gets filed as “engineering said no”, and the same request comes back in a quarter.
5. Which debt, and why
Ask what they've 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 chosen to take on debt has probably been slowing a team down. One who can't explain why a particular piece of debt was worth it has been taking it on by accident.
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 for the decisions you need made. Plenty of people do both jobs under either title.
- Do I need a design engineer if I already have a design system?
- Having one is the easy part. The hard part is keeping it from growing to forty components where twelve would do, and deciding which exceptions to allow. That's a judgment role more than a maintenance one.
- Should I review their GitHub?
- Briefly. It shows what they merged, which is useful for confirming a craft floor. It can't show what they talked the team out of, and in this role that's most of the value.