Communication

Communication in an AI-enabled interview is harder than in a traditional one. You're managing two conversations at the same time, one with the AI and one with the interviewer, and the temptation is to let the AI conversation consume all your attention. The interviewer can see your prompts and the AI's output, but they can't see your thought process or evaluate your decision-making unless you show it to them out loud.

State what you're about to do before you do it. "I'm going to ask the AI to implement the input validation for the Order class" takes three seconds and gives the interviewer everything they need to follow along. Without this, they're watching you type a prompt and waiting to see what happens, which makes it impossible for them to evaluate whether you're making good decisions.

After the AI generates code, narrate what you see. "This looks right, it's checking for null fields and validating quantities, which is what I wanted" or "This isn't quite what I asked for, it's throwing exceptions instead of returning error objects like the rest of the codebase, so I'm going to reprompt." Or even just "This was a lot. Let me read through it and make sure it's doing what I wanted." All of these are good signals. The first shows you can verify AI output. The second shows you can catch mistakes and correct course. The third shows you're actually reviewing what was generated rather than just accepting it and moving on.

The rhythm that works best is: state your intent, prompt the AI, review the output out loud, then move on. You don't need to narrate every line of generated code, but you should narrate the decisions. Why you chose this approach, whether the output matched your expectations, and what you're doing next. These are the inflection points the interviewer cares about.

AI doesn't always respond instantly, especially in structured interview environments where the models can be noticeably slower than what you're used to. These pauses can feel awkward, but they're actually an opportunity.

Use the wait time to talk through your solution with the interviewer. Explain your approach, discuss why you chose this algorithm, or walk through how you expect the generated code to work. This fills what would otherwise be dead air with exactly the kind of reasoning the interviewer wants to hear. Some of the best interview moments happen during these pauses, because you're talking without the distraction of code appearing on screen.

Alternatively, use the time to parallelize. While the AI is generating the implementation for step two, you can start reading the code you'll need for step three, sketching out test cases for the current step, or thinking through edge cases. This makes you faster overall and shows the interviewer you're thinking ahead rather than waiting passively.

We cover the tactical side of getting unstuck and pivoting in driving the AI and planning your approach. The communication piece is simpler but just as important: narrate what's happening.

"I'm stuck on how to handle cycles in this graph. Do you have any suggestions?" is a perfectly fine thing to say. Asking the interviewer for help is collaboration, and interviewers would much rather see you ask and keep moving than watch you silently burn through five minutes going in circles.

When you need to change direction, say why. "This approach isn't going to work because the time complexity is too high for the larger inputs. I'm going to switch to a heap-based solution instead." That one sentence shows the interviewer you recognized the problem, understand why it's a problem, and have a plan to fix it. Silently deleting code and rewriting without explanation looks like confusion rather than adaptation, even if you know exactly what you're doing.

There's a real tension between moving fast to finish the problem and communicating well enough for the interviewer to follow your thinking. You can't narrate every keystroke, and you shouldn't try to. Focus on the inflection points: decisions, surprises, and corrections.

"I'm going to implement the search function next" is worth saying. "I'm going to type the word 'function' now" is not. The right level of narration is somewhere around one statement every 30-60 seconds during active coding, covering what you're doing and why.

If you need a quiet moment to think, say so. "Let me think about this for a second" is all it takes to turn potentially awkward silence into a reasonable pause. The interviewer knows thinking is part of the process. What makes silence uncomfortable is when they don't know if you're thinking, confused, or just reading code. A quick framing sentence resolves the ambiguity.

The candidates who nail this balance are the ones who practice it. Record yourself solving a problem with AI while narrating, then watch it back. You'll immediately see where you went silent for too long or where you over-narrated things that didn't matter. A couple of practice sessions and you'll find the rhythm that feels natural.