September 28, 2026·5 min read
A wave of junior engineers is entering the market who have never written a function without autocomplete. They grew up debugging with Claude, not with Stack Overflow and trial and error.
Some of them are genuinely capable. Others are fragile in ways that do not surface until they are already hired.
Here is how to tell them apart.
A strong AI-native junior moves fast on greenfield work. They are comfortable with unfamiliar tools, write reasonable tests, and iterate quickly. Their weakness is not speed. It is the moment the AI's advice is wrong and they do not have enough foundation to notice.
That is the specific thing to test for.
Give them a small project and tell them to use Claude or any AI tool they want. That part is normal.
Build in one trap: a specific step where Claude's natural suggestion is plausible but wrong. It could be a subtle security assumption, a race condition, or an approach that works locally but fails under any real load.
Then watch the recording.
Did they catch it? Did they run a test that would have caught it? Or did they paste and submit?
Run the same candidate through two sessions on the same task. One with AI tools available, one without.
The gap between the two results is the signal.
A junior who performs reasonably in both is genuinely learning. A junior who scores very high with Claude and struggles completely without it has a skill floor you need to know about. Not because AI-assisted work is invalid, but because the skill floor is what shows up when Claude is wrong and they cannot tell.
EasyEnv lets you set up both versions of the interview under the same role. The two recordings sit side by side for a senior to compare. It takes about fifteen minutes to read the difference.
After the session, ask them to walk you through one decision Claude made. Ask why they accepted it. Ask what they would do if Claude gave conflicting suggestions in two different prompts.
If they have never thought about verifying AI output, that is the real answer.
An AI-native junior is not a worse hire by default. They are a different profile. The question is whether they have the judgment to direct AI tools, or whether they are depending on AI to cover gaps they have not yet closed.
Two sessions will not tell you everything. They will tell you considerably more than one.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Teams hire platform engineers on Kubernetes depth and Terraform fluency, then wonder why nobody notices the invoice climbing. Cost awareness is an engineering skill, it is easy to test on a running environment, and almost nobody tests it.
Under the EU AI Act, AI used to screen or evaluate candidates sits in the high risk category. Here is what that actually asks of you as an employer, the questions to put to your assessment vendor, and how to structure a process you could defend.
Read more
When the model has shell access, the question is no longer whether a candidate can write the code. It is whether they can supervise something that writes it faster than they can read it. Here is how to test that on a real repository.
Read more
