Software developer interview questions, and how to answer them
A developer interview is really a test of how you think out loud. The interviewer already knows you can write a loop; what they want to see is how you break down a messy problem, how you react when your first idea is wrong, and whether you'd be easy to review code with. Here's what each round checks and how to handle the questions that come up again and again.
What happens in each round
- 1
Recruiter screen
What happens
Whether your languages and frameworks match the team's stack, what kind of apps you've worked on, your notice period, and if you can work hybrid or on-site.
- 2
Take-home or online coding assessment
What happens
Whether you can produce working, readable code on your own time. Reviewers look at structure, naming, tests and the README as much as whether it runs.
- 3
Live coding with an engineer
What happens
How you clarify a problem, talk through tradeoffs, write code in a shared editor like CoderPad, and debug when a test case fails in front of someone.
- 4
Technical deep discussion or system design
What happens
Whether you can design a small feature end to end: the API, the database tables, where validation lives, and what happens when something fails.
- 5
Team and hiring manager round
What happens
How you handle code review feedback, vague requirements and deadlines, and whether you'll work well with the product owner and QA.
Questions you're likely to get
1.Walk me through a feature you built from ticket to production.
Why they ask
It shows whether you understand the whole delivery process or only the part where you type code.
How to answer
- Name the feature and who used it, in one sentence
- Say how you clarified the requirements and what was unclear at first
- Describe the design choice you made and one you rejected
- Cover testing, code review and how it was deployed
- End with what happened after release, including anything you'd change
2.Here's a function with a bug. Find it and fix it.
Why they ask
Developers spend much of their time in code they didn't write, so reading and debugging is a core skill.
How to answer
- Read the whole function before touching anything
- Say out loud what you expect it to do and what inputs could break it
- Reproduce the bug with a specific input before changing code
- Make the smallest fix and explain why it works
- Suggest a test that would have caught it
3.How would you design the backend for a simple booking system?
Why they ask
It checks whether you can turn a plain business need into tables, endpoints and rules.
How to answer
- Ask who books, what gets booked and whether double booking is ever allowed
- Sketch the main tables and their relationships
- Define a few REST endpoints and what each returns
- Explain how you'd stop two people grabbing the same slot, such as a transaction or unique constraint
- Mention what you'd log and how you'd handle cancellations
4.Explain the difference between an inner join and a left join, and when you'd use each.
Why they ask
Most business applications sit on a relational database, and weak SQL causes slow pages and wrong reports.
How to answer
- Define each join plainly
- Give a real example, like customers with and without orders
- Point out that a left join is how you find missing matches
- Mention indexes when the tables are large
5.A page that used to load quickly is now slow. How do you find out why?
Why they ask
Performance complaints are a routine ticket, and they want a method, not a guess.
How to answer
- Confirm the problem and when it started, then check what shipped around then
- Use browser dev tools or application logs to see where the time goes
- Check the database for slow queries or a missing index
- Fix the biggest cause first and measure again
6.What do you look for when you review someone else's pull request?
Why they ask
Code review is a daily habit on most teams, and it shows your standards and how you give feedback.
How to answer
- Check that it does what the ticket asked
- Look for edge cases, error handling and missing tests
- Consider readability and whether it fits the codebase's patterns
- Separate must-fix issues from style preferences
- Explain how you word comments so they're about the code, not the person
7.How do you decide what to unit test?
Why they ask
Teams want developers who test the right things instead of none or everything.
How to answer
- Test business rules and calculations first
- Cover the edge cases that have caused bugs before
- Mock external services like payment APIs, not your own logic
- Name a testing framework you've used, such as JUnit, xUnit, pytest or Jest
8.Tell me about a time you merged something that broke production.
Why they ask
Everyone breaks something eventually. They want to see honesty and what you changed afterward.
How to answer
- Own it plainly without blaming the reviewer
- Say how it was noticed and how fast it was rolled back or fixed
- Explain the root cause
- Describe the check, test or process change that stops it happening again
9.How do you handle a requirement that's vague or keeps changing?
Why they ask
Developers in business settings deal with product owners and stakeholders who don't always know exactly what they want.
How to answer
- Ask for an example of the result they expect
- Write down your understanding and confirm it in the ticket
- Build the smallest version and show it early
- Flag when a change affects the estimate instead of quietly absorbing it
10.What's a piece of technical debt you'd fix in your last codebase, and why that one?
Why they ask
It shows whether you think about maintenance and can prioritise by impact.
How to answer
- Name a specific problem, like duplicated validation or a fragile deploy script
- Explain what it costs the team in bugs or slow work
- Say how you'd fix it in small, safe steps
- Show how you'd make the case to a manager who wants features
11.How do you get up to speed on a codebase you've never seen?
Why they ask
New developers often join teams with large, older applications and thin documentation.
How to answer
- Get it running locally first
- Trace one real request from the UI to the database
- Read the tests and recent pull requests to learn conventions
- Pick up a small bug early to learn the deploy process
- Write down what confused you so the next person has it easier
12.Why do you want to work on this product?
Why they ask
They want developers who care who uses the software, not only which stack it's in.
How to answer
- Mention something specific about the product or its users
- Connect it to a kind of problem you enjoy solving
- Say what you'd hope to learn on this team
Mistakes that sink good candidates
Going silent during live coding
Talk through what you're thinking even when you're stuck.
Writing code before asking a single clarifying question about the problem
Listing every framework you've touched instead of going deep on the ones you've used for real
Criticising your current team's code or colleagues in detail
Need more Software Developer interviews to prep for?
HeroApply applies to Software Developer jobs that match you, every day. 2,355 jobs are open today.