TL;DR: For a forty-minute practice build, spend about five minutes scoping, twenty building, ten evaluating and five explaining the result. Reserve time for five to ten deliberate test cases. This is our rehearsal format; an employer may set a different duration or prohibit AI assistance.
Why practise building
Building gives you an artifact whose assumptions can be examined: the user you chose, the failures you tested and the scope you deferred. It is useful preparation even when the interview contains no live build. Published role responsibilities can justify practising these skills, but they do not establish an interview format.
The format
For this exercise, use an original prompt such as "build something that helps a support team with refunds", synthetic records and a tool you already know. Ask a practice partner to introduce one constraint midway, such as support for Hindi. In an actual interview, follow the written tool policy and clarify anything missing before starting.
The time plan
| Phase | Minutes (of 40) | Goal |
|---|---|---|
| Scope | about 5 | One user, one job, a narrow happy path, non-goals, success criteria |
| Build | about 20 | Working core with real model calls and simple data |
| Evaluate | about 10 | 5 to 10 deliberate test cases, pass or fail |
| Narrate | about 5 | What works, what fails, next steps, risks |
Read diagram description
A forty-minute practice build: scope for about five minutes with one user, one job and non-goals; build for about twenty with real model calls and sample data; evaluate for about ten with five to ten deliberate cases graded pass or fail; and narrate for about five covering what works, what fails, next steps and risks. Choose common, edge, sensitive, adversarial and variation cases on purpose.
Scoping
Restate the prompt, ask a couple of quick questions or state assumptions, then choose a specific user and a painful, testable job. Say what you are leaving out. Define success in one or two lines. Avoid spending fifteen minutes on discovery in a build round.
Building
- Start with the simplest structure: a notebook or a minimal page.
- Use structured output where the result feeds anything else.
- Hardcode sample data instead of integrating real systems.
- Read the code the tool generates well enough to debug it.
- Keep a working checkpoint before risky changes.
Evaluating
Protect this phase; it is the evidence the build produces. Choose cases deliberately:
- The common case.
- Edge cases you are worried about (missing information, ambiguity, long inputs).
- A sensitive case (a request the system must handle carefully).
- An adversarial case (an attempt to make it break a rule).
- A language or format variation if relevant.
Write the expected behaviour before running; grade pass or fail; note failures honestly. Eight cases with two clear failures and a plan to fix them is a strong result.
Narrating
Talk while you work, so the interviewer follows your reasoning. Finish with a readout: what it does, evaluation results, failure modes, what you would do next, risks, and what production would require.
Our practice checklist
| Signal | Weak | Strong |
|---|---|---|
| Scoping | Generic or sprawling build | Narrow happy path with non-goals and success criteria |
| Tool use | Accepts output blindly or loops | Directs precisely, reads code, simplifies when stuck |
| Verification | One happy example | Deliberate test set with pass or fail |
| Communication | Silent | Narrates assumptions and trade-offs |
| Problem handling | Panics | Time-boxes, reverts, protects time for testing |
| Readout | "It works" | Honest results, next steps, path to production |
When things break
Read the error yourself, time-box the fix, and if the tool loops, revert or simplify: notebook instead of web app, hardcoded data instead of an integration, one model call instead of an agent. Protect the evaluation and readout.
Practice
Run timed practice builds on prompts like "help a small seller answer customer questions" or "extract action items from meeting notes". Practise writing a test set quickly. Practise narrating aloud.
In the interview
Judge your rehearsal by the decisions it makes inspectable: a bounded scope, test results, a known failure and a credible next step. A working prototype is evidence about those inputs; it does not establish production safety or predict an interview result.