How to Interview Junior Developers in the Age of AI

Most of us are still interviewing junior developers the way we did in 2015. We ask them to reverse a linked list on a whiteboard, recite the time complexity of quicksort, and — my personal favorite — we hand them a take-home task and tell them, with a straight face, "please don't use AI for this."

It's theater. And worse, it's theater that filters for the wrong people.

I've hired and mentored junior engineers for years, and the tools have changed underneath us. Claude Code, Copilot, and the rest now do the things we used to test for. Syntax, boilerplate, the API call you half-remember, the first draft of a function — that's all solved. If your interview is built around skills a model performs in two seconds, you're not measuring the candidate. You're measuring how well they memorized things they will never type by hand again.

So let me share how I actually interview juniors now, and what I look for instead.

What AI changed — and what it didn't

Here's the honest split.

AI is excellent at the how: how to write the loop, how to call the library, how to scaffold the project, how to fix the red squiggle. A motivated junior with Claude Code open can produce working code on day one. That genuinely used to take months.

AI is still useless at the what and the why. It will not tell you what the business actually needs. It will not notice that the requirement is contradictory. It cannot judge whether its own output is correct in your context, with your constraints, against your real users. It does not own the outcome.

That gap is the entire job. And it's exactly what your interview should be measuring. Stop testing the half the machine does. Test the half that's now scarce.

I look at five things.

1. Problem-solving and decomposition

This is the one that matters most, and it's the easiest to test once you stop being precious about it.

Give the candidate a problem that is deliberately vague and a little messy — the way real work arrives. Not "implement a stack." Something like: "We're getting complaints that our nightly report email is sometimes wrong. How would you approach this?" There's no clean answer. There's no single algorithm. There's a fog you have to walk into.

Then watch. Do they ask clarifying questions before diving in? Do they break a fuzzy problem into parts? Do they reason about trade-offs out loud, or do they freeze waiting for the "right" answer? Can they say "I don't know yet, but here's how I'd find out"?

And let them use AI while they do it. I'll say it plainly: I want to see them open the tool. Watching how a junior decomposes a problem with an AI assistant in the loop tells me more than any closed-book whiteboard ever did.

Ask: "Walk me through how you'd start." "What would you check first, and why?" "What could make this harder than it looks?"

2. Technology awareness, not recall

I don't care if they remember the exact signature of Task.WhenAll. I care whether they know it exists, what it's for, and when reaching for it is a bad idea.

Junior engineers don't need depth of memory anymore — the model has that. They need breadth and judgment: a mental map of the landscape, and a sense of when to use what. Do they know the difference between a queue and a database, and when each is the wrong tool? Have they noticed why a technology choice mattered on something they built?

I probe for awareness, not trivia. "You used Postgres on that project — do you know why the team picked it over something else?" A great junior lights up here even if their answer is incomplete. A weak one just shrugs: "It's what we used."

3. How they actually worked before — even if it was an internship

This is the part most interviewers skip, and it's the most revealing thing in the entire conversation.

I dig — really dig — into what they did before. I don't care if it was a three-month internship or a student project. I care how involved they actually were. There's a world of difference between a junior who closed assigned tickets and a junior who understood why those tickets existed.

Because here's what I want, even from someone on their first job: I want someone who understands the business problem and then goes and finds a technical solution for it. That instinct — connect the code to the reason it's being written — is the single best predictor I've found of who becomes a strong engineer. And you can absolutely spot it in a junior. It shows up in how they talk about past work.

So I ask the questions that separate "I did tickets" from "I owned a problem":

• "What was the team actually trying to achieve with that project?"
• "Who used the thing you built, and what did they need from it?"
• "Was there anything you pushed back on, or suggested changing?"
• "If you could redo that project, what would you do differently — and why?"

The candidate who only ever saw their own ticket gives you a thin, mechanical answer. The one who understood the why will tell you about the users, the constraint, the trade-off, the thing that almost went wrong. Hire that one.

4. How they use the tools

AI fluency is now a core engineering skill, so test it the way you'd test any other — openly, not by pretending it doesn't exist.

When they use Claude or Copilot in front of you, watch how. Do they write a clear, specific prompt, or a vague one and hope? When the model hands back code, do they read it and reason about it — or paste it and pray? Crucially: can they smell when the AI is wrong? Do they verify the output against the actual requirement, or trust it because it looks confident?

The junior I want treats AI like a sharp power tool: fast, useful, and respected because it can hurt you if you're careless. The one I worry about treats it like an oracle. Same tool, completely different engineer. You only see the difference if you let them use it in the room.

5. Teamwork and communication

Software is a team sport, and AI makes the human parts more important, not less — because when anyone can generate code, the bottleneck moves to alignment, judgment, and communication.

So I look at how they collaborate. Can they explain a decision so a non-expert follows it? How do they take feedback — defensive, or curious? Can they disagree with me well, without either caving instantly or digging in? When they hit something they don't understand, do they go quiet or do they ask?

A junior who communicates clearly and takes feedback gracefully will outgrow a "smarter" one who can't, every single time.

A better interview, in practice

Throw out the algorithm gauntlet and the no-AI take-home. Replace them with one realistic task and an honest conversation.

For the take-home, give something small, vague, and real, and say so explicitly:

Build a small tool that takes a CSV of customer orders and flags the ones
that look suspicious. "Suspicious" is intentionally underspecified — part of
the task is deciding what it should mean and why.
 
Use any AI tools you like — Claude, Copilot, whatever you'd actually use at
work. We're not testing whether you can type code from memory. We care about
how you think, what you decide, and how you check that it's right. Include a
short note on the choices you made and anything you'd do with more time.

Then score against what actually matters. Here's the rubric I use — steal it:

We're not hiring typists

The era of testing juniors on syntax is over, and good riddance. We were never really hiring people to type code — we were hiring people who turn business problems into working systems. AI just removed a lot of the typing and threw the real skills into sharp relief.

So interview for those. Hire the junior who walks into a fuzzy problem and starts asking the right questions. Who understood why they were building things, even as an intern. Who wields AI with judgment instead of faith. Who you'd actually want in the room when something breaks.

The tools got better. The bar didn't drop — it moved. Make sure your interview moved with it.