To prepare for a coding interview with an AI interviewer, practice solving problems while narrating every step out loud: restate the problem, offer a brute-force idea, state your better approach and its complexity before you type, then test with a normal case and an edge case. An AI interviewer can't read your mind, and when a session is recorded or transcribed, your spoken reasoning is the only evidence of how you got to the code. This is a preparation guide: you take the real session yourself, and practice beforehand is where the improvement happens.
How a coding interview with an AI interviewer works
Coding rounds led by an AI are now part of some early screens. As of October 2026:
- micro1's AI interview guide lists a coding challenge for technical roles as part of its interview with Zara, its AI interviewer.
- micro1 also tells some technical candidates to expect technical questions that test architecture, problem-solving and code reasoning.
- Mercor's AI interview guide says some interviews are technical and involve deep discussion of prior experience, and its rules ask candidates not to use large language models to compose their responses.
Beyond that, formats vary by platform and employer. You might solve a problem in an online editor while an AI voice asks questions, talk through how you'd approach code without running it, or complete a coding exercise after a spoken interview. Some set-ups run your code against test cases, some score how you explain it, and some do both. Before the day, check your invitation or ask the recruiter four things: which languages are allowed, whether code is executed, how long you have, and whether you'll be asked to explain your solution out loud.
What may be evaluated: your code and your explanation
Rubrics differ, so treat this as a checklist of what coding rubrics commonly cover, not any vendor's formula. The right column is what makes each area visible to a reviewer who only has your code and transcript.
| Area | What reviewers may look for | How to show it out loud (example lines) |
|---|---|---|
| Understanding | Restated constraints and sensible assumptions | "Can the input be empty? I'll assume it can and return an empty list." |
| Approach | A plan before code, and awareness of alternatives | "Brute force checks every pair, O of n squared. A hash map gets it to O of n." |
| Correctness | Code that works, including edge cases | "Let me trace the first example by hand before running it." |
| Complexity | Accurate time and space analysis | "O of n time, and O of n extra space for the map." |
| Code quality | Readable names and simple structure | "I'll call this seen: it maps each value to its index." |
| Testing | Finding your own bugs | "This breaks if the same number appears twice. I'll check before inserting." |
| Communication | Clear, ordered reasoning | "I've got a working version. Now I'll test, then tidy up." |
For the interviewer's side of the same checklist, see what to look for in a coding interview.
A think-aloud script for each phase
- Understand (one to two minutes). Restate the problem in your own words, name the input and output, and ask or state one assumption. "So I return the indices, not the values, and there's exactly one answer."
- Plan before typing. Give the brute-force idea in one sentence, then the better approach and its complexity. Saying the plan first means that even unfinished code shows a sound approach.
- Code in narrated chunks. Say what the next block does, then write it. "Now the loop: for each number, I'll check whether its complement is already in the map." Short bursts of quiet typing are fine.
- Flag silences. If you need a minute, say so: "I'm going to write the loop now; give me a moment." Mercor notes that extended silences may trigger its AI to interject, and other platforms may behave similarly.
- Test out loud. Trace one normal example step by step, then one edge case: empty input, one element, duplicates or negatives.
- Wrap up. Restate the final complexity and one improvement you'd make with more time.
If thinking aloud feels unnatural, our guide to practicing thinking out loud in coding interviews has drills that build the habit in about two weeks.
Example: narrating a two-sum solution
Problem: given an array of integers and a target, return the indices of the two numbers that add up to the target. The narration below is an example we wrote to show the pattern.
Example narration: "Let me restate it: I get a list of integers and a target, and I return the two indices whose values add up to the target. I'll assume there's exactly one valid pair and I can't use the same element twice. The brute-force way checks every pair, which is O of n squared. A better way is one pass with a hash map from value to index: for each number, I check whether target minus that number is already in the map. If it is, I return both indices; if not, I add the current number. That's O of n time and O of n space. I'll write it in Python. ... Done. Let me test with 2, 7, 11, 15 and a target of 9. At index 0, I need 7, which isn't in the map, so I store 2. At index 1, I need 2, which is in the map at index 0, so I return 0 and 1. Edge case: the list 3, 3 with a target of 6. At index 1, the first 3 is already stored, so it returns 0 and 1, which is correct because I check before inserting. Final complexity is O of n time and space."
| Version | What the transcript shows (example) | What a reviewer learns |
|---|---|---|
| Before | "Okay... so... I'll just use a hash map, I think. [six minutes of silence] Okay, I think that works." | Almost nothing: no plan, no complexity, no testing, and no evidence of why a hash map |
| After | Restated problem, one assumption, brute force and its cost, the hash map plan with O of n time, a traced example and a duplicate-value edge case | Understanding, approach, correctness, complexity and testing, each in quotable sentences |
Common mistakes in AI-led coding rounds
- Coding in silence and explaining only at the end, when time may run out.
- Starting to type before stating a plan, which hides your reasoning if the code is unfinished.
- Skipping complexity, or giving it without a reason.
- Declaring "done" without a test, even a hand-traced one.
- Ignoring the follow-up. If the AI asks "can you do better on space?", answer that question before anything else.
- Switching to an unfamiliar language because you think it looks better. Use the one you're fastest in, if it's allowed.
- Assuming the AI saw something you didn't say. If an insight isn't spoken or written, it isn't in the record.
Our full list of coding interview mistakes covers the general ones.
A one-week practice plan for coding with an AI interviewer
- Days 1 and 2: patterns. Review the core patterns on the free coding interview cheat sheet and check your complexity intuition with the Big-O complexity visualizer.
- Days 3 and 4: narrate. Solve two easy problems a day out loud, recording yourself. Play it back and check that each of the six phases is audible.
- Day 5: scored mock. Our free AI interview assistant includes a Mock Interview mode where you choose coding in the question mix and set your coding language. It reads each question aloud and scores your answer out of 10 with what to fix and a model answer. Coding questions never auto-submit, so you can take the time you need while you practice narrating. The free plan includes 15 minutes every day.
- Day 6: variety. Answer single coding and system design questions in the browser demo at /try, which has 145 real interview questions across 10 tracks, graded by AI.
- Day 7: full run. One timed problem, start to finish, narrated, then a rest.
Take the assessment yourself and follow the employer's rules — use CoPilot Interview to practice beforehand. If your round also includes spoken technical questions, read technical questions in an AI voice interview, and for platform-specific detail see our micro1 AI interview guide.
Rehearse the narration, not just the code
Mock Interview includes coding in the question mix, in your chosen language, and scores each answer out of 10 with what to fix, so thinking aloud feels normal before the round that counts.
Try a free AI mock interviewFAQ
Can an AI interviewer run a coding interview?
Yes, on some platforms. As of October 2026, micro1 lists a coding challenge for technical roles in its AI interview, and Mercor says some of its AI interviews are technical. The format, language options and whether your code is run depend on the platform and the employer.
Does the AI evaluate my explanation or just my code?
It depends on the platform. Some set-ups run code against test cases, some score your explanation from the recording or transcript, and some combine both. Assume both matter: working code shows correctness, and your narration shows understanding, approach and testing.
Which programming language should I use?
The one you can write fastest and most accurately, if the platform allows it. Check the invitation for the allowed languages, and practice in that language with the same kind of editor before the day.
What should I do if I get stuck?
Say where you are stuck and why, then fall back to a simpler working solution, such as brute force, and state its complexity. A correct slower solution with a clear explanation usually shows more than an unfinished clever one.
Can I use AI tools during an AI coding interview?
No. Do the session yourself and follow the platform's and the employer's rules. Mercor, for example, asks candidates not to use large language models to compose their responses. Use AI tools to practice before the interview, not during it.
How do I practice thinking aloud when I practice alone?
Record yourself solving easy problems and play the recording back. Check that you restated the problem, gave a plan and complexity before coding, tested out loud and wrapped up. A scored mock interview adds feedback on what to fix.