The Vibe Coding Interview: How to Steal the Room

Last week I was coaching a candidate — let's call her Maya — for a senior product role. Tomorrow, she has a live case study, and the instructions were refreshingly blunt: "Let's create a vibe coding project together." Not "walk me through your resume." Not "tell me about a time." An actual, on-the-clock, screen-share-and-build-something interview: hand her a rough scenario (an AI copilot for insurance claims adjusters), start the clock, watch her build.

This is a new interview format, and it's spreading fast. Companies used to ask candidates to describe their process. Now they want to watch it — live, unedited, prompt by prompt. Call it the vibe coding interview: you, an AI builder tool, a case, and forty-five minutes with no backstage. One line in the invite says it all: let's create a project together. No brief, no rubric, no hint of what "good" looks like — just an open canvas and a clock.

Most people are terrible at this interview, and it has nothing to do with their prompting skills.

What This Interview Is Actually Testing

Here's the part that trips people up: they prep like it's a build exercise. They practice prompts. They rehearse tool workflows. And then they walk in and get evaluated almost entirely on something else — whether they can think in public without falling apart.

A live case study isn't measuring whether you can produce a working prototype in 45 minutes. Nobody expects a working prototype in 45 minutes. It's measuring:

• Can you scope ruthlessly, out loud, under a clock?
• Can you narrate your reasoning instead of going silent while you work?
• Can you absorb a curveball mid-build without losing the thread?

Those are the three things interviewers are actually scoring. None of them show up if you treat this like a solo take-home you happen to be doing with an audience.

Move One: Cut Your Own Scope, Out Loud, First

The instinct under time pressure is to start building immediately. Resist it. The strongest opening move is the opposite — spend the first few minutes making your own brief smaller, in front of everyone.

Maya's opener: hand the case to ChatGPT as a thinking partner and say, out loud, my requirements are dumb — let's make them smart. Ask it to cut scope by half. Then push again: are we actually hitting the goal, or are we just busy?

This is the SpaceX algorithm applied live: question the requirement before you touch the design. For Maya's case, "build an AI claims tool" got cut down to "AI copilot for the adjuster, reviewing claims that are already filed" — not intake, not the customer side, one narrow wedge, framed as a deliberate cut rather than something she ran out of time for.

The scoping conversation is the interview. Everything after it is just evidence.

Move Two: Talk Your Prompts, Don't Type Them

This is the single biggest lever nobody uses, and it's almost embarrassingly simple: stop typing your prompts and start speaking them.

You talk at 100-120 words a minute. You type at 15-70. In a normal work session that gap doesn't matter much. In a live interview, it's the difference between a candidate who's visibly thinking and a candidate who's gone quiet and is making the interviewers wonder if the connection dropped.

Set up Whisper or Willow beforehand, share your AI console on screen, and speak your prompts into it. The words stream live as you talk. The room watches your reasoning arrive in real time instead of watching a cursor blink while you compose the perfect sentence. It reframes the whole session — from "candidate operating software" to "candidate thinking, and the software keeping pace."

Test this before interview day, not during it. Voice tools mishear things, and discovering that live is its own kind of choke.

Move Three: Use Multiple Tools, Not One

Here's a mistake I see constantly, and it's the one that separates a competent candidate from an impressive one: picking a single AI tool and asking it to do everything.

No single tool is good at everything, and pretending otherwise shows. Cursor writes strong code and has no taste in design. ChatGPT can generate solid visual direction — colors, logos, mood — but hand it copywriting and you'll get something that reads like a press release. Claude writes copy that actually sounds like a person, but I'd think twice before trusting it alone on the harder engineering lifts. Knowing which tool is weak where is a bigger signal than knowing how to prompt any one of them well.

So don't marry one tool for the whole session. Route the work: scoping and copy to whichever model writes like a human, the actual build to whichever coding tool you're most fluent in (Cursor, Codex, Claude Code — pick one and be fast in it), visual direction to whichever model has the better design eye. Say the routing out loud as you do it — I'm switching to X here because Y is better at this — because that sentence is doing double duty. It's not just efficient, it's you demonstrating you understand the tool landscape instead of being loyal to a favorite.

Move Four: Build, Then Immediately Ask for Less

Once a prompt's refined, get a first pass built, and then do the thing almost nobody does: immediately ask the tool to simplify what it just made.

The first output from any builder is over-scoped by default. Treat it as a rough draft, say so out loud, and cut it down. This is a second, smaller version of Move One, and interviewers notice when you do it without being asked.

Move Five: Name Your Rough Edges Before They Do

Before the prototype loads, drop in a small intro modal — three bullets on what it does, an "OK" button, one line: concept for illustrative purposes only.

Every live build has rough edges. Engineers and designers in the room are trained to spot them. The modal gets there first: I know this isn't polished, and I'm choosing not to pretend otherwise. You're not hiding the seams. You're pointing at them before anyone else can — which, oddly, is what makes people stop looking for them.

Move Six: When They Throw You a Bomb, Narrate It Into the Build

Every version of this interview has a signature moment: the mid-session curveball. A new constraint. "Actually the data's incomplete." "Actually the client also needs X." Good senior PMs don't freeze when the bomb goes off — they narrate it into the build.

The wrong instinct is to defend your original plan. The right one: say the new constraint back out loud, say how it changes your priority, and feed that into your next prompt. Interviewers aren't testing whether your first plan survives contact. They're testing whether you can replan without going quiet. Silence reads as panic even when you're just thinking. Narration reads as control even when you're a little panicked underneath it. Every time, choose narration.

Try This Before Your Next One

If you've got one of these interviews coming — or you're just building live in front of stakeholders and want it to land better — steal the shape:

• Cut your own scope out loud before you build anything.
• Talk your prompts instead of typing them, and test the voice tool before it's live.
• Route the work — copy here, code there, design somewhere else — and say why out loud.
• Ask for less immediately after every first build.
• Name your rough edges before someone else does.
• When the bomb goes off, narrate the replan instead of defending the original.

Here's the thing about "vibe coding" as an interview format — it's not testing whether you're loyal to one tool. It's testing whether you know the landscape well enough to route around each tool's weaknesses, and whether you can think in public without your process falling apart. Most candidates are still interviewing like it's 2019, where the only way to look competent was to pick one tool, go quiet, and get to work.

Don't go quiet.