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, we ask for the time complexity of quicksort, and then, my personal favourite, we hand them a take home task and say with a straight face, "please do not use AI for this."

It is theatre. Worse, it is theatre that filters for the wrong people.

I have hired and mentored junior engineers for years, and the tools changed under 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 version of a function. That is all solved. If your interview is built around skills a model finishes in two seconds, you are not measuring the candidate. You are measuring how well they memorised things they will never type by hand again.

So here is how I interview juniors now, and what I look for instead.

What AI Changed, and What It Did Not

The honest split is this.

AI is very good at the how. How to write the loop, how to call the library, how to scaffold the project, how to make the red squiggle go away. A motivated junior with Claude Code open can produce working code on day one. That used to take months.

AI is still useless at the what and the why. It will not tell you what the business needs. It will not notice that the requirement contradicts itself. It cannot judge whether its own output is right in your context, with your constraints, for your users. It does not own the outcome.

That gap is the job. It is also exactly what your interview should be measuring. Stop testing the half the machine does. Test the half that is now scarce.

I look at five things.

1. Problem Solving and Decomposition

This matters most, and it is easy to test once you stop being precious about it.

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

Then watch. Do they ask questions before they start? Do they break a fuzzy problem into parts? Do they think about trade offs out loud, or freeze while they wait for the right answer? Can they say "I do not know yet, but here is how I would find out"?

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

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

2. Technology Awareness, Not Recall

I do not care whether they remember the exact signature of Task.WhenAll. I care whether they know it exists, what it is for, and when reaching for it is a bad idea.

Junior engineers do not need memory any more, the model has that. They need breadth and judgement: a rough 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 one is the wrong tool? Have they noticed why a technology choice mattered on something they built?

I ask about awareness, not trivia. "You used Postgres on that project. Do you know why the team picked it over something else?" A good junior lights up here even if the answer is incomplete. A weak one shrugs and says "it is what we used".

3. How They Actually Worked Before, Even If It Was an Internship

Most interviewers skip this part, and it is the most revealing thing in the whole conversation.

I dig into what they did before, properly. It does not matter whether it was a three month internship or a student project. What matters is how involved they really were. There is a large difference between a junior who closed the tickets they were given and a junior who understood why those tickets existed.

Here is what I want, even from someone in their first job. I want someone who understands the business problem and then goes and finds a technical solution for it. That instinct, connecting the code to the reason it is being written, is the best predictor I have found of who becomes a strong engineer. And you can 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 do that project again, what would you change, and why?"

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

4. How They Use the Tools

AI fluency is an engineering skill now, so test it the way you would test any other, openly, instead of pretending it does not 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 gives code back, do they read it and think about it, or paste it and hope again? Most important: can they tell when the model is wrong? Do they check the output against the actual requirement, or trust it because it sounds confident?

The junior I want treats AI like a sharp power tool. Fast, useful, and respected because it can hurt you if you are careless. The one I worry about treats it like an oracle. Same tool, completely different engineer, and 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. When anyone can generate code, the bottleneck moves to alignment, judgement and communication.

So I watch how they work with other people. Can they explain a decision so a non expert follows it? How do they take feedback, defensively or with curiosity? Can they disagree with me well, without folding immediately or digging in? When they hit something they do not understand, do they go quiet or do they ask?

A junior who communicates clearly and takes feedback well will outgrow a smarter one who cannot, every 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:

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

Then score against what matters. This is the rubric I use, take it:

We Are Not Hiring Typists

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

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 uses AI with judgement instead of faith. Who you would want in the room when something breaks.

The tools got better. The bar did not drop, it moved. Make sure your interview moved with it.