Common software developer interview questions

Software developer interview questions and answers

Questions marked STAR want a real example: the situation, your task, the action you took and the result. For the others, follow the steps. Keep each answer to about two minutes.

1. 1

   Experience

   Talk me through a project you have worked on recently.

   What they want to hear

   A clear explanation of what the product does, your part, the technical decisions and what you would change. They are checking your depth and how well you explain things.

   Avoid

   Listing technologies without explaining your choices, or describing the team’s work as if it were all yours.

   How to answer

   Start with

   The problem and the users, in a sentence or two.

   Then

   Your part: the stack, a decision you made and why, and something hard you solved.

   Finish with

   The outcome, and what you would do differently now.

2. 2

   DebuggingSTAR

   Tell me about a difficult bug you tracked down.

   What they want to hear

   A methodical approach: reproducing the problem, narrowing it down with logs, tests or a debugger, fixing the cause and stopping it coming back.

   Avoid

   A story where the fix was a lucky guess, or where you never found the root cause.

   An example answer, with STAR

   Situation

   Orders sometimes showed the wrong total, but only for some customers.

   Task

   You were asked to find the cause before a busy weekend sale.

   Action

   You reproduced it with a copy of one customer’s order, found a rounding error when two discounts applied, wrote a failing test and then fixed the code.

   Result

   The test now runs on every build, and the bug hasn’t come back.

3. 3

   Problem solving

   How do you approach a coding problem you haven’t seen before?

   What they want to hear

   That you clarify before you code, think out loud, start simple and test as you go. In a live exercise, how you reason matters as much as the final answer.

   Avoid

   Coding in silence, or going quiet when you get stuck. Saying what you are thinking lets the interviewer help.

   How to answer

   First

   Ask about the inputs, the edge cases and what "done" looks like.

   Then

   Talk through a simple approach, write it and test it with a small example.

   Finish with

   Improve it, and explain the trade-offs, such as speed against readability.

4. 4

   Testing

   How do you test your code?

   What they want to hear

   That testing is part of how you work, not an afterthought: unit and integration tests, what you choose to test and how tests run in your pipeline.

   Avoid

   Saying the testers handle it, or claiming you test absolutely everything.

   How to answer

   Start with

   The kinds of tests you write and the tools you use, such as Jest, pytest or JUnit.

   Then

   How you decide what to test: the important paths, the edge cases and the bugs you have fixed before.

   Give an example

   A time a test caught a problem before it reached users.

5. 5

   TeamworkSTAR

   Tell me about a code review where you disagreed with someone.

   What they want to hear

   That you give and take feedback well, argue with evidence and keep working relationships good.

   Avoid

   A story where you were simply right and the other person was wrong, or where the disagreement turned personal.

   An example answer, with STAR

   Situation

   A colleague’s pull request added a new library for something the codebase already did.

   Task

   You wanted to raise it without holding up their work.

   Action

   You left a friendly comment with a short example using the existing code, then had a quick call to talk it through.

   Result

   They switched to the existing approach, and you added a note to the team’s coding guidelines.

6. 6

   Version control

   How do you use Git when you work in a team?

   What they want to hear

   Practical experience: branches, small commits, pull requests, resolving conflicts and keeping the main branch ready to release.

   Avoid

   Only knowing Git through a visual tool you can’t explain, if the role expects the command line.

   How to answer

   Start with

   Your usual workflow, such as feature branches and pull requests into main.

   Then

   How you keep changes small and commit messages clear.

   Finish with

   How you deal with a merge conflict or a broken build.

7. 7

   JudgementSTAR

   Tell me about a technical trade-off you made.

   What they want to hear

   That you weigh options against real constraints, such as time, cost, performance and how easy the code will be to maintain, and can explain your reasoning to people who don’t code.

   Avoid

   Implying there was only one right answer, or describing a choice you can’t explain.

   An example answer, with STAR

   Situation

   A report page was very slow to load for the largest customers.

   Task

   You had a week to make it usable.

   Action

   You compared rewriting the database query with caching the results, chose caching for now because it was quicker and safer, and logged the rewrite as follow-up work.

   Result

   The page became usable for those customers that week, and the team planned the rewrite for later.

8. 8

   System design

   How would you design a simple service, such as a link shortener?

   What they want to hear

   Mostly for mid-level and senior roles: that you can break a problem into parts, think about data, load and failure, and discuss trade-offs without over-engineering.

   Avoid

   Jumping to a complex architecture before asking any questions.

   How to answer

   First

   Clarify the requirements: who uses it, what features it needs and what matters most.

   Then

   Sketch the parts: an API, a database for the links, how short codes are created and how you would cache popular links.

   Finish with

   What could fail, how you would monitor it, and what you would build first.

9. 9

   LearningSTAR

   Tell me about a time you had to learn a new technology quickly.

   What they want to hear

   That you learn independently, use good sources and share what you learn with the team.

   Avoid

   Suggesting you only want to work with technologies you already know.

   An example answer, with STAR

   Situation

   Your team moved its services to Docker, and you had never used it.

   Task

   You needed to get your service running in containers within the sprint.

   Action

   You worked through the official tutorial, paired with a colleague who knew it and wrote notes as you went.

   Result

   Your service moved over on time, and your notes became the team’s set-up guide.

10. 10

    Scenario

    What would you do if a release you shipped broke something for users?

    What they want to hear

    Calm ownership: tell people, limit the damage, fix it properly and learn from it without blame.

    Avoid

    Fixing it quietly without telling anyone, or blaming whoever reviewed the code.

    How to answer

    First

    Tell the team straight away and check how many users are affected.

    Then

    Roll back or ship a quick fix, following the team’s process.

    Finish with

    Find the cause, add a test that would have caught it and share what happened in a short review.

11. 11

    Communication

    How do you explain a technical problem to someone who isn’t technical?

    What they want to hear

    That you can work with product managers, designers and customers: plain language, a focus on the impact and clear options.

    Avoid

    Jargon, or making the other person feel they should already know.

    How to answer

    Start with

    What it means for them: what users will notice and how soon it can be fixed.

    Then

    A simple comparison instead of jargon.

    Finish with

    The options and your recommendation, so they can decide.

12. 12

    Motivation

    Why do you want to work on our product?

    What they want to hear

    That you have looked at what they build, how they build it and why it interests you as a developer.

    Avoid

    Talking only about the tech stack or home working, with nothing about the product.

    How to answer

    Start with

    Something specific about the product, its users or the problem it solves.

    Then

    What appeals about how they work: their stack, their engineering blog, open source work or team practices.

    Finish with

    What you would bring, and what you want to learn.