Protocol

The AI-assisted round

What interviewers watch for when you are allowed to use an AI coding assistant.

More companies now run a round where you are allowed, and sometimes required, to use an AI coding assistant. Candidates tend to read this as the easy round. In my experience it is the hard one. The assistant takes recall off the table, so what is left on display is your judgment. The interviewer already assumes the model can produce plausible Node.js code. They are watching whether you can direct it, verify it, and stay accountable for what it produces.

What is actually being tested

Once code generation is cheap, three skills stay scarce. You have to frame a problem well enough to hand part of it off. You have to tell a correct answer apart from a confident one. And you have to own the result. Paste the assistant's first output and move on, and you fail the round even when the code happens to run, because you showed none of that. Lean on the assistant heavily but treat it as a fast, untrusted collaborator, and you pass.

Direct the tool with a hypothesis

Interviewers want to see you drive. Before you prompt, say out loud what you expect and why, then hand the assistant a scoped, checkable task instead of the whole problem. "This leaks file descriptors under load; list every call in this handler that opens one and tell me whether it is closed on every exit path" is a good prompt. "Why is this slow" is a weak one. Say why you scoped it that way. A bounded question comes back with a checkable answer. An open one comes back with a plausible essay. When you own the hypothesis, you are driving the tool instead of being driven by it.

Verify, never trust

Treat every claim from the assistant as a draft you confirm against something outside the model. That means the runtime and the documentation. If it says the code is correct, run it. If it says it tested the code, ask to see the test, read it, and run it yourself. A model that claims it "tested" something has usually run nothing. Aim your scrutiny where models are weakest in Node. That is hallucinated or version-drifted APIs, dropped error paths, unhandled stream error events, backpressure, and resource cleanup. Say it out loud, something like "I will confirm this against the docs and by reproducing it, I am not taking it on faith." That sentence is what the interviewer wants to hear.

Stay accountable

The interviewer wants to hear that you own what you merge, as if you had typed it yourself. "The AI wrote it" is never an explanation for a bug. Push back when the assistant hand-waves, ask it to justify a choice, and reject any answer you cannot verify. A candidate who says "I do not understand why this works yet, so I am not shipping it" scores higher than one who ships working code they cannot explain.

What good sounds like

You use the assistant to compress search and drafting. That is boilerplate, an API shape, a first cut at tests. You keep the hypothesis, the acceptance test, and the decisions that matter in your own hands. Every claim the model made is something you confirmed yourself before you believed it, and you can say precisely why the final code is correct. You end up faster because of the tool and accountable for the result regardless of it.