Vibe coding interviews: what they test and how to run one

A vibe coding interview is a timed round in which a candidate builds something working with an AI coding tool from a short, open-ended brief, explaining their decisions as they go. It's spreading across product and engineering loops. The name is the problem: "vibe coding" originally meant not reading the code. A useful vibe coding interview measures the opposite — how well the candidate scopes the task, directs the AI, verifies what it produces, and owns the result.

What is a vibe coding interview?

The term comes from Andrej Karpathy, who described in February 2025 a new kind of coding where "you fully give in to the vibes, embrace exponentials, and forget that the code even exists." By November, Collins had named "vibe coding" its Word of the Year, and the phrase had stretched to cover almost any AI-assisted building.

Interview loops picked it up in that looser sense. In practice, a vibe coding interview usually looks like this:

• A short, open brief."Build a tool that helps a support team triage tickets" rather than a fully specified function.
• An AI coding tool, explicitly allowed.Sometimes the candidate's choice, sometimes the company's standard tool.
• A working result in the time box. Typically under an hour or two, with the interviewer watching or reviewing afterwards.
• Narration and a debrief. The candidate explains what they built, what they cut, and why.

Vibe coding vs. AI-assisted coding: why the name matters

Simon Willison drew the line clearly in Not all AI-assisted programming is vibe coding: vibe coding is "building software with an LLM without reviewing the code it writes." That's fine for a weekend prototype. It's not what you're hiring for. The engineer you want uses AI heavily and still won't ship code they can't explain.

So a vibe coding interview has a built-in trap for the interviewer. If you score it on how quickly something impressive appears on screen, you reward the candidate who accepted everything the AI wrote — the literal vibe coder. The round only works if the scoring is about what happened between the prompts.

Which companies have vibe coding interviews?

Most public evidence is candidate reports, not company announcements, so treat it as directional. Aakash Gupta's Product Growth newsletter collects reports of a Meta PM round with 30 minutes of product sense followed by 30 minutes of vibe coding, and of vibe coding rounds at Google, Microsoft, and Adobe, among others. Separately, we've covered companies running AI-native coding interviews for engineers, which share the same core idea under a less loaded name.

Vibe coding interviews for engineers vs. product managers

The format looks the same in both loops; the bar is different.

• For product managers, the question is whether the prototype tests the right idea. Rough code is acceptable; building the wrong thing beautifully is not.
• For engineers, the question is whether the code is correct, understood, and safe to build on. A demo that works once on the happy path is the start of the assessment, not the end of it.

Mixing these up is a common failure: engineering loops that borrow a PM-style brief end up grading product taste and demo polish instead of engineering judgment.

What a vibe coding interview should test

Whatever you call the round, these are the things it can see that a whiteboard question can't:

1. Scoping. Does the candidate decide what to build — and what to cut — before prompting, or do they let the AI pick the shape of the solution?
2. Direction. Are prompts specific, with constraints and a definition of done, or vague and repeated when the output is wrong?
3. Verification.Do they read the diff, run the code, and check edge cases, or accept "it works" from the AI?
4. Override. When the AI goes the wrong way, do they notice quickly, stop it, and redirect or write the code themselves?
5. Ownership. Can they explain any part of what they shipped, including the parts the AI wrote?

These map closely onto how we'd assess AI fluency in software engineers more generally.

How to run a vibe coding interview

1. Write a brief with one real ambiguity.If a single prompt produces a finished answer, you're testing the model. Leave a requirement the candidate should ask about.
2. Start from something that exists. A small codebase, an API, or a dataset with quirks. Greenfield toy apps are where AI looks most capable and where candidates differ least.
3. Plant a mistake the AI is likely to make. A misleading field name, a timezone edge case, a data rule the obvious implementation breaks. Whether the candidate catches it is the most informative moment of the round.
4. State the AI policy in plain words."Use it the way you would at work." Without that, cautious candidates underuse the tool and you end up scoring their nerve.
5. Give enough time for a full loop. Build, check, find a problem, fix it. Too short and everyone just prompts and accepts.
6. Keep a record of the session. Prompts, AI actions, edits, and test runs. Without it, the debrief depends on what the interviewer happened to notice.
7. End with a walkthrough. Ask the candidate to explain one piece of AI-written code they kept and one they rejected.

If an interviewer will be pairing live rather than watching, see how to run an AI pair programming interview for what the interviewer should actually do in the room.

How to score a vibe coding interview

Score the process with evidence, then the result. A simple version:

• Strong signals: clarifies the ambiguity before building; rejects or rewrites AI output with a stated reason; runs the code and tests early; catches the planted mistake; can explain generated code line by line.
• Weak signals:pastes the brief straight into the tool; accepts large diffs unread; re-sends the same prompt when output is wrong; trusts the AI's claim that tests pass; can't explain parts of the final code.
• Not a signal on its own:how much the candidate used AI. Heavy use with careful review is a good sign; light use out of caution isn't a bad one.

Tie each judgement to a specific moment in the session. Two candidates can finish with the same working app, one having steered carefully and one having got lucky — the final output can't tell them apart.

When a vibe coding interview isn't the right round

It's a poor fit when the job rarely involves AI tools — some embedded, safety-critical, or regulated environments — or when you need to check fundamentals the AI would mask, such as reasoning about concurrency or memory by hand. It also shouldn't be the only technical round: a candidate who can't reason about code without the AI can't catch the AI's mistakes either. Pair it with a conversation that probes fundamentals, and see what technical interviews should measure in 2026 for how the pieces fit.

Where DeftBench fits

DeftBenchruns this kind of round without the vibes. The candidate works in a browser IDE with a real coding agent on an ambiguous problem; the session is captured as telemetry that attributes each action to the human or the agent; and the evaluation links each score to the moment that produced it, with a human making the final decision. It's pre-GA. For how that compares to incumbent platforms adding AI to their own assessments, see DeftBench vs Codility. If you're adding a vibe coding round to your loop and want it to measure judgment, get in touch.