The interview for a junior development role produces a particular kind of anxiety: the feeling that at any moment the question will come that exposes what you do not know yet. That anxiety rests on a misunderstanding. Nobody expects a junior to know everything; they expect them to reason, to learn fast, and to be honest about their limits.
This guide explains what is really being evaluated, which technical and behavioral questions come up most often, and how to handle two defining moments: the "I don't know" and the personal projects.
In this guide
What is actually evaluated in a junior
Hiring a junior is an investment: the company knows the first months are training. That is why the interviewer is not looking for encyclopedic knowledge but for three signs that the investment will pay off.
The first is reasoning: faced with a new problem, the path matters more than the answer. The second is learning ability: what the person learned on their own and how they dig in when they get stuck. The third is technical honesty: a junior who says "I don't know" and shows how they would find out is hireable; one who makes up answers is a risk, because they will make things up on the job too.
The typical technical questions
Topics vary with the stack, but the pattern repeats across companies:
| Topic | Typical question | What it tests |
|---|---|---|
| Language fundamentals | "What's the difference between a list and a dictionary?" | Whether the foundation is solid or was learned by copying snippets |
| Logic and data structures | A short exercise, solved out loud | The reasoning, not the optimal solution |
| Git and teamwork | "How do you resolve a merge conflict?" | Whether the person can join a real workflow from week one |
| Databases and APIs | A simple SQL query, what a REST API is | Understanding of the whole system, not just the fragment coded |
| Their own code | "Why did you solve it that way?" | Whether they understand their code or copied it, a common filter in the age of AI assistants |
In junior roles the exercises are simple on purpose: what is observed is the process, not the speed. For any technical prompt, it helps to restate the problem in your own words and lay out the approach before executing it.
Thinking out loud is not optional: it is the product being evaluated. A candidate who stays silent for two minutes and gives the right answer scores lower than one who narrates their reasoning, makes a mistake, and corrects it.
The behavioral questions
The non-technical half of the interview carries more weight than junior candidates assume. The classics of the general format (introduction, motivation, strengths and weaknesses) are in the guide on common interview questions; these are the ones specific to the profile:
- "How did you learn to program?" There is no wrong answer (college, bootcamp, self-taught), but there is a strong structure: what was chosen to learn, why, and what was built with it.
- "Tell me about a bug that was hard to fix." Tests debugging method and frustration tolerance. A strong answer narrates the process: what was tried, how the problem was isolated, and what it taught.
- "What do you do when you're stuck on something?" Tests autonomy with judgment. "I never ask for help" is as bad an answer as "I ask right away."
- "What technology are you learning right now?" Measures whether learning is still active, the number one signal of a junior who will deliver.
How to say "I don't know" well
In a junior interview, questions arrive that have no answer, sometimes placed on purpose to see the reaction. A three-step formula turns that moment into a point in your favor: admit it plainly, get close with what you do know, and explain how you would find out.
"I haven't worked with Redis, so I don't want to make something up. I know it's an in-memory database and it's widely used for caching, so I assume the advantage is read speed. If I needed it in a project, I'd start with the official docs and build a small test before touching anything real."
That answer shows honesty, a base for reasoning, and a learning method: the three signals the interview is looking for. The alternative (improvising a definition) always fails, because the interviewer knows the answer and the follow-up question is coming.
How to talk about personal projects
Without work experience, projects are the experience. For each project in the portfolio, the candidate should be able to explain four things: what problem it solves, what technical decisions were involved, what was hardest, and what they would do differently today. That last one is the interviewers' favorite, because it measures technical self-criticism.
Two projects defensible in depth are worth more than six barely modified tutorials. If a project has real users, even ten, that fact goes first. The same projects need to be told well on paper: the guide on a resume with no experience explains how to present them in accomplishment format.
Common junior mistakes in interviews
Most of these are not knowledge gaps but habits, which is good news: habits can be corrected in a couple of practice rounds.
- Making things up when you don't know. The most expensive mistake: the follow-up exposes it and drags down the credibility of everything else.
- Solving in silence. Reasoning that is not narrated does not exist for the interviewer.
- Being unable to explain your own portfolio. A sign of code copied without digesting it.
- Over-apologizing. Starting every answer with "this is probably wrong, but..." erodes the overall impression.
- Showing up without your own questions. Asking about the stack, the code review process, or how juniors are mentored shows judgment.
- Not rehearsing the spoken part. Explaining code out loud is a trainable skill; a mock interview with AI makes it possible to practice role-specific questions in the interview simulator before the real one.
Frequently asked questions
What do they ask in a junior developer interview?
Fundamentals of the main language, basic data structures, Git, some SQL query or API concept, and behavioral questions: how you learned to program, a hard bug, what you do when stuck. If there is a portfolio, questions about the decisions behind that code.
Do I need to solve complex algorithms for a junior role?
In most junior roles, no. The exercises are usually simple logic, and what is evaluated is the reasoning out loud, not the optimal solution. The exceptions, some large tech companies with competitive processes, are signaled in the posting.
What if I don't know the answer to a technical question?
It is expected and even part of the interview's design. The right answer has three steps: admit it plainly, contribute what you do know, and explain how you would find out. Making up an answer is the only disqualifying path.
How many projects should be in a portfolio?
Two or three that can be defended in depth: what problem they solve, what technical decisions are behind them, what was hard, and what would be changed today. They beat any list of replicated tutorials.
How do I practice a junior technical interview?
Out loud, which is how the real one happens: explain a personal project to someone else, narrate the reasoning of a simple exercise while solving it, and rehearse the behavioral questions with a simulator that asks follow-ups.