Optimizing Performance

Tell a performance story the way a careful engineer works: measure first, find the real bottleneck, fix it, prove the gain and keep it from coming back.

Overview

Performance questions ask about a time you made something faster or cheaper. The interviewer is checking your method more than your result. Did you measure before you changed anything? Did you find where the time actually went, or guess? Did you pick a target that mattered to users or cost? And did you ship the change safely and keep it from slowly getting worse again?

The weakest answer is 'I refactored the code and it got faster'. Without a baseline and a measurement after, nobody can tell a real improvement from luck, and the interviewer will assume you guessed.

Baseline — Numbers before the change, and how they were measured — 'It was slow'
Diagnosis — A profile or trace pointed to the cause — A hunch
Target — A percentile and a load, tied to users or cost — 'Make it fast'
Rollout — Canary or flag, compared against the old version — Shipped to everyone at once
Lasting — A test or alert that catches regressions — Improvement faded within months

The stories on this page are fictional examples.

What you will be able to do

Tell a performance story as a measured loop, with numbers before and after.
Explain why percentiles such as p99 matter more than averages.
Set a target that says the metric, the percentile and the load.
Name the common mistakes and how you avoided them.

Interview questions

Tell me about a time you improved a system's performance
How do you find a performance bottleneck?
How do you set a performance target?
What are common performance optimization mistakes?

Optimizing Performance

Overview

What you will be able to do

Interview questions

More Behavioral topics