Software Engineer Interview Questions and Answers

We needed order history to load in under 300 ms for accounts with several years of data. The obvious option was to denormalize everything into one wide table, which is fast to read but painful to keep consistent. The other was to keep normalized tables and add a read model updated from an event stream. I chose the read model because writes were already event-driven and we could rebuild it from scratch if it drifted. The cost was eventual consistency: a newly placed order could take up to two seconds to appear in history, so we show an optimistic row on the client. With hindsight I would have added a rebuild runbook on day one instead of week three, because the first schema change was stressful without it.

First I check whether users are still affected; if yes, I roll back or disable the offending flag before investigating, because every minute of debugging is a minute of outage. Then I look at the blast radius: which endpoints, which regions, which deploy version. I compare the error rate against the deploy timeline, because most incidents are change-related. If the signal is ambiguous, I add temporary structured logging at the suspected boundary rather than guessing. Once I have a root cause, I fix it behind the same flag, verify with the metric that first alerted us, and then write a short postmortem whose only action item is the guardrail that would have caught it earlier — typically an alert or a test, not a promise to be careful.

A teammate wanted to adopt a new message broker for a workload of a few thousand events a day. I argued that our existing database-backed queue was sufficient and that a new broker meant a new on-call surface, new dashboards and a new failure mode. I brought the numbers: our peak was under ten events a second and our retention requirement was minutes, not days. We took it to a short design review, and the team decided to stay with the existing queue but add a migration path if throughput grew tenfold. I disagreed with the original proposal, not the person, and once the call was made I wrote the runbook for the existing queue. Six months later the volume had not grown, so the simpler choice held.

I test where a bug would be expensive and hard to reverse. Pure functions and pricing rules get dense unit tests because they are cheap to run and easy to get subtly wrong. Anything crossing a process boundary gets a contract test, because most outages I have seen live at the seams, not inside a function. For user-facing journeys I keep a thin end-to-end suite, one test per revenue-critical path, because those are slow and flaky and a large suite becomes a liability. I deliberately do not chase a coverage number: a getter at 100 percent coverage adds no safety. What I do insist on is that any bug that reaches production gets a regression test before the fix, so the same class of failure cannot return silently.

I would not start by refactoring, because I cannot prove a refactor is safe without tests and I cannot see what is failing without telemetry. First week: add RED metrics for the service and alert on the symptom that page the team most often, so the next outage is detected in minutes instead of reported by a customer. Second: find the most frequent outage cause and remove it, usually a missing timeout, an unbounded query or a deploy with no health gate. Third: wrap the two or three paths I must change in characterization tests that pin current behavior, warts included, so I can refactor with a safety net. Only then do I propose a refactoring plan to the team, sliced so each step is independently deployable and reversible. Trying to fix everything at once is how these services stay broken.

Think of a book without an index: to find every mention of a word you read every page. That is a database scanning a whole table, and it is why a search screen gets slow as the table grows. An index is the back-of-book index: instead of reading everything, the database jumps straight to the matching rows. It is not free — every time we save a record we also update the index, so writes get slightly slower and the index takes disk space. That trade is worth it when we read far more than we write. So when you ask me to make the customer list fast, the question I will ask back is which columns you filter and sort by, because that decides which index buys the most speed for the least write cost.

I shipped a schema migration that added a non-null column with a default, and on a large table it locked writes for about ninety seconds during peak traffic. I owned it in the incident channel immediately, we rolled back the migration, and the site recovered. The mechanism was that I had tested the migration on a copy that was a fraction of the production size, so the lock duration looked negligible. I added a pre-migration checklist that requires a row-count estimate and an explicit lock-duration test on production-scale data, and we moved to the expand/contract pattern for all subsequent schema changes. The lasting change for me was refusing to treat 'works on staging' as evidence for anything that touches table locks.

I start by splitting the work into what I have done before and what I have not, because those have different error bars. For the unknown parts I try to name the specific risk — an unfamiliar API, a data model I cannot see, a third-party integration without documentation — and I timebox a short spike to convert the unknown into a known. Then I give a range rather than a number, and I write down the assumption the range depends on, for example that we do not need to backfill historical records. At each checkpoint I re-estimate and say plainly if the range moved, because a slip surfaced on day two is a planning problem while the same slip on the last day is an incident. I would rather deliver an honest range early than a confident date I cannot defend.

Lead each bullet with the outcome and the number, then the method: 'Cut p95 latency 40% by …', not 'Worked on caching with Redis'.

Spell out the technology and the business domain once; a recruiter or ATS may see only this line.

Match the scope to the years shown: lead with ownership of a component at three years and of a system at seven, rather than borrowing the senior vocabulary early.