Software Engineer interview questions

I treat this as a deploy-linked performance regression and narrow it down with metrics, traces, and a controlled comparison.

• I start by comparing the deploy diff and correlating the latency jump to the exact deploy timestamp on the metrics dashboard, then check p50 versus p99 to see if it is a broad shift or a tail regression.
• Missing errors usually point at added work rather than failures, so I look for new synchronous calls, N+1 queries, a dropped cache, or a config change like connection pool size.
• I pull traces for slow requests to find which span grew, and if needed I run the old and new build side by side under the same load to confirm the regression.

I distinguish CPU-bound from I/O-bound latency with profiles, utilization metrics, and traces before choosing a fix.

• I check whether CPU time tracks wall-clock time by sampling with a profiler like py-spy or perf: if on-CPU time dominates the request duration it is CPU-bound, and if the thread mostly waits on sockets or disk it is I/O-bound.
• Metrics help too, since high CPU utilization with low iowait suggests compute, while low CPU with long external-call spans in traces points to I/O.
• The fix differs: CPU-bound work wants algorithmic improvements, caching, or parallelism, while I/O-bound work wants batching, connection pooling, concurrency, or removing round trips entirely.

I find memory leaks by measuring retained heap growth, tracing ownership, and proving the fix under sustained load.

• I capture heap snapshots at intervals and diff them to see which object types keep growing, using tools like Chrome DevTools or the Node heap profiler for JS, or tracemalloc and objgraph for Python.
• A steadily rising RSS with a growing retained set usually means references are held somewhere, often caches without eviction, event listeners that are never removed, or unbounded queues.
• Once I spot the growing type I trace its retaining path back to the owning structure, fix the retention, and confirm with a soak test that memory plateaus.

I treat a bug that vanishes under observation as a likely timing-sensitive Heisenbug and investigate it with low-overhead tools.

• This is a classic Heisenbug, and it usually means a timing or concurrency issue where logging shifts the schedule enough to hide a race, or the debugger serializes threads that normally interleave.
• It can also be uninitialized memory or a compiler optimization that a debug build changes.
• I proceed by adding low-overhead observation like counters, ring buffers, or a thread sanitizer instead of blocking logs, and I stress the concurrency with more threads and randomized delays to make the race reproducible.

I profile a realistic workload and optimize the widest meaningful hot paths rather than visually prominent frames.

• I run a sampling profiler under a realistic workload and read the flame graph, looking for the widest frames that represent the largest share of total time rather than the deepest stacks.
• Common mistakes include profiling a warmup or unrepresentative load, trusting a single run instead of aggregating, confusing self time with total time, and optimizing a function that looks hot but is only 2 percent of real traffic.
• I also watch for observer effect from heavy instrumentation and prefer sampling over full tracing for production-like numbers.

I reproduce the failure under controlled load and then look for contention, saturation, and resource limits.

• I reproduce the load first with a tool like k6, Locust, or wrk so the issue becomes observable, then watch saturation signals: thread pool and connection pool exhaustion, lock contention, GC pauses, and queue depth.
• Problems that surface only under load are usually contention or resource limits rather than logic bugs, so I look at pool sizing, timeouts, and backpressure.
• Continuous profiling and per-request traces during the load test show me where time and waiting concentrate as concurrency rises.

I trace one request end to end with a propagated trace identifier and fall back to correlated logs when necessary.

• I use distributed tracing with a correlation or trace id propagated across service boundaries, for example via OpenTelemetry and W3C trace context headers, so one request produces a single connected trace in Jaeger or Tempo.
• I search by that trace id to see the full span tree, spot which hop errored or timed out, and read tags for status codes and retries.
• If tracing is missing, I fall back to a request id logged at each service and stitch the logs together in the log aggregator.

I use metrics to detect a problem, traces to locate it, and logs to explain the specific event.

• Metrics are cheap aggregate numbers over time that answer whether something is wrong and how often, so I use them for dashboards and alerts.
• Logs are discrete events with detail that answer what exactly happened in one case, useful once an alert fires and I need context.
• Traces show the path and timing of one request across components, answering where the latency or failure lives, and together they form a flow of alert on a metric, find the request with a trace, read the logs for detail.

I confirm a dependency bug with an isolated reproduction before escalating it or introducing a workaround.

• First I isolate the suspect by writing a minimal reproduction that calls the library directly with the same inputs, ruling out my own wrapper code.
• Then I check the library's issue tracker and changelog for known bugs on my version, pin and bisect versions to find where behavior changed, and read the relevant source since it is available.
• If confirmed I file an upstream issue with the repro, apply a local workaround or patch such as a fork or a monkeypatch, and pin a safe version until a fix lands.

I pair each database-timeout hypothesis with a concrete measurement and correlate the evidence with the timing of spikes.

• My first hypotheses are connection pool exhaustion, lock contention or long transactions, a missing index causing occasional full scans, and resource saturation on the database host.
• I test them with pool utilization metrics, the slow query log and pg_stat_activity for blocking, EXPLAIN ANALYZE on the suspect queries, and host-level CPU, IO, and memory graphs during the spikes.
• Intermittent usually means it correlates with something, so I line the timeouts up against traffic peaks, batch jobs, or lock waits to find the trigger.

I choose the test mix by risk, boundary complexity, feedback speed, and the criticality of user journeys.

• I follow the test pyramid idea: many fast unit tests for logic and edge cases, a solid layer of integration tests for the parts that touch real boundaries like the database or a queue, and a thin set of end-to-end tests for the few critical user journeys.
• The balance depends on where the risk and complexity live, so a service heavy on orchestration and I/O needs more integration tests than a pure calculation library.
• I optimize for confidence per second of runtime and avoid a top-heavy suite of slow, flaky end-to-end tests.

I replace routine external API calls with controlled test doubles while retaining a smaller real integration check.

• I isolate the external call behind an interface and inject a fake in tests, and for HTTP I stand up a stub server like WireMock or a recorded fixture so no real network call happens.
• Contract tests or a recorded cassette keep the stub honest against the real API shape, and I run a small number of real calls in a separate, less frequent integration suite.
• This keeps the common test run fast, deterministic, and free of flakiness from rate limits or downtime.

Contract tests verify that independently deployed consumers and providers still agree on their interface.

• Contract tests verify that a provider and a consumer agree on the shape and semantics of their interface without spinning up both systems together, typically with a tool like Pact.
• The consumer records its expectations as a contract, and the provider replays them in CI to prove it still satisfies every consumer.
• They solve the problem of independently deployed teams breaking each other silently, catching incompatible changes before they reach production.

Mocks make tests worse when they couple the suite to implementation details or misrepresent real dependencies.

• Mocks hurt when they over-specify interactions so the test asserts how the code works rather than what it produces, making every refactor break the tests.
• They also mislead when a mock drifts from the real dependency's behavior, giving green tests against a fantasy, and when you mock types you do not own so the stub encodes wrong assumptions.
• I prefer mocking at true boundaries, using real objects or fakes for in-process collaborators, and testing observable outcomes over call sequences.

I restore trust in a flaky suite by separating known noise, fixing root causes, and making red builds meaningful again.

• I make flakiness visible by quarantining known-flaky tests into a separate lane and tracking a flaky rate, so the main build goes back to green-means-green and red actually blocks merges again.
• Then I fix root causes one by one: shared state and test order, real time and sleeps, network and timing races, and nondeterministic ordering.
• Restoring trust in the signal is the real goal, because a suite everyone ignores gives zero protection no matter how many tests it holds.

I make time an injected dependency so time-sensitive behavior can be tested deterministically without sleeping.

• I never read the wall clock directly in business logic, I inject a clock abstraction so tests can supply a fake or fixed time and advance it deterministically, using tools like libfaketime or a controllable clock in the language.
• For scheduled jobs I test the trigger logic separately from the schedule and verify boundaries like just before and just after expiry.
• This makes token expiry, retries with backoff, and cron windows fully reproducible without waiting real seconds.

I add protection around risky legacy behavior first, then create seams that permit more focused tests and safe changes.

• I start with characterization tests that pin the current behavior, even if it is quirky, so I have a safety net before changing anything, following Michael Feathers' approach of finding seams to break dependencies.
• I add tests at the highest level I can reach cheaply first, often around a whole module, then push coverage down as I introduce seams and injection points.
• Priority goes to the code I am about to change and the highest-risk paths, not chasing a coverage number across dead code.

I test failure handling by deliberately creating faults and verifying the complete, correct recovery behavior.

• I deliberately force failures by injecting faults: making a mock throw, returning error responses, simulating timeouts and dropped connections, and feeding malformed input.
• I assert not just that it fails but that it fails correctly, with the right status, a clean rollback, no resource leak, and a useful message, and I check that retries and fallbacks actually trigger.
• Fault injection and tools like a fault-injecting proxy or chaos experiments help cover the paths that rarely run in normal operation.

A fast suite minimizes expensive boundaries and preserves a short, reliable feedback loop for the team.

• Speed comes from keeping most tests in-process and pure, avoiding real I/O, sharing expensive setup, running in parallel, and using test containers only where a real dependency is essential.
• Slow suites get run less often, so bugs are found later and developers lose flow while waiting, which quietly erodes the whole feedback loop.
• I treat suite time as a first-class metric and budget it, since a suite that runs in seconds gets run on every save while a twenty-minute suite gets skipped.

I use TDD for understood, non-trivial behavior and relax it during genuine exploration or for disposable code.

• I use TDD where the behavior is well understood and the logic is non-trivial: write a failing test, make it pass simply, then refactor, which keeps the design testable and the feedback tight.
• I skip or relax it when I am exploring an unknown design or spiking a prototype where the interface is still fluid, and for trivial glue code or throwaway scripts.
• Even then I usually backfill tests once the shape settles, so the exploration does not ship untested.