Questions to ask an AI product designer
Ask about one decision they made, and keep asking about that same decision for forty-five minutes. Do not work through a list — every list is published with its answers attached, so a question you can look up is a question they've rehearsed. The questions below are shaped to have no lookup-able answer, because they're about their work rather than the field.
I sell fractional design leadership and I'm describing the interview I'd want to be given, which is a conflict worth stating plainly. It's also an interview I'd find harder than the standard one, which is the only reason I think it's worth your time.
Why the standard question banks don't work any more
Check what's actually published. Indeed lists thirty-nine product design interview questions with sample answers. Uxcel publishes a top-fifty with answers. One question bank advertises 994 questions and answers. Exponent and Revarta sell practice tools that drill them, and at least one of those will run the rehearsal against an AI interviewer until the delivery is smooth.
This isn't cheating and I don't think less of a candidate for preparing. It's just an information problem for you: on the AI-specific queries in particular, most of what's published is written for the person answering, so the questions are common knowledge and the answers are commodity. When I checked on August 21, 2026, the general "product designer interview questions" result set was a fairly even split between employer-side HR content — Deel, Braintrust, Fullstory — and candidate prep. Narrow it to AI product design and it tilts hard toward preparation material: guides for the OpenAI loop, fifty-with-answers, "the portfolio questions I'm preparing to answer."
So the asymmetry runs against you. Anything generic you ask, they've seen. The fix isn't a cleverer generic question — it's to ask about something only they know.
The shape: one decision, held under pressure
Pick a single decision from something they actually shipped. Not a project, a decision — one fork where they went left instead of right. Then stay there. Most interviews cover six topics at a depth of one; you want one topic at a depth of six, because judgment is only visible below about the third follow-up.
The rest of this is what to ask once you're down there, and what a thin answer sounds like.
The questions
1. "What did you throw away, and why was it worse?" Listening for: a specific discarded direction that was worse in an interesting way. "We tried a wizard first; it tested fine but every support ticket came from step three, where people didn't have the account number in front of them." Thin version: "we iterated a lot" or a discard that was obviously bad from the start, which means they're describing a straw man rather than a real fork.
2. "What was the constraint you couldn't design around?" Every shipped thing is deformed by something — a schema, a regulator, a customer who funds the module nobody likes, a date. Someone who names none is describing a concept piece, possibly without realizing it. Someone who names one and then explains how the design absorbed it is the hire.
3. "Where is this design wrong now?" Listening for whether they've looked since. A designer who shipped and never went back has no feedback loop, and in an AI product the feedback loop is the design work — the interface is decided by what the model does to real users, which you cannot know in advance. A confident "nothing's wrong with it" is the answer that should worry you.
4. "Which part did the model do, and what did you cut?" The useful version of "do you use AI." Never ask whether — ask about the division of labour on a specific artifact. Good answers are unglamorous and precise: generated against a token contract, three variants, kept one, rewrote the empty states by hand because the generated ones assumed data that doesn't exist for new accounts. Bad answers are either defensive ("I do all my own work") or total ("I just prompt it"), and both mean they haven't got a working method yet.
5. "What happens in your design when the model is confidently wrong?" The one AI-specific question I'd never drop. "The model failed" collapses several different situations — no answer, a low-confidence answer, a fluent and wrong answer, a right answer the user won't believe — and they need different interfaces. Someone who has shipped a model-backed product has opinions here immediately; someone who has only shipped around one has a generic error-state answer. The long version of why this is the question.
6. "Who else was in the room, and what did they change?" Named people, named changes. Sole authorship of an entire system is the oldest tell in portfolio review and it survives into the interview intact.
7. "What would you need to see to change your mind about it?" Listening for a falsifiable answer — a metric, a support pattern, a specific user behaviour. This is the question that most cleanly separates a designer with a model of the product from one with a preference about the product.
If you only get one question
"What did you throw away, and why was it worse?" — number one, and it isn't close.
It works because a discarded direction is expensive to invent convincingly. It has to be plausible enough that a competent person would have tried it, and it has to fail for a reason specific enough to be checkable, and the two constraints together are very hard to satisfy from imagination or from a language model. Everything else on the list has a decent fabricated answer available. This one mostly doesn't.
What not to ask
Don't ban AI, and don't make its use the topic. "Do you use AI in your process" is a 2023 question with a 2026 rehearsed answer, and banning tools in an exercise tells you how someone works in conditions that will never recur. Watch them use their own tools instead.
Don't ask tool trivia. Which model, which plugin, which Figma feature — all of it churns quarterly, and it selects for recency of tinkering rather than quality of judgment.
Don't ask them to critique your product cold. You'll get either flattery or a list of things they don't have the context to understand, and you'll mistake the confident version for insight. If you want this, give them the context first and accept it's a two-hour exercise, not a question.
Don't run a hypothetical design prompt — "design an elevator for a blind user." It's a genre with published solutions, it rewards performance, and it tests the one thing generative tooling is now genuinely good at: producing a plausible answer to a made-up brief. Fake problems produce fake results.
When a structured interview beats this
Be fair about where this approach loses. If you're hiring at volume, comparing many candidates against one bar, or operating anywhere that requires defensible consistency between interviewers, a deep single-decision conversation is hard to score and easy to run unfairly — it rewards candidates who present well under follow-up, which is correlated with seniority and confidence but also with things you don't want to select on. A structured rubric is worse at finding the exceptional person and much better at not being arbitrary, and if you're making twenty hires that trade is correct.
For one senior hire, where being right matters more than being consistent, go deep on one decision.
This interview is roughly forty-five minutes and it's the cheap half. The other half is watching them work on something real, which is the method here — both steps sit inside the five-step sequence — and if you haven't yet settled whether you want a person, a firm, or a fractional lead, start there instead. What I charge and how I'd rather be assessed, or hello@product.inc.