When interviewers run an AI-enabled coding interview, they're not primarily grading whether your solution is correct at the end. The AI could produce a correct solution on its own; that wouldn't tell them anything about you. What they're grading is how the work happened — the behaviours you demonstrated while the AI did the typing.
Across the companies running these interviews, the rubric converges on five skills. Here's what each one looks like, and how to show it.
1. Orienting — reading the codebase
Before you write a line or prompt the AI, you need a map. Interviewers watch whether you actually read the code you've been handed: what modules exist, what the conventions are, where the bug you're asked to fix lives, how the pieces connect.
Good: "Let me look at how this repo is structured — there's a service layer and a routes layer, and the failing test is in the service. Let me find where this function is called before I change it."
Bad: Opening the AI chat before reading anything, and asking it to fix a bug in a codebase you've never looked at.
Orienting is the difference between asking the AI to "add a searchByPrefix method to the Dictionary class" (specific, fits the architecture) and "make this work" (generic, fits nothing).
2. Planning — deciding before you prompt
The AI answers instantly, which is exactly why planning is now a distinct, observable skill. If you don't decide the approach first, the AI's first answer becomes your plan by default — and the interviewer can see that you didn't choose it.
Good: "The problem needs a trie. I'll build insert and prefix search, then optimize by storing end-of-word flags. Let me ask the AI to implement that."
Bad: "Let me ask the AI what data structure to use" — and then accepting whatever it says without weighing alternatives.
The giveaway interviewers look for is ownership: you can name the approach and the reason for it, even if the AI wrote every line.
3. Driving the AI — prompting at the right granularity
Most of the interview is active prompting. The skill is matching prompt specificity to the task: a clear what-and-how for tricky logic, an underspecified prompt for boilerplate, and a "be concise" instruction so you don't drown in output to review.
Good: "Implement BFS on the Grid class returning coordinates, using the existing getNeighbors method." — pins the approach, lets the AI handle syntax.
Bad: "Do it" — leaves every decision to the model, or pasting a paragraph so long the AI makes its own choices about what you meant.
Interviewers also watch for a specific judgement: when to write it yourself. If you can fix a small bug in thirty seconds, writing it yourself beats prompting — it signals you're not a prompt relay.
4. Verifying — not trusting the AI
This is the skill that's impossible to test in a traditional interview and central to an AI one. The AI will occasionally produce confidently wrong output, and your behaviour when it does is the test.
Good: Running the code after every generation, reading the output as it lands, and using tests as the target you hand the model. When output looks wrong, saying so out loud and investigating why.
Bad: Accepting generation output because it compiles, stacking multiple unverified changes, or letting a hallucinated API call stand because you didn't read it.
Interviewers are explicitly looking for whether you catch hallucinations, handle edge cases, and keep the build green. "That compiles and passes the suite — now I'm moving to the optimization phase" is the sentence they want to hear.
5. Communicating — two conversations at once
You're managing two audiences: the AI and the interviewer. The silence trap is the danger — under pressure, candidates go quiet and let the AI work, which reads as not thinking.
Good: Narrating intent before prompting ("I'm going to fix the parser bug, then add search with BFS"), reviewing output out loud ("I think this fails because the empty-input case isn't handled"), and using the AI's generation time to show reasoning.
Bad: Going silent for minutes while the AI generates, then presenting a wall of code you can't explain.
The interviewer can't grade reasoning they never hear. Communication is how your thinking becomes visible.
The rubric in a line
Problem solving and code quality still count — but in an AI interview they're downstream of the five behaviours. Show the behaviours and the code follows.
How to train the five skills
They're trainable, and they train best in the environment you'll face:
- Orienting and planning improve with a habit: before you prompt, write down what you're going to build and why. Two sentences is enough.
- Driving improves with practice on prompt granularity — get the AI to implement what you want, not what it guesses.
- Verification improves by making "run after every generation" a reflex, not an aspiration.
- Communication improves by narrating out loud during practice runs — it feels strange at first, which is exactly why it needs rehearsal.
The good news: all five are habits, and habits are built the same way as the algorithms you already know — deliberate, repeated practice in a realistic setting.
The short version
AI interviewers grade five behaviours: orienting, planning, driving, verifying, and communicating. The final code is evidence of those behaviours, not the point in itself. Practice the behaviours in an AI-enabled environment, under time, until they're automatic — and the rubric takes care of itself.