Interview questions to ask junior developer candidates

Eight questions for junior candidates

1. Tell me about something you built. Why did you build it that way?
2. What is a bug that took you a long time to solve?
3. What have you learned in the last month?
4. When you get stuck, what do you do first, second and third?
5. Show me something in your project you would change now.
6. What part of programming do you find hardest?
7. How do you know when your code works?
8. What are you curious about that you have not had time to try?

Depth on one project beats breadth across five

Ask about a single project and go three levels deep. Why that database, why that structure, what happened when it broke. Juniors who genuinely built something can answer; juniors who followed a tutorial cannot get past the second follow-up. This is not a trap — following tutorials is how people learn — but it distinguishes understanding from completion, which is the thing you are actually trying to measure.

Getting unstuck is the core junior skill

Most of a junior engineer's first year is being stuck and recovering. Ask what they do first, second and third. Strong answers have a real sequence — read the error properly, reproduce it smaller, search, then ask with context. The answer “I ask someone” is not wrong, but ask how they ask: a junior who arrives with what they tried and what they expected is dramatically cheaper to work with than one who arrives with “it does not work”.

Assess learning rate directly

• “What have you learned in the last month?” The most predictive junior question. Specificity and enthusiasm here correlate strongly with the first six months on the job.
• “What would you change about your own project now?” Measures whether they have grown since writing it, which is learning rate made visible.
• “What do you find hardest?” Candidates who name something real are self-aware; “nothing really” usually means limited exposure rather than mastery.

What not to weight

• Number of technologies listed. At this level breadth is almost always shallow, and depth is the better predictor.
• Polish of the portfolio. It rewards design skill and available time, not engineering aptitude.
• University, unless the role genuinely requires it. It is one of the strongest bias vectors in junior hiring.
• Nerves. Junior candidates are often interviewing for the first time in their lives. Give them a moment and ask again.

Run the technical round differently

Keep the problem small and the scaffolding generous. Give a working repository, a clear task and permission to look things up. You are watching whether they can read code, form a hypothesis and check it — not whether they have memorised an algorithm. Tell them explicitly that you expect questions, because many junior candidates believe asking anything is a failure and will burn twenty minutes rather than clarify a requirement.

Make the interview survivable

A nervous junior candidate performs several levels below their ability, and almost none of that gap is job-relevant. Say at the start what the format is, that they can ask questions, that you do not expect them to finish, and that thinking aloud helps you. The candidates who benefit most from this are often the ones with the least interview exposure, which is exactly the group most companies claim to want to reach.

Where junior candidates are unfairly filtered

• Timed algorithm tests, which measure recent drilling and disproportionately favour candidates who had time to practise.
• Portfolio expectations, which assume unpaid project time that many candidates do not have.
• Referral-only pipelines, which reproduce the existing network and quietly narrow the pool.
• Interviews that punish questions. If asking for clarification costs marks, you are selecting for guessing.

Decide what you are actually hiring for

Junior hiring is a bet on a year of growth, not on current output. Before the loop, agree what the person needs to be able to do unsupervised in twelve months, and assess for the distance between here and there. See how to reduce interview bias and how to write an interview scorecard.

Where Interviewer Mode fits

Disclosure: we make CoPilot Interview, which includes Interviewer Mode for the hiring side and a real-time assistant used by candidates. We have an interest in you using the first, and our view of the second is that interviews should be designed to measure something an assistant cannot fake. Weigh the advice below accordingly.

Frequently asked questions

What should I ask a junior developer in an interview?

Ask about one thing they built and go three levels deep on why, a bug that took them a long time, what they have learned in the last month, and what they do first, second and third when stuck. Depth on one project beats breadth across five.

How do you assess potential with no work experience?

Assess learning rate and how they handle not knowing. What they learned recently, what they would change about their own project now, and their sequence for getting unstuck all predict the first six months better than any list of technologies.

Should junior candidates be allowed to look things up?

Yes, and say so explicitly at the start. Testing memorisation adds noise at every level and most of all at this one. Tell them you expect questions too — many junior candidates believe asking anything counts as failing.

What should I ignore when interviewing juniors?

The number of technologies listed, portfolio polish, university brand unless genuinely required, and first-interview nerves. All four are weak predictors and the last three are significant bias vectors in junior hiring.