Interview prompt. A partner integration team reports intermittent request timeouts against an endpoint whose server-side p99 is 200 ms. None of your dashboards are red and no error rate has moved. Take it from here.

What the interviewer is testing

Whether you know that a server's latency histogram measures a window that excludes most of what a client experiences. The handler timer starts when the request is dispatched to application code. Everything before that - DNS, TCP, TLS, the proxy's queue, the accept backlog - and everything after the last byte is written is invisible to it. A candidate who starts tuning the server has not noticed that the evidence does not cover the symptom.

The clarifying questions that change the answer

• Which timeout is firing - connect, TLS handshake, read, or a total-request deadline? They have different causes and the partner probably has one number configured for all of them.
• Where are the clients, and is the connection new? A fresh TLS connection costs about 3 round trips before the first request byte moves. For a platform operating in markets of Grab's kind, where partner round-trip times can run 250 to 400 ms, that is a second of setup before any server-side work, and a 1-second total timeout fails with a perfectly healthy server.
• Is the client pooling connections or opening one per request? A per-request connection pays setup every time, and a pool that is too small queues on the client side - invisible to both sides' server metrics.
• What does the client's own percentile look like, and over how many requests? "Intermittent" across a small volume may be 1 in 500, which no server-side percentile will show.
• What sits in between? A load balancer with its own queue and its own idle timeout, a partner-side egress proxy, an API gateway that re-resolves DNS on a long TTL.

A strong answer's arc

Measure the thing that is being complained about. Add a client-perceived measurement - a synthetic probe from the partner's region, or the partner's own instrumentation - and compare it with the edge's measurement and the handler's. The gap between the three localises the problem within one iteration: handler versus edge isolates server queueing and the accept backlog, edge versus client isolates the network and connection setup.

Then look for the specific suspects that produce an intermittent pattern with flat averages: listen-backlog overflow during bursts (a counter, not a latency), a connection pool hitting its ceiling, TLS session resumption not working so every connection is a full handshake, a DNS record whose TTL causes a periodic re-resolution stall, and keep-alive idle timeouts that are shorter on the server than on the client - which produces a race where the client sends on a connection the server has just closed.

Common weak answers

• "Raise the timeout." It converts a visible failure into a slow path and tells you nothing. It may still be the right short-term action, and say so explicitly rather than silently.
• "Add retries." Each retry re-establishes a connection, so a retry during a setup-bound failure multiplies exactly the work that is already too slow.
• "The network is bad." Possibly, and unactionable until you have split setup time from transfer time.

What a strong answer adds

Three things. A measurement that the two teams agree on, so the conversation stops being one dashboard against another. Separate connect and read timeouts with a stated budget, because one number cannot express both. And the organisational point: if the cause is the partner's SDK not reusing connections, the fix lives in their code, which makes this a documentation and client-library problem, not a server problem - and the thing to ship is a hardened client and a published guidance page, not a configuration change on your side.