Let candidates use AI tools in the interview. Banning them tests a skill nobody uses on the job anymore, and it tells you nothing about how the candidate will actually perform once they’re hired.

The harder question isn’t whether to allow AI in the interview. It’s what to test once you do.

Yes, with intention. HackerRank co-founder and CEO Vivek Ravisankar frames the underlying shift this way: the role of a developer is changing to become an orchestrator of AI agents. If that’s the job now, testing candidates in an AI-free room measures a version of the job that doesn’t exist anymore.

The concern most teams raise is fairness: won’t AI access flatten the differences between candidates. It doesn’t. Access to the same tool doesn’t produce the same output. Two candidates with the identical AI assistant available will still produce very different results, because the differentiator has moved from typing the code to directing, verifying, and reasoning about it.

The interview stops measuring recall and starts measuring workflow. That’s a bigger shift than it sounds like.

A candidate working without AI is mostly showing you what they remember. A candidate working with AI is showing you how they think: what they delegate, what they double-check, where they push back on a suggestion versus accept it. That’s closer to what Ravisankar means when he talks about engineers who build with care and taste, and it’s closer to how they’ll actually work on your team.

It also changes what a strong answer looks like. Fast, clean output is no longer impressive on its own, since the AI can produce that. What’s impressive is a candidate catching the AI’s mistake before it ships, or redirecting an approach that was heading somewhere wrong.

Watch the moments where the AI’s first suggestion isn’t quite right. That’s where judgement shows up.

Strong candidates notice the gap between what the AI produced and what the problem actually needs. They’ll say something like “this handles the common case but I don’t think it’s checking for the edge case we talked about,” and then either redirect the AI or fix it themselves. Weaker candidates accept the output at face value because it looks plausible and compiles.

You’re not scoring whether the final code is correct. Correct code is now the easy part. You’re scoring whether the candidate understood why it was correct, or got there by accident.

Debug-and-explain. Give the candidate AI-generated code with a subtle bug and ask them to find it, using AI tools if they want. This tests verification skill directly.

Multi-step build with a twist. Have them build toward a goal with AI assistance, then introduce a changed requirement halfway through. Watch how they redirect the tool, not just how they redirect themselves.

Approach comparison. Ask them to generate two different approaches with AI, then defend which one they’d actually ship and why. This tests judgement more directly than almost any other format, since there’s no single right answer to hide behind.

This is the structure behind Plan/Build/Review: Plan surfaces the candidate’s approach before code gets written, Build lets them work with AI tools present the way they actually would on the job, and Review probes the reasoning behind what they built and why. Chakra, HackerRank’s AI interviewer, runs that Review conversation live and consistently, at a scale no engineering team could reasonably staff themselves.

The goal isn’t to make the interview harder. It’s to make it accurate. An interview that bans the tools your team uses every day was never testing the job. It was testing a version of the job that stopped existing.