Software Engineer and Software Developer Interview Questions and Answers (2026)

Do not change it blind. First learn what it does by reading it, running it and talking to anyone who knows it. Add tests that capture its current behaviour, then make the smallest change that delivers the feature, and leave the code a little clearer than I found it.

I inherited an invoicing module with no tests, and I had a week to add a discount rule. I read through it with the debugger and wrote down what each function took and returned. Then I wrote tests around the existing behaviour, using real invoices from last month as examples, so I would know if I changed any totals. That took two days but gave me confidence. I asked the developer who had worked on it last for twenty minutes, and she warned me about a rounding rule that was not documented. I added the discount in a new small function, called from one place, and ran the tests. I left a short note in the readme explaining the rounding rule and the new tests. The change shipped on time and the finance team found no differences.

Measure before changing anything. Reproduce the slow case with the affected customer's data, look at the query plan and time each part of the request. Common causes are missing indexes, large data volumes or repeated queries, but I would find the evidence, not guess.

A dashboard loaded in a second for most customers and eight for a few. I asked support which customers were affected and found they were the ones with the most orders. I reproduced it locally with a copy of one account's data and turned on query logging. A single page was running over 400 queries: for each order it fetched the customer's addresses separately. With few orders, nobody noticed. I confirmed it with a profile before changing anything. I replaced the repeated queries with one query that fetched all addresses for the page and added an index on the foreign key. The load time for the largest account fell below a second. I wrote a test that checks the number of queries for a page with fifty orders, so the problem cannot return unnoticed, and shared the finding in the team channel.

Stop the harm first: roll back or switch off the feature, and tell the people who need to know. Then work out which records are affected, plan how to repair them, fix and test the cause, and hold a blame-free review. Do not start debugging live while the damage continues.

On a Friday afternoon, support told me customers' delivery addresses were being overwritten after a morning release. I told the team lead in our channel that I was investigating, and asked for the release to be rolled back, which took ten minutes. That stopped new damage. Next I queried the audit table to find affected records: about 300, all updated by one endpoint. I wrote a script to restore addresses from the previous day's backup, tested it on a copy and had a colleague review it before running it. The cause was a missing condition in an update query that I had reviewed but not tested against partial updates. I added a test for it and fixed the query. On Monday we reviewed what let it through, without blame, and added a check to the release process for data-changing endpoints. I emailed the affected customers through support.

Find out whether it is a principle or a preference. Ask for their reasoning, share mine with an example, and see if the team already has a convention. If not, propose agreeing one and automating it with a linter, so the argument is settled once.

A senior developer blocked my pull request because I had used a different way of structuring error handling. I felt mine was clearer. Rather than argue in comments, I asked him for ten minutes on a call. He explained that his pattern made errors easier to find in logs, which I had not considered. I showed him a case where my version made the happy path easier to read. We found that the team had no written convention. I suggested we agree on one and write it into the contributing file, and he agreed to take it to the next team meeting. Meanwhile I changed my pull request to follow his pattern, as his reason was sound for our logging. We later added a linter rule so such points do not need discussing in reviews.

Be clear that payment changes carry high risk, so skipping tests is not a saving. Offer options that still meet the date: reduce the scope, test the riskiest paths first, or release behind a feature flag to a small group. Put my concern in writing so the decision is shared.

Before a launch, my manager suggested we skip testing on a change to the payment flow because the date was fixed. I said I understood the pressure, but that mistakes in payments hurt customers and are expensive to unpick. I did not just refuse. I proposed three options: ship the simpler version without the saved-cards feature, which was where most of the risk sat, test only the main payment paths and the refund path, or release to ten per cent of users behind a feature flag. He chose the second with the flag. I wrote the tests that evening, found a bug in refunds and fixed it, and we launched on the date. I sent a short note afterwards listing what we had tested and what we had deferred, so that nobody was surprised later.

Revoke or rotate the key immediately, because removing it from the repository does not make it safe. Then tell the team and security, check logs for misuse, clean up the history if needed, and add a secrets scanner and a safer way to handle keys.

I once pushed a configuration file that contained a third-party API key to a shared repository. I noticed within minutes. I logged into the provider's dashboard and revoked the key, then generated a new one. I told my team lead and the security contact straight away, in writing, with the time and what had been exposed. I checked the provider's usage logs and found no unusual calls. I removed the file from the repository and its history with the team's agreed procedure, and moved the key to our secrets manager. Afterwards I added a pre-commit secrets scan and a line in the readme about environment variables. The security lead thanked me for reporting it quickly. I would say that being open early turned a mistake into a small process improvement.

Find where the library is used and whether the vulnerable feature is reachable. Check the advisory for affected versions and fixes, prioritise exposed services first, patch or mitigate, test and deploy. Record what I found, and tell the owners of any service I cannot update quickly.

When a critical advisory was published for a logging library, I used our dependency report to list every service that included it, directly or through another package. I read the advisory and learned that only versions before a certain release were affected, and only if a particular feature was on. Of eleven services, six used an affected version and two of those had the feature enabled and were internet-facing. I patched those two first, ran their test suites and deployed them the same day. I disabled the feature as a temporary mitigation on a third service that could not be upgraded until the following week. I then updated the remaining services in the normal cycle. I posted a short summary for the team with the services, versions and dates. We also set up automatic alerts for new advisories.

Never trust input. Use parameterised queries to prevent injection, validate input on the server, and encode output for where it is shown to prevent cross-site scripting. Also check who is allowed to see or change each item, and log failures without exposing details.

For a comments form that saves to a database and shows to other users, I would think about two things: what goes in and what comes out. For input, I would use parameterised queries through the database library, never string-built SQL, so a comment containing quotes cannot change the query. I would validate length and type on the server, and not just in the browser. For output, I would encode comments for the context where they appear, so that a comment containing a script tag is shown as text and does not run. I would use the framework's templating rather than writing HTML by hand. I would check on each request that the user has permission, rather than relying on hidden fields. Finally, I would write tests with hostile strings, and rate-limit the endpoint to deter abuse.

Give a range, not a single number, and name the assumptions and unknowns behind it. Break the task down, do a small spike to reduce the biggest unknown, and offer options on scope when I am pushed to go faster.

Asked to estimate adding a new payment provider, which I had never integrated, I said I could give a range after a short spike. I spent half a day reading their documentation and building a test call in their sandbox. The unknowns became clear: webhook handling and the refund flow. I broke the work into pieces and estimated each as a best and worst case. I told the product owner it would take three to five weeks, depending on the refund flow, and that I would know more after the first week. She asked for two. I said we could meet two weeks if we launched with payments only and left refunds for a second release. She agreed. I shared my assumptions in the ticket and updated the estimate after week one, when it came in at the lower end of the range.