How to Tell a Senior AI-Native Engineer From a Vibe-Coder in a 90-Minute Interview

Every resume you see now says "AI-powered development." Some of those candidates are senior engineers who ship what a four-person team used to. Some of them are juniors who learned to prompt their way past your take-home and will prompt their way into your production database. On paper, they look identical. That's the problem.

I've interviewed both kinds for years — first as a CTO hiring for my own teams, now placing AI-native engineers with startup founders. The good news: you don't need a week-long trial or a CS degree to tell them apart. You need 90 minutes and the right structure. This is the exact structure I use.

First, understand why your current interview fails.

Why AI broke the standard interview

The traditional signals are dead. A take-home project proves nothing — a vibe-coder with Claude produces a take-home that looks better than what a 2019-era senior wrote by hand. LeetCode is worse than nothing: it filters for memorization and against the engineers who've spent the last three years building real systems with AI leverage instead of grinding puzzles.

Here's the asymmetry that saves you: AI compresses the gap in output, but it widens the gap in judgment. A vibe-coder and a senior produce similar-looking code. They do not produce similar decisions — about what to build, what to reject, what the AI got subtly wrong, and what happens under load, failure, or a malicious user. Judgment is hard to fake in real time, in conversation, under follow-up questions. So that's what the 90 minutes attacks.

The structure: 20 minutes of postmortem interrogation, 45 minutes of live code review, 15 minutes of architecture under constraint, 10 minutes for their questions. No trick puzzles, no whiteboard algorithms.

Block 1 — The postmortem interrogation (20 minutes)

Pick the most substantial thing they've shipped in the last year and dig. Not "tell me about a project" — specific, uncomfortable, second-order questions. Ask these:

"Walk me through a time the AI was confidently wrong. How did you catch it?" A senior has war stories: a hallucinated API method that compiled against a stale type stub, a plausible-looking migration that would have dropped an index under load. They caught it because they read the diff and something smelled off. A vibe-coder gives you a generic answer — "sometimes it makes mistakes, so I test" — with no specific incident. No scar tissue means no real mileage.

"What did you delete from the AI's output on your last feature, and why?" Seniors delete constantly: the defensive try/catch that swallows errors, the abstraction layer nobody asked for, the third dependency for something the standard library does. If a candidate can't name anything they've rejected, the AI is the senior in that pairing — you'd be hiring the intern who holds its coat.

"Where does AI-generated code fail in ways human code doesn't?" This one separates practitioners from tourists. Seniors say things like: it's confidently consistent even when wrong, it optimizes for looking complete over being correct, it writes tests that mirror the implementation's assumptions instead of challenging them, it handles the happy path beautifully and invents behavior on edge cases. Vibe-coders say "hallucinations" and stop.

"What's your workflow when the AI's suggestion works but you don't understand why?" The only acceptable answer is some version of "it doesn't ship until I understand it." Listen for how they get to understanding — reading upstream source, writing a failing test to probe behavior, asking the model to explain and then verifying the explanation. A vibe-coder tells you, sincerely, "if the tests pass, it works." That sentence should end the interview politely.

Block 2 — The code-review exercise (45 minutes)

This is the core, and it's the exact inversion of a take-home. Don't ask them to write code with AI — ask them to review code the AI wrote. Writing is what the AI is good at; catching what it got wrong is the job you're actually hiring for.

The spec, so you can build this in an afternoon:

• Generate a realistic pull request in your actual stack: a ~150–250 line feature, e.g. "add a webhook endpoint that receives payment events and updates order status." Have Claude or your model of choice write it in one shot, unreviewed. You'll get something that looks 90% shippable. That's the point.
• Verify it contains real flaws — plant them if the model was too good. You want four or five of these, all subtle: no idempotency handling on the webhook (retries will double-fulfill orders); no signature verification (anyone can POST fake payment events); a lookup inside a loop that turns into N+1 queries at volume; an error swallowed with a log line so failed events silently vanish; tests that mock so much they'd pass against an empty function.
• Run it as a live conversation, not a silent exercise. Give them the PR, the feature description, and one instruction: "You're the senior on this repo. This came from a teammate using AI. Review it — would you merge?" Let them think aloud for 30 minutes, then 15 minutes of discussion.

What you're grading — in order of importance:

1. Do they question the design before the syntax? Seniors ask "what happens when the webhook fires twice?" before they comment on naming. Vibe-coders fix typos on the deck of the Titanic.
2. Do they find the security hole? Unverified webhook input is a real-world breach pattern, not an academic gotcha. Missing it is disqualifying for a senior claiming production experience.
3. Do they interrogate the tests? The strongest signal in the whole exercise. A senior reads the tests first, notices they assert almost nothing, and says so. Almost no vibe-coder ever looks at the tests critically — passing green checkmarks are the whole point of their workflow.
4. Would they merge it? The correct answer is no, with a specific list of what must change and — this matters — what's fine as-is. Blanket rejection is as junior as blanket approval. Senior judgment includes knowing what not to fix.

You don't need to be deeply technical to run this. The flaws are planted, so you have the answer key. You're watching for whether they find what you already know is there, and how they talk about it.

Block 3 — Architecture under constraint (15 minutes)

One question: "You have three weeks and just you to take this feature to production for 10,000 users. Walk me through what you build, what you buy, and what you refuse to build."

You're not grading the architecture — you're grading the constraint-handling. Seniors immediately start cutting scope, naming boring proven tools, and stating what they'd punt on and what signal would trigger revisiting it. Vibe-coders describe an ideal system with no relationship to three weeks, because they've never been the person accountable for the deadline. Anyone who says "with AI I could build all of it" has just told you they've never maintained what they generated.

The red-flag checklist

Print this. Any two of these, stop the process:

• ❌ Can't name a specific incident where AI output was wrong and they caught it
• ❌ Can't name anything they've deleted or rejected from AI output
• ❌ "If the tests pass, it works" — in any phrasing
• ❌ Never reads the tests during the code review, or reads them last and uncritically
• ❌ Misses the security flaw entirely, even with a hint ("anything worry you about the endpoint itself?")
• ❌ Reviews syntax and style before design and failure modes
• ❌ All-or-nothing merge verdict with no severity ranking
• ❌ Estimates that ignore the constraint ("three weeks is plenty for all of it")
• ❌ Can't explain a piece of "their" past code when you drill into the why
• ❌ Talks about AI as either magic or garbage — seniors talk about it like a power tool with known kickback

And the green flags, because this cuts both ways: they read tests first, they ask about idempotency and abuse cases unprompted, they have specific scar tissue, they say "I don't know, here's how I'd find out," and they treat the AI's output the way a staff engineer treats an eager junior's PR — with respect and zero trust.

What this means for your hire

The fear that keeps founders defaulting to a "safe" traditional hire — or skipping AI-using candidates altogether — is that AI-native means junior in disguise. Sometimes it does. That's exactly why the screen matters: the answer isn't avoiding engineers who use AI, it's testing for the judgment that makes AI leverage safe. A senior AI-native engineer is a senior first — the AI multiplies judgment that already exists. A vibe-coder is a multiplication by something less than one.

Ninety minutes. One postmortem interrogation, one rigged code review, one constraint question, one checklist. Cheaper than a mis-hire by roughly six months of runway.

Steal this framework and run it yourself — it works on FT candidates, freelancers, and agencies alike. Or skip the interviews entirely: this is the bar every Exit Code engineer clears before we ever put them in front of you. If you'd rather start with someone pre-vetted, talk to us.