How to practice for an AI-allowed coding interview

Practice the work around the agent. Write a clear scope before it touches code, steer it one small step at a time, check every change it makes, and keep the project in a working state from start to finish. Do that on real, ticket-sized projects with the agent you expect to use, then read back your own session the way an interviewer would.

That is the short answer. The rest of this post covers which rounds now allow AI, what interviewers watch for when you use an agent, the mistakes that sink candidates who are otherwise strong, and a weekly routine you can start tonight.

Which coding interviews let you use AI now?

The formats differ, and it helps to know which one you are walking into. Three examples from the past year show the range.

Meta runs an AI-enabled coding round that, according to Coditioning's guide, lasts 60 minutes in CoderPad with an AI-assist chat window. The guide says candidates started getting it in early October 2025, and it lists four areas interviewers assess: problem solving, code development and understanding, verification and debugging, and technical communication. Coditioning also stresses that the round is mainly about your coding skill, with the AI treated as a tool.

CodeSignal launched agentic coding assessments in April 2026. Its press release says candidates interpret product or technical requirements, use agentic tools such as Claude Code, Cursor and Codex to build a working solution, and then explain their decisions to a human reviewer.

And on 2026-10-05, TechCrunch reported that HackerRank made Chakra, an AI agent that conducts interviews and observes candidates as they work, generally available to its customers. HackerRank says Chakra ran more than 500,000 interviews during testing, and that it wants to assess critical thinking, judgment and what it calls AI fluency.

So you might get a chat panel inside a browser IDE, a full coding agent on a real task, or an AI that runs the interview itself. In all three, the AI does a lot of the typing, so what gets graded is your judgment about what to ask for and what to accept.

What do interviewers look at when you use an agent?

Interviewers can see the whole session: your prompts, the diffs the agent produced, what you ran, what you changed back. They are reading four things from it. For the hiring-side view in more detail, see what interviewers see when candidates direct AI agents.

How you scope the task

Before the agent writes anything, can you say what done means? A good scope names the inputs and outputs, the edge cases you care about, the parts of the codebase that should not change, and the order you plan to build in. Interviewers notice when a candidate pastes the whole problem statement into the agent and waits. They also notice when a candidate spends two minutes reading the existing code, asks one clarifying question, and then gives the agent a narrow first step.

How you direct and correct the agent

Agents go wrong in predictable ways. They invent an API that does not exist, rewrite files you did not ask them to touch, or solve a slightly different problem than the one in front of you. What matters is how quickly you notice and how precisely you correct it. "That's wrong, try again" is weak. "Keep the existing Book model, only add the isbn field, and don't touch the routes file" is strong, because it shows you read the diff and know what you want.

How you verify its output

Passing tests is necessary but not sufficient. Interviewers want to see you run the code, read the diff before accepting it, try an input the tests do not cover, and question anything that looks too convenient. Watch out for an agent that "fixes" a failing test by editing the test. Catching that out loud is one of the clearest signals you can give.

Whether the result keeps working

A session that ends with a big, broken change scores worse than one that ends with a smaller feature that runs. Keep the project working at every step: small changes, run after each, commit when green. If the agent breaks something, roll back instead of piling more prompts on top.

Where do strong developers lose points?

Most of the mistakes come from treating the agent like an autocomplete that happens to be very fast.

• Accepting large diffs unread. If the agent changed eight files and you approved all of them in one go, the interviewer has no evidence that you understood any of them.
• Going quiet. In a live round, silence while the agent works looks like you are waiting for it to save you. Say what you expect it to produce and what you will check.
• Prompt loops. Re-asking the same thing with slightly different wording, three or four times, instead of stepping back and narrowing the task.
• Skipping your own tests. Relying only on the tests the agent wrote, which tend to check what the code already does.
• Not knowing the tool. Losing time to finding how to undo a change, switch to a plan step or open a diff. These are things to learn before the interview day.

A practice routine on real projects

Toy prompts do not prepare you for this. You need real code that has existing structure, tests and some mess, and you need a clock. Here is a routine that fits into a few evenings a week.

Pick a ticket-sized task. Something you could finish in about an hour: a new endpoint in a side project, a bug from an open source issue tracker, tests for a module you did not write, or a practice challenge. Rotate the type each session, because interviews mix greenfield work, bug fixes and changes to unfamiliar code.

Use the agent you expect to get. If the company lets you bring Claude Code, Cursor or Codex, practice with that one. If the round gives you a chat panel inside a browser IDE, also practice with a plain chat window and copy-paste, because the workflow is slower and you need to plan for it.

Set a timer and write the scope first. Spend the opening minutes reading code with the agent closed. Write three to five lines: what done means, the edge cases, what you will not change. Then give the agent only the first step.

Work in small loops. Ask for a plan before code when the task has more than one part. Reject plans that try to do everything at once. After every change: read the diff, run the tests, try one input by hand, commit if it works.

Narrate as you go. Talk out loud or record yourself. It feels strange alone, but explaining your reasoning while the agent works is a skill, and it only gets easier with reps.

End with a working state and a short summary. When the timer runs out, stop. Write four sentences: what you built, what you checked, what the agent got wrong and how you caught it, and what you would do next. That last part is exactly the wrap-up interviewers ask for.

Review the session the next day. Read your prompts and your git log with fresh eyes. Ask yourself:

1. Where did I accept something I had not read?
2. Which correction took the most prompts, and what would have fixed it in one?
3. Did I test anything the agent did not test for me?
4. Was the project ever broken for longer than one step?

Pick one answer to work on in the next session. Changing one habit at a time works better than trying to fix everything at once. For a longer list of habits worth drilling, see how to practice coding with an AI coding agent.

Where kodwai fits

kodwai is a platform where developers solve real coding challenges on their own machine with their own AI coding agent (Claude Code, Cursor, or Codex) and get scored on how well they direct the agent, across three axes: Direction, Outcome, and Lift.

It is one way to get the timer, the realistic task and the after-session review from the routine above without setting them up yourself. The CLI downloads the problem, starter files and tests, starts a git repo and the clock, and when you submit it packages your code, git history, test runs and the agent transcript for scoring. The easy starter is a backend task with a 60 minute limit:

npx @kodwai/cli@latest challenge bookshelf-rest-api

When you are done, run npx @kodwai/cli@latest submit. The score is dominated by how you direct the agent, the part a careless prompt cannot fake. Direction carries the most weight, and its signals map closely to what interviewers watch: Spec Precision, Verification Rigor, Decomposition, Recovery, Intent Fidelity and Engagement. Each signal cites evidence from your transcript, commits and test runs, so you can see where a session went sideways. The score definition explains the three axes in more detail.

Solving challenges is free, and each developer account gets 3 scored submissions on kodwai's key. After that you connect your own Anthropic API key in Settings.

What it does not do: there is no human asking you follow-up questions, so it will not train the conversation part of a live round. Pair it with a mock interview with a friend or colleague who can interrupt you. And if your loop also has a classic algorithm round, LeetCode is still the right place for that.

Before the interview day

• Ask the recruiter exactly what is allowed: your own agent, a built-in assistant, or chat only, and whether you can use the internet and documentation.
• If you can use your own setup, test it on the same machine and network you will interview on.
• Know your agent's controls for undo, plan steps and viewing diffs well enough that you do not have to look them up.
• Use only the tools the company allows. Interviewers can see the session, and the round exists to measure how you work with the tools they gave you.
• Run one full timed practice session in the two days before, then stop practicing and rest.

If you want a ready-made task for your next practice session, run the bookshelf challenge above, then read your own transcript the next day with the four review questions in hand.