A deployment completes successfully. Twenty minutes later latency has tripled, but only on new instances. Diagnose.

What the interviewer is testing

Whether you distinguish cold-start effects from a genuine code regression, since the remedies are opposite.

The candidates specific to new instances

Cold caches. Local caches, connection pools, DNS caches and any warmed state are empty. If the service depends on a warm cache to meet its latency target, new instances will miss it until warmed — and if the cache is shared and was also flushed, the effect is worse.

JIT compilation. Runtimes like the JVM interpret before optimising, so a freshly started process is substantially slower for minutes until hot paths compile.

Connection pool ramp. Pools start empty and grow on demand, so early requests pay connection establishment including TLS handshakes.

Cold page cache and lazy loading in any local store.

All of these resolve on their own. Distinguishing them from a real regression is the point.

The distinguishing test

Does latency improve over time on a given instance? Plot latency per instance against its age. If it declines and converges towards the old instances' figure, it is warm-up. If it stays elevated indefinitely, it is a code or configuration regression.

That single chart resolves the question in minutes and is worth having as a standing dashboard.

If it is a code regression

Compare traces between old and new instances for the same operation to find where the additional time is spent. Common causes: an added synchronous call, a changed query, a dependency upgrade with different defaults, a serialisation change, or a configuration difference.

If it is warm-up

Readiness gating that does not admit an instance until it is genuinely ready.

Pre-warming at start-up — populate caches, establish pool connections, exercise hot paths — before signalling readiness.

Slower rollout, so warm-up cost is spread rather than concentrated.

Minimum pool sizes, so connections exist before traffic arrives.

What a strong answer adds

This is precisely why canary analysis must compare against a baseline deployed at the same time rather than against long-running production instances. Otherwise every canary looks worse for reasons that have nothing to do with the change, teams learn to discount the difference — and then discount a real regression.

Common weak answers

Rolling back immediately without determining which it is. Assuming warm-up without checking whether latency actually improves.