The AI design round
An AI design round is a 45 to 60 minute design conversation that comes in three distinct shapes: product-shaped, where you decide whether AI belongs in the solution at all; applied-ML-shaped, where you frame a task, choose an approach and define success; and agent-shaped, where you design a system that plans, calls tools and recovers. The round name does not tell you which. The job description and your recruiter's wording usually do.
If your round is explicitly named LLM System Design, read that guide instead — it is the narrower, architecture-shaped case.
The three shapes, and how to tell them apart
Read the job description for which of these the team is hiring for. That is the strongest inference available before your recruiter confirms anything.
| Shape | Posting language that points to it | How the round opens |
|---|---|---|
| Product-shaped | Users, outcomes, ambiguity, working with product and design, zero-to-one. | A vague user problem. You are expected to scope before designing. |
| Applied-ML-shaped | Modelling, features, data, metrics, experimentation. | A task to frame: input, output, definition of correct, and how you would measure it. |
| Agent-shaped | Agents, tools, orchestration, workflows, automation, reliability. | A system that must act: planning, tool calls, recovery, and stopping conditions. |
Which one you get depends far more on the team than on the round name. Recruiter wording is the strongest available signal, and asking costs you nothing.
What to ask your recruiter
Before you prepare anything, send one short email: how many rounds, what each one is called, how long each runs, whether any of them is a take-home, and whether an AI assistant is allowed in the coding round. Recruiters answer this routinely. Anything they confirm outranks every pattern on this page, because it is first-party evidence about your loop rather than a general tendency across companies.
What the name usually means
- Product-shaped: you are given a vague user problem and asked whether AI belongs in the solution at all, and how you would scope it.
- Applied-ML-shaped: you are asked to frame a task, choose an approach, define success, and decide what data you need.
- Agent-shaped: you are asked to design a system that plans, calls tools, and recovers from its own mistakes.
- Whatever the shape, the round rewards stating your assumption out loud early: "I am reading this as a product scoping question — tell me if you want me to go into architecture instead."
What it tends to test
- Problem framing
- Turning a fuzzy request into a task with an input, an output, and a definition of correct.
- Knowing when not to use a model
- Rules, heuristics, and retrieval-only answers are often correct. Reaching for a model every time reads as inexperience.
- Success metrics
- An offline metric, an online metric, and the gap between them. Plus what you would ship a guardrail against.
- Trade-off articulation
- Quality against latency, cost, and risk — stated explicitly rather than assumed.
- Iteration plan
- What v0 looks like, what would make you kill it, and what v1 depends on learning.
- Adaptability
- Whether you can change direction when the interviewer moves the constraint mid-conversation, which they frequently will.
What it is not
- Not a classical ML theory exam, in most applied roles.
- Not a pitch. Enthusiasm for AI is not the signal; judgement about it is.
- Not a coding round, though you may be asked to sketch an interface.
- Not a round where the right answer is always to build something.
Study now, review, skip
- Your reading of which shape this round is, stated as an assumption you will voice out loud.
- One story where you decided not to use a model, and why that was right.
- A default metric ladder: offline eval, shadow traffic, small online test, guardrail metric.
- A scoping routine: restate the problem, name the users, name what you are optimising, then design.
- Evaluation design at design-round depth.
- Retrieval and serving basics, in case the round turns architectural.
- Agent recovery and stopping conditions, if the posting mentions agents at all.
- Classical ML theory, unless the posting names modelling work.
- Framework and vendor comparisons.
- Memorised reference architectures.
Common failure modes
- Preparing one shape and being given another, with no plan for recognising the difference in the first two minutes.
- Designing before framing. In product-shaped rounds this alone can lose it.
- Advocating for AI rather than assessing whether it fits.
- No kill criterion and no v0, so every option sounds equally reasonable.
- Treating a moved constraint as an attack rather than as the actual exercise.
A three-day plan
Day 1 — Decide the shape
- Re-read the job description and decide which of the three shapes it is written for. Write the sentence you will say out loud in the round.
- Email your recruiter to confirm what the round covers.
Day 2 — Framing and metrics
- Practise scoping out loud on two vague prompts, spending the first three minutes only on framing.
- Write your metric ladder and your default guardrail metric.
Day 3 — The other two shapes
- Spend an hour on each shape you did not prepare, so a surprise costs you a few minutes rather than the round.
- Prepare the no-model story and one case where you killed a feature.
Common questions
- How do I find out which version of the round I am getting?
- Ask your recruiter what the round covers and who runs it. That answer is first-party evidence and outranks any inference from the round name. Failing that, the job description's emphasis is the next best signal.
- What if I prepare the wrong shape?
- State your reading out loud in the first minute. Interviewers routinely correct it, and doing so costs you two minutes rather than the round. Silently designing the wrong thing for forty minutes is the expensive version.
- Is it acceptable to say AI is not the right solution here?
- It is often the strongest answer available, provided you say what you would build instead and what would change your mind. What reads badly is refusing to engage with the problem.
- How is this different from LLM system design?
- LLM system design is reliably architecture-shaped. The AI design round may be architecture-shaped, but it is just as likely to be product scoping or applied ML framing, which is why identifying the shape comes first.
Related interview guides
- AI system design interview: framework and prep
A reusable framework for designing systems where a model is one dependency among many.
- Applied AI engineer interview: rounds and prep
Product judgment plus production AI systems, and the cross-functional ownership signal underneath both.
- LLM system design interview, decoded
The LLM-specific cut: retrieval architecture, prompting and orchestration, token budgets, failure handling.
- AI interview prep: the 2026 guide
The hub. Every role guide and round guide on this site, and how to decide which ones apply to your loop.
How every ranking on this site is reasoned about, including what counts as evidence: read the methodology.
Map your actual interview.
This page is the general pattern. Paste the job you are actually interviewing for and the wording your recruiter used, and the map ranks the rounds you are likely to face, explains why each is ranked where it is, and tells you what to skip.
See a complete Full Interview Map example