The Live Design / Discovery Round
The presales equivalent of a coding round, minus the code. Youâre handed a vague customer prompt and asked to design out loud â architecture, trade-offs, cost â while an interviewer plays the role of a skeptical customer or engineering counterpart. The whiteboard, not the editor, is the shared surface here.
What to expect
Format varies by company, but the shape is consistent: a vague, one-line customer ask, a whiteboard or shared doc, and an interviewer who expects you to drive â asking questions, narrating your reasoning, and arriving at a defensible design, not a perfect one.
| Problem type | What it looks like |
|---|---|
| Architecture whiteboard from a vague prompt | âA retailer wants an AI agent that answers order-status questions from their support inbox.â Youâre expected to ask scoping questions, then sketch a system â not jump straight to a diagram. |
| Cost and scaling trade-offs | Given a rough volume (say, 50,000 tickets a month), estimate token spend, pick a model tier, and explain when youâd switch from a hosted API to something cheaper or self-hosted. |
| RAG design questions | How would you chunk this customerâs document set? What happens when retrieval returns the wrong passage? When would you reach for a rerank step instead of just adding more context? |
| Agent and tool-use design questions | Where does this need a single well-scoped tool call versus a multi-step agent loop? Whatâs your answer when the interviewer asks âwhat stops this agent from doing something destructive?â |
| Defending a design under pushback | The interviewer plays a skeptical engineering counterpart: âwhy not just fine-tune instead of RAG here?â Youâre graded on the reasoning, not on winning the argument. |
You will not be asked to write or debug code live in this round â thatâs what the case-study round covers, if the loop has one. This round is testing whether you can think in systems out loud, under a little bit of pressure, in front of someone playing a customer.
What actually separates a pass from a fail
The design doesnât need to be the âcorrectâ one â there usually isnât one. What interviewers consistently flag, in both directions, has more to do with how you got to the design than the design itself:
Scoping questions before a diagram
Asking âwhatâs the data volume, and where does it live today?â before sketching anything reads as someone whoâs actually run discovery calls, not someone reciting a reference architecture from memory.
Naming the trade-off, not just the answer
âIâd use RAG over fine-tuning here because the knowledge base changes weekly and fine-tuning canât keep up cheaplyâ beats a confident answer with no reasoning attached.
A cost or latency number, even a rough one
Interviewers consistently flag candidates who can talk architecture all day but freeze the moment someone asks âroughly what would that cost per month at this volume?â A ballpark, stated as a ballpark, is the right move.
Comfort saying âit dependsâ â then actually saying what it depends on
A flat answer with no caveats reads as inexperience. The caveat plus the deciding factor is what reads as judgment.
Recovering gracefully from pushback
When the interviewer challenges a choice, changing your answer because the new information genuinely changes the calculus is a stronger signal than defending the original design out of ego.
The most common failure mode isnât a bad design â itâs a design with no reasoning attached. A candidate who picks a mediocre architecture and explains why, clearly, will often score better than one who arrives at a good architecture with no visible reasoning. The interviewer canât grade judgment they never got to see.
How to prepare
Two weeks is enough if youâre already comfortable with RAG and agent design fundamentals; the goal isnât to learn the concepts, itâs to rebuild the specific muscle of scoping and sketching under time pressure, out loud.
- 1
Week 1 â rebuild the underlying architecture fluency
This round assumes you can reason about RAG pipelines, chunking, retrieval quality, and agent/tool-use design from first principles, not just recite vendor diagrams. If any of thatâs rusty, redo Intermediate Chapters 1â6 of this curriculum hands-on rather than just re-reading them.
- 2
Week 2 â five scoping-to-diagram reps
Take five vague one-line prompts (âa bank wants an AI assistant for loan officers,â âa hospital wants to summarize intake formsâ) and practice going from clarifying questions to a rough architecture in fifteen minutes, out loud, timed.
- 3
Practice the cost-estimate reflex
For each of those five scenarios, force yourself to say an actual number â tokens per interaction, requests per day, a rough monthly dollar figure â even if itâs wrong. The habit of estimating matters more than the precision.
Three things to have ready before you walk in
Beyond practicing scenarios, a few concrete artifacts change how the whole interview reads â because they let the interviewer evaluate a real design instead of a hypothetical one:
A demo-able proof of concept
Something you can pull up and click through, not describe â a RAG search over a small document set or a simple tool-using agent, built from this curriculumâs Intermediate or Advanced labs and actually deployed somewhere reachable by URL.
Three or four well-reasoned architecture decisions
For your own demo, be ready to explain why you chunked the way you did, why you picked the model tier you picked, and what youâd change first at ten times the scale. Interviewers probe your own project far more than they probe a hypothetical one.
One story about a design you got wrong
Save the fuller version for the behavioral round, but have the two-sentence version ready here too: what you assumed, what broke the assumption, and what youâd design differently now.
None of this needs to be impressive at scale. A small, honestly-reasoned, actually-running thing beats an ambitious, hand-wavy one every time this comes up as a talking point.