Interview kit · 7 questions
Junior developer interview questions
These junior developer interview questions come from the screening we run on real candidates — each with what a strong answer shows, because a question without a grading key is just conversation.
Interviews reward fluency; the job rewards judgment. The questions below are scenario-first on purpose — past specifics and decisions under constraint predict, rehearsed strengths don't. Pair them with the graded work sample at the end and you have most of a real screening process.
1A production endpoint started returning 500s right after a deploy. You have logs, git history and a staging environment. Walk me through your process, in order — and tell me when you'd roll back versus fix forward.
What a strong answer shows: Sound order: read the actual error in logs, diff the deploy, reproduce in staging, then decide — with a stated criterion like 'roll back if users are bleeding and the fix isn't obvious in minutes'. Jumping straight to editing code without reading the error is the junior tell this question exists to catch.
2Walk me through the code you're proudest of. What would you change about it today?
What a strong answer shows: They can explain their own decisions line by line, and the self-critique is real — naming a structure or shortcut they'd now do differently. Pride without critique means they haven't grown since writing it.
3How do you use AI coding tools day to day — and how do you catch what they get wrong?
What a strong answer shows: Uses them for speed on boilerplate, tests and unfamiliar APIs, but reads and runs everything before it merges, and can name real failure cases they've caught: invented APIs, plausible-but-wrong logic, silently swallowed errors. 'I just review it' without an example means they don't.
4A reviewer asks for changes you think make the code worse. What do you do?
What a strong answer shows: Engages once with reasons, then either learns something or disagrees-and-commits without sulking — and knows which hills matter (correctness, security) versus which don't (style preferences the linter should own).
5How do you decide whether a change needs a test?
What a strong answer shows: A judgment, not a slogan: logic and edge cases yes, trivial wiring maybe not, bug fixes always get a regression test that fails before the fix. '100% coverage always' and 'tests slow me down' are both wrong answers.
6Explain something technical you learned recently as if I'm not a developer.
What a strong answer shows: Clarity under translation — a real analogy, no jargon retreat. This predicts PR descriptions, bug reports and every async explanation they'll ever write for you.
7You've been blocked for two hours. What does the third hour look like?
What a strong answer shows: A timebox that ends in a well-formed question: what they're trying to do, what they've tried, what they've ruled out — posted where the answer lives. Grinding silently for a day and asking 'it doesn't work, help' are the two failure modes.
Red flags, from reading a lot of these
- Can't explain code in their own portfolio — a proxy for AI-generated work they never understood.
- No testing habit at all, or a dogmatic one they can't reason about.
- Every debugging story starts with changing code instead of reading the error.
- Blames every past conflict on reviewers or teammates.
Then test the work, not the talk
The single highest-signal step isn't a question at all. For junior developers: A production-500 debugging walkthrough, plus working code with its tests. Graded work under a written rubric is how our own screening scores every candidate — here's a real sample shortlist showing what that evidence looks like.
Or let the screening run for you
Describe the role once and we run this whole process — sourcing, scenario answers, graded work samples, a second AI-tailored interview round — and hand you three scored finalists. The search runs free; the flat $1,995 is due only when you want introductions.
Hire a junior developer — search runs free
Common questions
How many interviews should I run for a junior developer?
Two, at most — one structured conversation built on questions like these, and one review of graded work. Adding a third round rarely adds signal; it mostly adds weeks, and in this market the good candidates are gone by then.
Should I send questions in advance?
Send the work sample in advance — polished written work under no time pressure is exactly what you're buying. Keep the scenario questions for the live conversation, where you can probe the first answer; the follow-up is where rehearsed answers fall apart.
Can't candidates just answer these with AI?
Written answers, sometimes — which is why the live follow-up matters, and why our own screening grades the thinking in an answer rather than its polish. Ask 'what happened next?' or 'why that order?' and a borrowed answer runs out of depth in one exchange. A candidate using AI well day-to-day is a positive signal; a candidate who can't defend their own answers is the flag.
What actually predicts a good hire?
Graded work beats conversation. Interviews reward confidence and fluency; a role-specific scenario plus a real work sample rewards the actual job. Use the interview to probe judgment and verify the work is theirs — not to guess at skill from charisma.