What they're testing
Whether you have the discipline to measure before changing, and whether you separate symptom from cause.
The short answer~30 seconds
I ask three questions before opening an editor: which endpoint and at which percentile, since when (does it correlate with a deploy), and what the target is. Then I look at a trace to see where the time goes — usually 80% is in one place, and it's almost never the place people guessed. Only then do I change anything, and I measure again to prove it worked.
The long answer
The "compared to what" question matters more than it looks. With no target, optimisation has no stopping condition, and you can spend three weeks taking 800ms to 600ms when users need 200ms — three weeks invested in an approach that could never arrive. Knowing the target up front decides whether you tune or redesign.
On tooling, distributed tracing gives the accurate picture fastest because it shows which tier holds the time; a CPU profiler is only useful once you know CPU is the bottleneck. In practice most slow APIs aren't CPU-bound but WAITING: on the database, on another service, on a lock. Opening a CPU profiler first is a very common way to look in the wrong place for two days.
One more senior-level point: sometimes the right answer isn't making it faster but making it unnecessary. Slow because it aggregates data for a dashboard opened three times a day? Precompute on a schedule. Slow because it returns 5,000 rows the UI renders 20 of? Change the contract. Those move the time by an order of magnitude, where query tuning moves it by tens of percent.
What they'll ask next
?Where do you start without tracing?
Coarse timing logs at a few boundaries — entering the handler, around each external call, before responding. Crude, but enough to localise it in an afternoon, and usually the first step toward justifying real tracing.
?How do you keep the regression from coming back?
A budget in CI: response time or query count for that endpoint, failing the build when exceeded. Without an automated threshold, performance only moves one way — worse, one unnoticed PR at a time.
These lose points
- Starting with "add a cache". You don't yet know what's slow, and a cache can hide the problem instead of fixing it.
- Micro-optimising code when the real time is in one database query. The most common form of wasted effort there is.