Prototype Strategy — Thin Slice to Working Demo

Before you write a line of code: (1) Thin-slice in their domain — 'So we're building a [what] that takes [input] and returns [output]. I'll start with the smallest version that works end-to-end, then add layers.' (2) Ask one or two sharp scope questions — the smallest number that resolves ambiguity. Good options: biggest constraint? prototype speed vs. production readiness? what makes it a win? If you have four questions, the task is underspecified — say so and propose a scope. (3) Stack-bridge line — see the Toolchain page for framing your tool choice in one sentence.

Identify the smallest end-to-end path that demonstrates the concept. Build that first — working code, not a scaffold. Once the happy path runs, immediately show one error path — the likeliest failure mode. Interviewers test failures, not features. Then add edge cases, then UX polish. Each layer is a natural checkpoint: 'Does this cover what you need, or should I go deeper on [X]?' T-minus-15 minutes: feature freeze. Stop adding. Polish what exists.

Even in a prototype, three things must be correct from the first write: (1) Parameterized queries — no string interpolation into SQL. (2) Idempotency keys on side effects — if the call repeats, the result doesn't double. (3) Secrets in environment variables — never hardcoded. These are not infrastructure — they're correctness. An interviewer who spots a SQL injection in your prototype has already made their decision.

Triage instantly: Typo → fix silently. Known error → 'I've seen this' + verify quickly (aim for ~30s). Internal bug → 'Let me think' → form 1-2 likely hypotheses, state them, and pursue the most likely. Only ask the interviewer for direction after you've exhausted your own investigation — and tell them what you ruled out. External (API, network, rate limit) → name it and ask how they want to handle it. If you're stuck silent for more than ~90 seconds, surface what you're investigating.

After each major milestone — the first working slice, the first error-handling pass, the demo-ready state — name one thing you verified. 'One thing I checked — the error handling catches empty results.' 2-3 times per session, not per chunk. This shows you verify code, not just generate it. If you spot a bug: name it, fix it, and explain why it happened.

At T-minus-5 minutes: (1) Working demo path — can you show it running end-to-end? (2) One thing you'd improve with more time — name it specifically. (3) Ask: 'Is there a specific path or edge case you'd like me to walk through?' — this is less open-ended than 'what would you poke at' and lets you demonstrate depth on a path you can control.

When the unexpected happens: Task too big? Thin-slice harder — find the absolute minimum. 'Whatever you think'? Propose a concrete scope and ask if it works. Need to re-plan? Say so: 'Let me re-plan — what we have covers X and Y, but Z needs a different approach.' Told 'don't use AI'? Close the tool and continue manually — the narration and reasoning habits carry over. Unknown stack? Be honest: 'I haven't used this, but here's how I'd approach it based on what I know.' At T-minus-15 with nothing running: stop building. Narrate what you learned, show the closest-to-working code, explain what blocked you, and offer to walk through your approach. A coherent postmortem beats a panicked scramble.

If the interviewer goes silent, stops responding to narration, or seems checked out: keep narrating. Don't fish for engagement. A silent interviewer is often taking notes or evaluating, not disinterested. If they're fully disengaged, your working demo is the only thing that recovers their attention. If you need a decision from them, ask once clearly — don't keep pinging.

Building full infrastructure first — don't build a complete auth system or normalized schema before the core logic. DO write parameterized queries, idempotency keys, and minimal validation from the first tool call. Perfectionism — polishing CSS while the core feature doesn't run. No demo — running out of time with nothing to show. Over-apologizing for AI-generated code — own it, review it, improve it. Error handling as an afterthought — interviewers test failures, not happy paths; show one error path right after the happy path works.