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.

Narrating your process

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 it, they're watching you type a prompt and waiting to see what happens — which makes it impossible to evaluate whether you're making good decisions.

After the AI generates code, narrate what you see. All of these are good signals:

The first shows you can verify 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.

The rhythm that works best is: state intent → prompt the AI → review the output out loud → 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 expectations, and what you're doing next.

At Shopify, interviewers specifically want the interview to feel like a pairing session, not like watching someone chat with a bot. Think of the interviewer as your pair partner. You wouldn't silently type at a pair partner for five minutes and then show them the result — you'd talk through what you're doing as you do it.

Using wait time productively

AI doesn't always respond instantly, especially in structured environments where 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, walk through how you expect the generated code to work. This fills what would otherwise be dead air with exactly the 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, parallelize: while the AI generates the implementation for step two, start reading the code you'll need for step three, sketch test cases for the current step, or think through edge cases. That makes you faster overall and shows you're thinking ahead rather than waiting passively.

Say what you expect before it arrives

There's a stronger version of this, and it's the highest-leverage habit in an agent-driven round: state your acceptance criteria before you hit enter, not after the output lands.

The reason is about what an observer can actually verify. When you review a diff after it appears, nobody in the room can tell the difference between "I had criteria and this meets them" and "I read it and made my peace with it." Both look like a person nodding at a screen. Announce the criteria first and the same review becomes a checkable claim.

I'm expecting a reducer with three cases and no data fetching inside the component. If it inlines the fetch or reaches for a global store, I'm throwing it away and re-prompting rather than patching it.

Two sentences, said into dead air that was going to exist anyway, and now your judgment is on the record — including the part where you'd reject the output. It's the same reason engineers write the test before the fix.

Solve it yourself while it works

The other high-value use of that window: work the problem out loud as though the agent weren't there.

One candidate's account of a round they passed ran roughly like this — ask clarifying questions, prompt the agent, set it running, then narrate their own approach from scratch while it worked. When the agent finished, the two solutions were nearly identical apart from one choice, and the candidate explained the difference between the two rather than just accepting what came back. The interviewers then asked for a requirement change by hand, and afterwards for the same change via the agent.

That sequence gives the room three things from one stretch of waiting: an independent solution, evidence you could have produced it unaided, and a specific technical comparison to talk about. Even when the agent's version wins, "mine was breadth-first, it went depth-first, and here's why that's the better call for this input" is a far stronger artifact than silent approval.

Communicating when things go sideways

The tactical side of getting unstuck is covered 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 — they'd much rather see you ask and keep moving than watch you silently burn 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 switching to a heap-based solution instead.

That one sentence shows 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.

Interviewers who run these interviews typically know the problem cold. They've watched dozens of candidates solve it and know exactly where the dead ends are. They're not expecting you to avoid every one — some are hard to see ahead of time. What they're evaluating is whether you notice when you're in one and how fast you recover. "Went down a dead end, recognized it, pivoted cleanly" is a much stronger signal than "ended up with a suboptimal solution and burned ten minutes tuning around the underlying problem."

Balancing speed with clarity

There's a real tension between moving fast and communicating well enough for the interviewer to follow. You can't narrate every keystroke, and you shouldn't try. 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 is roughly 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.