How to Survive a 90-Minute AI Build Round (FDE Interview)

The build round is not a coding test — it's a judgment test. Clarify before coding (5 minutes, non-negotiable). Scope ruthlessly. Stub aggressively. Add one taste detail at minute 70. Demo with a narrative that names your shortcuts explicitly. The judgment signals interviewers are actually watching.

How to Survive a 90-Minute AI Build Round (FDE Interview)

The Forward Deployed Engineer build round is not a coding test. It's a product-under-pressure test. You're given an underspecified brief — often from a simulated customer — and 90 minutes to produce something working. The evaluation is not code quality. It's judgment: did you build the right thing, not the most elegant thing.

The Brief Will Be Underspecified. That's the Test.

A well-specified brief in a build round means you're being tested on implementation speed. An underspecified brief means you're being tested on judgment — the ability to clarify constraints, make defensible assumptions, and scope ruthlessly. FDE roles exist because customers give underspecified briefs. The round simulates the job.

Minutes 0-8: Clarification, Not Code

• Ask the three questions that define scope: What does success look like for this demo? (Defines the acceptance criteria.) What is the primary user action? (Defines what must work vs. what can be stubbed.) What can be hardcoded or mocked? (Defines where to cut corners legitimately.) Then state your plan out loud: 'I'm going to build X with Y hardcoded and Z stubbed out. The demo will show A and B but not C. Is that a reasonable scope for 80 minutes?' Get confirmation before writing code. Why this matters: if the interviewer has a different success criterion in mind, you want to know now, not at minute 85.

Minutes 8-15: Architecture in 5 Minutes

Sketch the architecture before writing any code. Two questions: what are the 3-4 components, and what's the fastest path to a working demo? These are often different architectures.

• Correct architecture for demo: single file, minimal dependencies, hardcoded data where necessary, the happy path only. Correct architecture for production: modular, tested, handles edge cases. You are building the first one. Write this down, say it out loud, make sure the interviewer agrees. This prevents the 'this isn't production-ready' objection — you've pre-acknowledged it. Rule: if you're spending more than 15 minutes on architecture in a 90-minute round, you're over-engineering.

Minutes 15-70: Build the Happy Path First, Edge Cases Never

• Happy path first: the demo must work for the primary use case. Everything else is optional. Stub aggressively: if you need an LLM call, stub it with a hardcoded response until the rest of the UI works. Add the real call last. If it fails, you still have a working demo. Mock data over real data: a working pipeline with mocked data is demonstrable. A broken pipeline with real data is not. No error handling until the happy path works: error handling hides bugs during development. Add it at minute 65 if you have time. Verbalize blockers immediately: if you hit something you don't know, say so. 'I'm not sure of the exact API syntax for X — I'll stub it for now and look it up if I have time.' Interviewers respect this more than 20 minutes of silent Googling.

Minutes 70-80: Add One Impressive Thing

After the happy path works, add one thing that shows taste. Not a feature — a detail. Good error message with an actionable suggestion. A loading state that shows the model is thinking. A fallback that gracefully handles the most obvious failure mode. One detail signals you think about user experience, not just code correctness.

Minutes 80-90: The Demo Narrative

Do not just run the demo. Narrate it. 'I'm going to show you the primary flow: [action]. Here's what's happening under the hood: [brief explanation]. I hardcoded X here because [reason]. If I had more time, I'd replace it with [actual solution]. The thing I'd do next is [highest-priority improvement].' This shows you understand what you built, where you cut corners intentionally, and how to continue.

The Judgment Signals Interviewers Are Actually Watching

• Did you clarify before building? Did you scope ruthlessly rather than over-engineering? Did you verbalize your thinking rather than going silent? Did you prioritize a working demo over clean code? Did you name your shortcuts explicitly rather than pretending they don't exist? Did you have an opinion about what to build next?