Software developer interview questions, with worked answers

How to use these questions

Read the short answer and say it out loud. That is your first thirty seconds. Then read the full answer and pick two or three points to add from your own work. Interviewers want trade-offs and real examples, not definitions.

Things marked depends on the release or depends on the provider depend on a release or a provider. Check the current documentation before you quote a detail.

What a software developer is expected to know

• One main language, well: for example JavaAsked in 20% of software developer ads (as of 5 Nov 2026).Modern Java (records, streams, generics) in a framework such as Spring, with tests and a build tool., PythonAsked in 26% of software developer ads (as of 5 Nov 2026).Clean, tested Python: a small web service or a script others can run, with types, tests and packaging., C#Asked in 20% of software developer ads (as of 5 Nov 2026).C# on .NET: web APIs, async code, dependency injection and tests; common in banks and industry. or TypeScriptAsked in 11% of software developer ads (as of 5 Nov 2026).JavaScript with types: model the data, let the compiler catch mistakes, and keep the types honest.. Well means you can read unfamiliar code in it and explain why it behaves as it does.
• Testing: unit testsAsked in 8% of software developer ads (as of 5 Nov 2026).Fast tests for one piece of logic each; they run on every change and fail for one reason. (small, fast tests of one piece of logic), integration tests (several parts together) and when each is worth it.
• Version control: GitAsked in 33% of software developer ads (as of 5 Nov 2026).Branches, pull requests, a clean history, and fixing a merge conflict without panic. with branches and pull requests (a proposed change that others review before it is merged).
• Shipping: CI/CDAsked in 29% of software developer ads (as of 5 Nov 2026).Every change is built and tested automatically; a green pipeline can ship, a red one stops the release. (every change is built and tested automatically, then released), DockerAsked in 12% of software developer ads (as of 5 Nov 2026).Package a service and its dependencies into an image that runs the same on a laptop and in production. (a container: the program packed with everything it needs to run) and one cloud.
• Data: SQLAsked in 18% of software developer ads (as of 5 Nov 2026).Write joins and aggregations, read a query plan, and know when an index helps., tables and indexes, and what a transaction (several changes that succeed or fail together) protects you from.
• Design: clear names, small functions, APIsAsked in 6% of software developer ads (as of 5 Nov 2026).Design an HTTP API with clear resources, status codes, versioning, paging and helpful errors. (the agreed way two programs talk), and design patternsAsked in 1% of software developer ads (as of 5 Nov 2026).Named solutions to common design problems (adapter, strategy, observer); use them when they make code simpler. used only where they make code simpler.
• Security basics: the common attacks on web software and how code prevents them.
• Teamwork: code reviews, estimates, and working in agileAsked in 10% of software developer ads (as of 5 Nov 2026).Short cycles of planning, building and showing work; adjust the plan from what you learn. teams.

Writing and changing code

What do you look for when you review a colleague's code?

What they check: that a code review is about finding problems early and sharing knowledge, done kindly, not about style wars.

Short answer: "First, does it do what the ticket asks, including the edge cases? Then, is it tested, is it easy to read, and will it be easy to change? I ask questions rather than give orders, I separate must-fix from nice-to-have, and I leave formatting to an automatic tool."

The full answer: I read the description and the ticket before the code, so I know what it should do. I look for bugs first: empty input, a missing check, an error that is swallowed silently, two users doing the same thing at once. Then tests: is there a test for the new behaviour, and would it fail if the code were wrong? Then readability: names, size of functions, comments that explain why rather than what. I keep reviews small and fast; a change of a few hundred lines gets a better review than one of several thousand. If a discussion goes back and forth twice, we talk instead of typing.

A weak answer: "I check that it follows our style guide." Style is for a formatter; a review that only finds commas misses the bugs.

Follow-up: "A senior colleague keeps rejecting your changes over small preferences. What do you do?" Ask to agree the rules once, write them down or put them in the formatter, and keep the reviews for things that matter.

How would you refactor a large, old piece of code that nobody wants to touch?

What they check: that you change risky code safely, in small steps, with tests as a safety net.

Short answer: "First I add tests that pin down what it does today, even the odd parts. Then I refactor in small steps, each one shipped and tested, and I only change behaviour in a separate step. I start where the business feels the pain, not where the code looks ugliest."

The full answer: To refactor is to change the structure of code without changing what it does. With old code the danger is breaking something nobody remembers. So: write characterisation tests (tests that record the current behaviour, right or wrong). Find a seam, a place where you can cut in, such as a function boundary. Extract small pieces, give them clear names, and ship each step. Keep the old and new paths side by side behind a switch when the risk is high, so you can go back at once. Agree the work with the team and the product owner, and tie it to something they care about, such as fewer bugs or faster changes in that area.

A weak answer: "I would rewrite it from scratch." Big rewrites usually take far longer than planned and lose the hidden rules the old code had learned.

Follow-up: "There are no tests and no time to write many. Now what?" Test only the path you are about to change, and add a test for every bug you fix there.

What is technical debt, and how do you decide when to pay it back?

What they check: that you can talk about code quality in business terms.

Short answer: "Technical debt is the extra cost of every future change because of a shortcut taken earlier. I pay it back when it slows down work we are about to do, and I make it visible with a ticket and an estimate, so it is a decision, not a secret."

The full answer: Some debt is a sensible choice, such as shipping a simple version to learn faster. It becomes a problem when the interest grows: every change in that area takes longer, breaks more often or scares people. I keep a short list of the worst areas with the cost they cause, such as bugs, hours lost or slow releases. Then the team can trade it against features. A steady share of each sprint for clean-up often works better than a big clean-up project.

A weak answer: "Our code has no technical debt." Every real codebase has some.

Follow-up: "The product manager says there is never time for it." Show the cost in their terms, such as how much longer features in that area take, and propose one small, measurable fix.

Testing and debugging

How do you decide what to cover with unit tests, integration tests and end-to-end tests?

What they check: that you test with a purpose, and know the cost and value of each kind.

Short answer: "Many fast unit tests for the logic, fewer integration tests for the places where parts meet, like the database or another service, and a handful of end-to-end tests for the paths that make money. Every bug gets a test before it is fixed."

The full answer: A unit test checks one piece of logic alone and runs in milliseconds, so you can have thousands. An integration test checks that your code really works with the database, a queue or another API; it is slower but catches the wiring mistakes. An end-to-end test drives the whole system like a user; it is slow and fragile, so keep it to the key journeys, such as sign-up and payment. People call this shape the test pyramid. Good tests fail for one clear reason, do not depend on each other, and run in the pipeline on every change. Test automationAsked in 8% of software developer ads (as of 5 Nov 2026).Automated tests at several levels (unit, integration, end to end) that run in the pipeline. is only worth it if a red test really stops the release.

A weak answer: "We aim for full coverage." Coverage shows what ran, not what was checked.

Follow-up: "Your end-to-end tests fail randomly one time in ten. What do you do?" Treat flaky tests as bugs: find the cause (timing, shared data, the order of tests), fix it or remove the test, and never just re-run until it is green.

A bug appears in production that you cannot reproduce on your machine. How do you find it?

What they check: a calm, step-by-step method, and using evidence rather than guessing.

Short answer: "I limit the damage first, then gather evidence: logs, error reports, which users and which version. I look for what differs between production and my machine, such as data, settings, load or timing, and narrow it down one difference at a time."

The full answer: If users are hurt, I first stop the harm: roll back the last release or switch the feature off. Then I collect facts: when did it start, does it match a release, which inputs trigger it. Logs with a request id let me follow one request through every service. Typical causes of "works on my machine" are different data (an empty field, a special character), different configuration, a different version of a library, real load, or timing between two processes. I write a failing test that reproduces it, fix it, and add the test so it cannot come back. Then I ask why it was not caught, and close that gap too.

A weak answer: "I add print statements and redeploy until I find it." That is slow and risky on a live system.

Follow-up: "It only happens under heavy load." Suspect a race condition or a resource limit, such as a connection pool that runs out; reproduce it with a load test.

What is a race condition, and how do you prevent one?

What they check: that you understand what goes wrong when two things happen at the same time.

Short answer: "A race condition is a bug where the result depends on which of two processes gets there first, like two people booking the last seat. I prevent it by making the critical step atomic, meaning all-or-nothing, with a database transaction, a unique constraint or a lock, and by sharing as little changing data as possible."

The full answer: The classic case is "read, check, write": two requests both read that one seat is free, both book it. The fix is to let the database do the check and the write in one step, for example an update that only succeeds if the seat is still free, or a unique rule that refuses the second booking. Inside one program, avoid sharing data between threads where you can, and protect it with a lock where you cannot. For actions that may be retried, such as a payment, make them idempotent: doing them twice has the same effect as doing them once, usually with a unique request key.

A weak answer: "We add a short wait so they do not collide." Waiting hides the bug; it does not fix it.

Follow-up: "Locks made it slow." Lock less (one row, not the table), hold the lock for less time, or let the database's own rules do the check.

Databases

A page is slow because of one database query. How do you speed it up?

What they check: that you measure first and know what an index does.

Short answer: "I look at the query plan, which shows how the database runs the query, to see whether it reads the whole table. Usually the fix is an index on the columns we filter or join on, fetching fewer rows and columns, or removing a query that runs once per row."

The full answer: An index is like the index of a book: the database finds rows without reading every page. I check the plan before and after, because an index that is not used only slows down writes. Common problems: no index on a column used to filter or join, a function wrapped around the column that stops the index being used, selecting every column when the page needs three, and the "N+1" problem, where the code runs one query for a list and then one more for each item. If the data is read far more than it changes, a cache can help, but then I need a plan for when the cached copy is out of date. SQLAsked in 18% of software developer ads (as of 5 Nov 2026).Write joins and aggregations, read a query plan, and know when an index helps. skills and a database such as PostgreSQLAsked in 6% of software developer ads (as of 5 Nov 2026).A common open-source database: schemas, indexes, transactions and safe migrations. come up here a lot.

A weak answer: "Add an index on every column." Each index costs space and slows down every insert and update.

Follow-up: "The query is fast in testing and slow in production." Production has far more data and different value spreads; test with realistic data volumes.

How do you change a database table safely while the application is running?

What they check: that you can ship schema changes without downtime and with a way back.

Short answer: "In small, backwards-compatible steps: add the new column, write to both old and new, copy the old data across, switch reads to the new column, and only then remove the old one. Each step is its own release, so a rollback never meets a database it cannot read."

The full answer: A migration is a scripted change to the database structure, kept in version control with the code. The risk is that the new code and the old code run at the same time during a release, so both must work with the database at every step. Large tables need care: some changes lock the table for minutes, so copy data in batches. Back up first, test the migration on a copy of production data, and know how to undo each step.

A weak answer: "Stop the app at night and run the script." Many systems cannot stop, and the night is when nobody is there to help if it goes wrong.

Follow-up: "The migration failed halfway." That is why each step is small and can be run again safely; you fix it and run it again, or undo that one step.

APIs and system design

How would you design a REST API for creating and paying for orders?

What they check: clear resources, honest errors, safe retries and room to grow.

Short answer: "Resources named as nouns, such as orders and payments, the standard HTTP methods and status codes, a request key so a retried payment is not charged twice, paging for lists, clear error messages, and a version so old clients keep working."

The full answer: In a REST APIAsked in 6% of software developer ads (as of 5 Nov 2026).Design an HTTP API with clear resources, status codes, versioning, paging and helpful errors., each thing is a resource with an address, and the HTTP method says what to do: get to read, post to create, and so on. Creating an order answers "created" with the new order's address; a bad request answers with a message that says which field is wrong. Payments must be idempotent: the client sends a unique key, and a second request with the same key returns the first result instead of charging again. Lists are paged so one call cannot return a million rows. Every call checks who is asking and what they may see. Document the API so another team can use it without asking you.

A weak answer: one address that takes an "action" field and always answers "OK", even for errors.

Follow-up: "A mobile app still uses the old version." Keep the old version running, mark it as going away, and tell its users the date.

Design a URL shortener. Walk me through your system design.

What they check: that you ask about the numbers first, start simple, and know where it breaks.

Short answer: "I would ask how many links a day and how many clicks, then start with one service and one database: store a short code next to the long address, look it up on every click, and add a cache because clicks far outnumber new links. Then I would talk about what happens when it grows or a part fails."

The full answer: A system design interview is a conversation, not a drawing contest. I agree the requirements: do links expire, can people choose their own code, do we count clicks? I estimate the load, because reads are far more common than writes here. The simple design: an API that creates a short code (for example a random code, checked against existing ones), a database table keyed by that code, and a redirect on each click. A cache in front of the database serves popular links fast. Click counting goes to a queue (a waiting line of messages processed later) so it never slows the redirect. Then the failure cases: what if the cache is down (read the database), the database is down (serve cached links), or someone uses it to spread harmful links (check new addresses and allow reports).

A weak answer: starting with microservicesAsked in 6% of software developer ads (as of 5 Nov 2026).Know when splitting a system pays off, and what it costs: network failures, data consistency, tracing., three databases and a message bus before asking how big it is.

Follow-up: "Traffic grows a hundred times." More copies of the stateless service behind a load balancer, more cache, and copies of the database for reads.

When would you split a system into microservices, and when not?

What they check: that you know the costs as well as the benefits.

Short answer: "When separate teams need to release separate parts on their own schedule, or one part needs to scale very differently. Not by default: a well-structured single application is simpler to build, test and run, and many teams should start there."

The full answer: Microservices are small services that each own one job and their own data, and talk over the network. They let teams work and release independently. The price is real: network calls fail and are slow, data is spread out so keeping it consistent is harder, and you need tracing to follow a request across services, plus more automation for deployments. A "modular monolith", one application with clear internal boundaries, gives much of the structure without that price, and can be split later along those same boundaries.

A weak answer: "Microservices are always more modern."

Follow-up: "Two services both need the customer's address." One service owns it; the other asks it, or keeps a copy that is updated by events.

Shipping and running software

A release goes wrong in production. What is your rollback plan?

What they check: that you plan for failure before you ship.

Short answer: "Every release can be undone in minutes: the previous version stays ready, database changes are backwards-compatible, and risky features sit behind a switch I can turn off without a deploy. We watch errors and speed right after the release and roll back on a clear signal."

The full answer: A rollback means going back to the last working version. It is only quick if it was prepared: the pipeline can redeploy the previous build, and the database still works with it. Feature flags (switches in configuration) let you turn off a new feature without redeploying. Release to a small share of users first, which is often called a canary release, and compare their error rate with everyone else's. After the incident, write a short, blameless review: what happened, why it was not caught, and what we change.

A weak answer: "We test carefully, so releases do not go wrong."

Follow-up: "The bad release already changed customer data." Rolling back the code is not enough: find the affected records, repair them, and tell the people affected if needed.

What happens between your merge and the code running in production?

What they check: that you understand the pipeline and own your code after the merge.

Short answer: "The CI/CDAsked in 29% of software developer ads (as of 5 Nov 2026).Every change is built and tested automatically; a green pipeline can ship, a red one stops the release. pipeline builds the code, runs the tests and checks, builds an image, deploys it to a test environment, then to production, often step by step. Then I watch the logs and dashboards to see that it works."

The full answer: CI, continuous integration, means every change is merged often and checked automatically: build, unit tests, a scan of the libraries for known security holes. CD, continuous delivery, means a change that passes can be released at any time, by a button or automatically. The result is usually a DockerAsked in 12% of software developer ads (as of 5 Nov 2026).Package a service and its dependencies into an image that runs the same on a laptop and in production. image, deployed by a platform such as KubernetesAsked in 11% of software developer ads (as of 5 Nov 2026).Run containers at scale: deployments, health checks, scaling and config; often shared with a platform team. or a cloud service, which checks that new copies are healthy before old ones are stopped. Good teams release small changes often, because a small change is easy to check and easy to undo.

A weak answer: "After I merge, operations take care of it."

Follow-up: "The pipeline takes forty minutes." Run tests in parallel, cache the build, and move the slowest tests to a later stage that does not block every change.

Security

What is SQL injection, and how does your code prevent it?

What they check: that you know the most common attacks and the standard defences.

Short answer: "SQL injection is when user input is glued into a database query, so an attacker can change the query itself. I prevent it with parameterised queries, where the input is passed separately and is never read as part of the query, plus least-privilege database accounts."

The full answer: The rule behind it is wider: never trust input from outside. For the database, use parameterised queries or a library that does it for you. For web pages, escape output so input cannot become a script (that attack is called cross-site scripting). Check access rights on the server for every request, not only in the browser. Keep secrets such as passwords and keys out of the code. Keep libraries up to date, because many attacks use old, known holes. The OWASP Top 10 is the usual checklist of web risks, and securityAsked in 5% of software developer ads (as of 5 Nov 2026).The common attacks on web software and how code prevents them; the OWASP Top 10 is the usual list. questions often follow it.

A weak answer: "We remove quote marks from the input." Filters miss cases; parameters do not.

Follow-up: "Where do you keep the database password?" In a secrets store or the platform's secret settings, never in the code or the repository.

Working in a team

How do you estimate a task, and what do you do when you will miss the estimate?

What they check: honesty, splitting work into pieces, and telling people early.

Short answer: "I split the task into small pieces I understand, estimate those, and add time for the unknowns. If I see I will miss it, I say so as soon as I know, with what is done, what is left and the options: cut scope, get help, or move the date."

The full answer: Estimates go wrong on the parts we have not thought about, so the first step is to list them: the change itself, tests, the review, the migration, the documentation. Unknowns get a short investigation first, sometimes called a spike. In agileAsked in 10% of software developer ads (as of 5 Nov 2026).Short cycles of planning, building and showing work; adjust the plan from what you learn. teams, estimates are often relative (this is about twice that) rather than in hours, and the team compares plan with result to get better. The worst outcome is a surprise on the last day.

A weak answer: "I always finish on time." Nobody believes it.

Follow-up: "Your manager wants a date today for something nobody has built before." Give a range and say what would make it narrower, then update it after the first week.

You disagree with a technical decision your team lead has made. What do you do?

What they check: that you can disagree well and then commit.

Short answer: "I ask to understand the reasons first, then explain my concern with facts, such as a measurement, an example or a small test. If the lead still decides the other way, I support the decision and we agree how we will know if it works."

The full answer: Most disagreements come from different information, so I start by asking. I put my view in writing if it matters: the options, the trade-offs, what I recommend and why. A quick prototype or a measurement often settles it better than a debate. Once a decision is made, I do not keep reopening it, but we agree a point at which we will check, for example after the first release.

A weak answer: "I would just do it my way."

Follow-up: "You turned out to be right." Say what you learned about making the case earlier, and help fix it without blame.

Your CV for these questions

Every answer above is easier when your CV already says it, because interviewers ask about what is on it. Put one line under each job for each of these, in the words the ads use:

Then score your CV against a real job: you will see which of these the job needs and which your CV does not prove yet.