AI fluency means a candidate can direct an AI coding tool toward a real outcome, catch it when it’s wrong, and make the judgement calls the tool can’t make on its own. You test it by watching how someone works with AI under a real constraint.

Most interview loops haven’t caught up to this yet.

It’s not “has this person used ChatGPT” or “do they know what an AI coding assistant is.” Nearly every candidate will say yes to that now, and it tells you almost nothing.

AI fluency is closer to a working relationship with the tool. Can the candidate write a prompt that gets a useful first draft. Can they spot when the output looks right but isn’t. Can they push back on a suggestion, redirect it, and know when to abandon the AI’s approach entirely and do it themselves.

That’s a skill with real range. Some candidates lean on AI without checking its work. Others avoid it entirely and lose the speed advantage. The strongest candidates sit in the middle: fast, but not blind.

Raw typing speed and syntax recall stopped being scarce the moment AI tools got good at both. What’s scarce now is the judgement to use those tools well.

An engineer who can direct an AI agent through a multi-step task, verify each step, and catch a subtle bug the AI introduced is more valuable than one who can write the same code slightly faster unaided. The second skill is table stakes. The first is the actual differentiator on most engineering teams today.

Give them a real task with an AI tool available, not banned. Then watch three things:

How they prompt. Vague prompts get vague output. Strong candidates give the AI enough context and constraint to get something usable on the first or second try.

How they verify. Do they read the output critically, or accept it because it compiles. This is where weak AI fluency shows up fastest. A candidate who ships whatever the model hands them without checking it is a risk, not an asset.

How they recover. When the AI’s approach is wrong, do they notice, and do they know how to redirect it or take over manually. This is the single clearest signal of real fluency versus surface familiarity.

It looks like a candidate narrating their reasoning as they work with the tool, not just producing output. “I’m going to have it draft the function, then I want to check the edge case around null input myself because that’s usually where it gets sloppy.” That sentence tells you more than a perfect algorithm solution ever could.

Weak AI fluency looks like silence followed by a paste. No narration, no verification, just acceptance of whatever came back.

AI fluency doesn’t replace fundamentals. It sits alongside them. A candidate can be fluent with AI tools and still not understand what the generated code is actually doing, which is exactly why fundamentals still get tested. And AI fluency alone doesn’t tell you whether someone can reason through tradeoffs when there’s no clear right answer, which is what judgement is for.

This is the structure behind HackerRank’s Plan/Build/Review framework: Plan for approach, Build for execution with AI tools present, Review for the reasoning underneath it. Chakra, HackerRank’s AI interviewer, probes that reasoning live, the same way a technical interviewer would, at a scale most engineering teams can’t staff for on their own.

Testing for AI fluency isn’t an add-on question type. It’s a rethink of what the interview is actually measuring. Teams that treat it as a bolt-on will keep hiring for a skill that’s already table stakes and missing the one that isn’t.