Driving the AI

You've oriented yourself and formed a plan. Now you're in the execution phase, where most of the interview happens — actively prompting, reviewing what the AI generates, and making steady progress through your plan. How you drive the AI here is what interviewers spend the most time evaluating.

Prompting at the right granularity

The single biggest lever during execution is how much you give the AI in each prompt. Too vague, and the AI makes all the decisions for you. Too specific, and you're dictating code line by line, defeating the purpose of having an AI at all.

The sweet spot is a clear what and how while letting it handle syntax:

Implement a trie (a prefix tree) that supports insert and prefix search, where each node stores a character and a boolean for end-of-word.

Match prompt specificity to task complexity. For tricky logic — a complex state machine — be precise about the approach, data structures, and constraints so the AI implements what you actually want. For boilerplate and repetitive code — five similar API endpoint handlers — a short underspecified prompt is fine. The AI knows standard patterns, and you're going to verify it anyway.

Also ask for concise output. AI tends to generate sprawling responses with lengthy comments and more abstractions than you need. Every extra line is something you have to review and potentially defend. A short "be concise" or "minimal comments" in your prompt goes a long way.

When to use AI vs. when to write it yourself

Not everything should go through the AI. If you can write something in 30 seconds — a small bug fix, a one-line change, renaming a variable — just write it. Prompting for these takes longer than doing it yourself, and it creates the impression that you can't code without assistance.

On the other hand, anything that takes you five minutes but the AI produces in ten seconds is a clear candidate for prompting: standard patterns, data-structure implementations you know are correct but tedious to type, test-case generation, boilerplate setup.

There's a nuance specific to interviews. In your day-to-day, prompting for everything makes sense — no downside to a second perspective. In an interview, the calculus differs: they're evaluating whether you're an engineer who uses AI as a tool, or a prompt relay who forwards output without owning the decisions. The interview has to surface your thinking. Asking the AI to propose an approach is fine, even smart, as long as you weigh the options and choose one for a reason rather than taking whatever it hands back.

Keep your code running

Run the code after every meaningful AI generation. Don't stack multiple changes without compiling in between — each generation might be individually correct, but they can conflict in ways that produce a cascade of errors when you finally run everything. Fix breakages before moving on. Never layer new code on top of broken code.

This also gives you natural checkpoints to narrate: "That compiles and passes the existing tests, so now I'm moving on to the optimization phase."

Close the loop for the agent

The section above is about you running the code. This one is about giving the agent a way to check itself.

An agent that can run the test suite, the typechecker, the linter, or a headless browser will catch a share of its own mistakes before you ever see them. An agent with no feedback signal hands you confident, unverified output every single time — and every error it makes becomes your problem to find. The difference in output quality is larger than any prompt-wording improvement you can make.

So spend a minute early making sure the loop is closed: confirm the test command actually runs, that a typecheck or lint exists, and then tell the agent to use them rather than assuming it will.

After each change, run `npm test` and `npm run typecheck` and fix anything they report before moving on. Don't tell me it's done until both pass.

One interviewer who hires on this round frames it as a question: are you using the agent to build the product, or to build the thing that builds the product? Setting up verification is how you get repeatable results out of a tool that is fundamentally non-deterministic — and it's visible to anyone watching.

When AI gives you bad output

AI will occasionally give you output that doesn't work or doesn't match what you asked. How you handle this matters more than whether it happens — the interviewer knows AI isn't perfect.

First, learn the common failure patterns so you can spot them fast:

Training data bias

Ask for a graph traversal solution and you'll often get the textbook LeetCode solution — complete and correct, but not necessarily the right fit for your problem's specific constraints. The codebase might already have utilities that make a simpler solution possible, or the problem has a twist that makes a different approach more efficient. Recognizing when the AI gave you a technically correct but strategically wrong answer is critical.

Verbosity

AI generates more code than you need, more abstractions than you asked for, more comments than are helpful. You end up with 150 lines where 60 would do, and now you have to understand and defend all of it. Ask yourself what can be simplified without losing functionality.

Design shortcuts

AI loves base classes, deep inheritance hierarchies, and over-engineered abstractions. It'll introduce a BaseProcessor superclass for two classes that share almost nothing, or wrap everything in a strategy pattern when a simple if/else would be clearer. These choices might not break anything, but they signal you accepted a lazy design without thinking critically.

Correctness shortcuts

The most dangerous category: AI will sometimes delete failing tests instead of fixing the underlying issue, use any to bypass type errors, add try/catch blocks that swallow exceptions, or hardcode values to make specific test cases pass. These are red flags to an interviewer — they suggest you either didn't notice or didn't care. Always scan generated code for these patterns before accepting it.

Recovery tactics

• Commit frequently (open-ended). If the AI goes off the rails and you have several bad generations layered on top of each other, rolling back to the last working state is almost always faster than manually undoing the damage.
• Watch for the "almost right" trap. When output is 90% correct, there's a strong temptation to patch the remaining 10% by hand line by line. That's usually slower than reprompting with a clearer request, and it produces messy half-AI, half-hand-edited code. If the output missed the mark, ask again properly.
• Don't switch models mid-interview. In open-ended formats you technically can, but it's rarely worth it. Reprompting with more specificity, or writing it yourself, is almost always faster than moving context to a different model.
• Sometimes the fastest path is dropping the AI. If you've spent two minutes fighting for output and you could type the ten lines in one minute, do that. It shows you're pragmatic and don't have a dependency on AI — which looks good.

The "nerfed AI" problem

We're not certain interview AI is deliberately weakened. What's more likely is that tools in structured interview environments lack the system prompts and context that Claude Code or Cursor have baked in, which makes them feel substantially less capable. The practical effect is the same: don't expect the interview AI to behave like your daily driver.

Multiple candidates at Meta have reported the interview AI feeling noticeably worse than what they practiced with. At Uber, candidates describe it as giving nudges rather than solutions. It might not point out bugs directly, give cryptic or incomplete responses, or refuse certain requests.

If you encounter this, adjust expectations and lean more on your own understanding. Use the AI for what it can do — generating boilerplate, explaining unfamiliar syntax, scaffolding basic structures — and handle the harder thinking yourself. The interview is partly testing whether you can work effectively with imperfect tools, which is what real engineering looks like most of the time.