What to expect in a junior developer interview

Junior developer interviews usually have three parts, though the order and format vary between companies. The technical screen is often a short coding challenge or online quiz to check you have the basics. In the technical interview, an engineer asks about fundamentals and watches how you work through a problem. The behavioural round is about how you work: whether you ask for help when you need it, how you take feedback, and how you keep learning.

It's easy to put all your preparation into the technical side and arrive at the behavioural round with nothing ready. The questions below cover both.

What they expect from a junior developer

Nobody expects a junior developer to know everything. The interviewer wants to see solid basics, honesty about what you don't know, and signs that you learn quickly. "I'm not sure, but this is how I'd find out" is a much better answer than a bluff, which tends to fall apart at the first follow-up question.

Technical fundamentals

These questions check that you understand the ideas behind the code you write. You don't need textbook definitions. Explain each idea in your own words, with an example of when you'd use it.

Questions 1–7 · Core Technical
Question 01
"Can you explain the difference between object-oriented and functional programming?"
What they're really asking
Can you explain programming paradigms in plain words, and do you know that different problems suit different approaches?
How to answer it
Give a sentence on each, then an example. Object-oriented programming groups data and the methods that act on it into objects. That suits things whose state changes, like a shopping cart. Functional programming builds programs from pure functions, which return the same output for the same input and change nothing else, so they're easy to test and safe to run in parallel. Most mainstream languages let you mix the two, and most codebases do.
Question 02
"What is the difference between a stack and a queue? When would you use each?"
What they're really asking
Do you know the basic data structures, and can you work out when to use each one?
How to answer it
A stack is LIFO (last in, first out), like a pile of plates. Undo uses one, and so does the call stack that tracks which function called which. A queue is FIFO (first in, first out), like print jobs waiting for a printer, so it suits tasks that should be handled in the order they arrived. Breadth-first search uses one too. Choose whichever gives things back in the order your problem needs.
Question 03
"What is Big O notation and why does it matter?"
What they're really asking
Can you reason about performance as the amount of data grows?
How to answer it
Big O describes how an algorithm's running time or memory use grows with the size of its input. A nested loop that takes a millisecond on 1,000 records takes about 17 minutes on a million, because it's O(n²): a thousand times the data means a million times the work. Give examples: one loop over an array is O(n), a loop inside a loop over the same array is O(n²), and binary search on a sorted array is O(log n). You don't need to optimise everything, but you should notice when something won't cope with real data volumes.
Question 04
"Can you walk me through what happens when you type a URL into a browser?"
What they're really asking
How well do you understand what happens underneath the code you write? Expect follow-up questions on any step you mention, to see how far down you can go.
How to answer it
Go through the steps in order. A DNS lookup turns the domain into an IP address. The browser opens a TCP connection (or QUIC over UDP, for HTTP/3), and for HTTPS a TLS handshake sets up encryption. It sends the HTTP request, the server sends back a response, and the browser parses the HTML, fetches the CSS, JavaScript and images it needs, and renders the page. You don't need every detail. Get the order right, and be ready to go further into any step they ask about.
Question 05
"What is the difference between SQL and NoSQL databases? When would you choose each?"
What they're really asking
Do you understand why you'd store data one way rather than another?
How to answer it
Relational (SQL) databases store data in tables with a defined schema. They're good at queries that join related data, and transactions and constraints keep the data correct, which suits things like financial records. NoSQL covers several designs (document, key-value, wide-column and graph) with more flexible schemas. They fit data whose shape varies, very high write volumes, or simple lookups at large scale. A relational database is a sensible default unless you have a specific reason to choose something else. Postgres can store and query JSON too, so flexible fields alone aren't a reason to switch.
Question 06
"What is version control and how do you use Git in your daily workflow?"
What they're really asking
Can you work in a shared codebase without breaking things, and do you know why version control exists?
How to answer it
Say what version control does: it records every change, lets several people work on the same code, and lets you go back to an earlier version. Then describe how you use Git: a branch off main for each feature, commits with clear messages, a pull request for review, and fixing merge conflicts. Be honest about your experience. If you've only used Git on your own projects, say so, and talk through the commands you know. If you've used pull requests and code review in a team, mention it.
Question 07
"Can you explain what REST is and how RESTful APIs work?"
What they're really asking
Most web and mobile work involves calling or building APIs. Do you know the basics?
How to answer it
REST (Representational State Transfer) is a style for designing web APIs. The main ideas: requests are stateless, URLs name resources, and the HTTP method says what to do. GET reads, POST creates, PUT replaces, PATCH updates part of a resource and DELETE removes it, so GET /orders/42 fetches order 42. Stateless means each request carries everything the server needs to handle it, such as an auth token. Responses are usually JSON, with a status code that says what happened: 200 OK, 201 Created, 404 Not Found, 500 Internal Server Error. If you've built or used an API, even in a side project, use it as your example.

Practise answering out loud

Explaining something out loud is harder than reading about it. InterviewZap asks you behavioural questions like the ones further down, written from your CV and the job description. Answer by typing or speaking, and after each answer you'll see what was missing and a better way to put it.

Start Practising Free →

No credit card. Free to start.

Coding and problem-solving

These questions are about how you work through a problem: whether you have a method, whether you can explain it as you go, and whether someone else could follow your work and build on it.

Questions 8–12 · Coding & Problem Solving
Question 08
"How do you approach debugging a piece of code that isn't working?"
What they're really asking
Do you debug methodically, or change things at random until it works?
How to answer it
Describe your process: first reproduce the bug reliably, then narrow down where it happens with logging or breakpoints, form a theory about the cause and test it, then fix it and check the fix. Mention the tools you use: a debugger, console.log or print statements, and a unit test that fails before the fix and passes after it. Each step should rule something out, so you're not guessing. It helps to describe a bug you tracked down and what it taught you.
Question 09
"What does it mean to write clean code? Can you give an example?"
What they're really asking
Do you think about the next person who has to change your code?
How to answer it
Clean code is code that other developers, including you in six months, can read, understand and change easily. The main habits: names that say what a variable holds or a function does, functions that do one thing, comments that explain why rather than repeat what the code says, consistent formatting, and keeping each piece of logic in one place (DRY: don't repeat yourself). Give a small before-and-after if you can. Even renaming x to userAgeInYears makes the point.
Question 10
"How do you approach a coding problem you haven't seen before?"
What they're really asking
You might hear this just before a live coding exercise. They want to see how you go about it.
How to answer it
Talk it through before you start typing. Restate the problem in your own words to check you've understood it, and ask about edge cases, input format and limits. Think out loud. Start with a simple brute-force approach that works, even if it's slow, then look for a faster one. Write readable code rather than clever code, and test it with examples as you go. The interviewer can only judge what they can see and hear, so keep talking even when you're unsure. If you go quiet, they can't tell if you're stuck or nearly there.
Question 11
"What is the difference between unit tests, integration tests, and end-to-end tests?"
What they're really asking
Do you understand testing beyond checking that the code runs?
How to answer it
Unit tests check one function or component on its own. They're fast and cheap, and good at catching logic errors. Integration tests check that several parts work together, such as an API handler and its database. End-to-end tests use the whole system the way a user would. They're slower and harder to maintain, but they catch problems that only show up when everything is connected. The usual guide is the test pyramid: many unit tests, fewer integration tests and fewer still end-to-end tests, though teams weigh it differently.
Question 12
"Have you worked with any CI/CD pipelines? What do they do?"
What they're really asking
Have you seen how code gets from a developer's laptop into production, even on a side project?
How to answer it
Continuous integration (CI) means merging changes often, with each push or pull request built and tested automatically, so a broken build or failing test is caught early, usually before it's merged. CD is either continuous delivery, where every passing build is ready to release and a person decides when it goes out, or continuous deployment, where it goes to production automatically. If you've set up a GitHub Actions workflow or worked on a project with a pipeline, describe it. If you haven't, say so, explain what you understand of the idea, and say you'd like to learn it on the job.

Behavioural questions

Don't treat these as the easy part. You'll be working closely with other developers, and the interviewer wants to know you'll communicate, take feedback and keep learning without someone checking on you all the time.

Use the STAR method for these: Situation, Task, Action, Result.

Questions 13–20 · Behavioural
Question 13
"Tell me about a project you're proud of. What was your contribution?"
What they're really asking
Can you explain what you built, which part was yours, and what you learned?
How to answer it
Pick one project, from uni, work or your own time, and describe it clearly: what it does, the stack, what you did on it, and what you'd do differently now. Don't skip the part about what you'd change. It tells the interviewer you can look at your own work critically. And instead of listing technologies, talk about what was hard and how you solved it.
Question 14
"Describe a time you got stuck on a problem. How did you get unstuck?"
What they're really asking
Do you have a method for getting unstuck, and do you know when to ask for help?
How to answer it
Be honest and specific. Describe the problem, what you tried, when you realised you were going round in circles, and how you got moving again: stepping away, reading the documentation, asking a colleague, or coming at it a different way. Show that you don't stay stuck for long, and that you ask for help once you've had a proper go yourself.
Question 15
"How do you handle receiving critical feedback on your code in a review?"
What they're really asking
Do you get defensive about your code, or can you hear criticism of it without taking it personally?
How to answer it
Say that you welcome it. Code review is one of the quickest ways to learn from more experienced developers. Give an example where a review comment made your code better. Explain that you try to understand why the reviewer suggested something, rather than just making the change. If you've ever disagreed with a suggestion, explained your reasoning and the reviewer agreed, that's a good story too.
Question 16
"Tell me about a time you had to learn something new quickly."
What they're really asking
Can you teach yourself new things? Junior developers keep having to pick up new frameworks, tools and parts of the business.
How to answer it
Use STAR. Pick a real example: a language, framework or tool you had to learn for a deadline or to finish a project. Describe how you learned it: the documentation, tutorials, building something small, asking questions. Spend as much time on how you learned as on what you learned. The interviewer wants to know you could do the same with whatever they use.
Question 17
"How do you prioritise when you have multiple tasks or deadlines?"
What they're really asking
Can you manage your own workload, or will you need someone to tell you what to do next?
How to answer it
Describe what you actually do: weigh urgency against importance, tell people early when something might slip, and break big tasks into smaller pieces so you can show progress. It's fine to say you're still getting better at this, as long as you show you work at it. Add that when priorities aren't clear, you ask rather than guess.
Question 18
"Have you ever disagreed with a technical decision made by someone senior? What did you do?"
What they're really asking
Can you give a technical opinion respectfully? Will you go along with anything, or do you think for yourself?
How to answer it
A good answer shows that you raised the concern clearly and politely, listened to their reasoning, and then either changed your mind or accepted the decision and got on with it. This is what people mean by "disagree and commit". Avoid stories where you said nothing, or where you wouldn't let it go. Show that you can hold an opinion, make the case for it, and then back the decision whichever way it goes.
Question 19
"Where do you want to be in your career in three years?"
What they're really asking
Are you serious about growing as an engineer, and does this job fit where you want to go?
How to answer it
You don't need a detailed career plan. They want to hear that you have a direction and that this role fits it. Something like: "I want to get really good at [area] and work on systems at scale. In three years I'd like to be a solid mid-level engineer who can take a feature from start to finish without close supervision." Then connect it to what this role offers.
Question 20
"Do you have any questions for us?"
What they're really asking
Are you curious about this company and this job, or just going through the motions?
How to answer it
Always have some ready. Questions that work well for a junior developer: "What does onboarding look like for junior developers, and how long is it usually before they push code to production?" / "How do code reviews work here?" / "What are the main technical problems the team is working on at the moment?" / "What do the junior developers who do well here have in common?" Save questions about pay and annual leave for a later stage, unless they raise them. And don't ask anything the company's website already answers, because it suggests you haven't looked.

How to prepare

Reading these questions is a start. Answering them out loud, to a stranger, while you're nervous, takes practice.

  • For technical questions: Don't just read the answer. Explain it out loud, to yourself or to someone else. If you stumble over part of an explanation, that's the part to go back to.
  • For behavioural questions: Prepare five to eight real stories from your projects, internships, jobs or study. Most stories can answer more than one question, depending on which part you focus on.
  • For coding challenges: Practise on sites like LeetCode, HackerRank or Codewars, and talk through your thinking out loud while you do. In a live coding interview, the interviewer is following your reasoning as well as your code.
  • Mock interviews: Before the real thing, do at least one timed mock interview with someone else asking the questions. Your first go at answering out loud is usually your roughest, so make sure it isn't in the real interview.
One more thing

For a junior role, the interviewer is also judging how much you'll grow once you start. Let your curiosity show: ask about their codebase and how the team works, and mention what you've been learning on your own.