Performance Optimization Interview Questions: Measure, Then Change One Thing

Asked how you optimised something, weaker candidates list techniques: added a cache, added an index, increased the pool. Those are conclusions with the reasoning removed, and the interviewer cannot tell whether you found the bottleneck or guessed and got lucky.

The answer that scores is a method: what was slow from the user's perspective, how you located the time, what hypothesis you formed, what you changed, and how you confirmed it worked. Every technique belongs inside that frame.

Say what the target was before you started. Faster is not a target; the ninety-fifth percentile of one endpoint under peak load is.

Be precise about percentiles. An average that improved while the tail got worse is a common outcome and knowing to check separates people who have done this from people who have read about it.

Say where the time actually was. A profile, a trace, a breakdown by stage. The frequent and honest answer is that the time was somewhere nobody expected, and interviewers respond well to that because it is what really happens.

Changing several things at once and observing an improvement teaches you nothing about which one worked, and leaves you unable to answer the follow-up.

Say what you measured after, under what conditions, and whether the effect held under real traffic rather than only in a benchmark. Benchmarks that did not survive production are a good story, not a bad one.

Say what the change cost. More memory, more complexity, a cache that now needs invalidating, a denormalised table that can drift. An optimisation presented as free is an optimisation whose costs were not examined.

Expect to be asked how you knew it was enough. Optimisation without a stopping condition consumes unbounded engineering time for diminishing user benefit.

The strong answer ties stopping to the requirement: the target was met, the next bottleneck was elsewhere, or the remaining gain no longer justified the complexity.

Have one case where you decided not to optimise. Understanding that a slow path called twice a day is not worth engineering is judgment, and it is scored as such.