Mean vs. Median for API Response Times?
Tests your understanding of non-normal distributions like latency. Choose median as it's robust to outliers that skew the mean. Then, state that even median is insufficient; percentiles (p99, max) are crucial for capturing the full user experience.
What's really being asked
This question isn't just about mean vs. median. It's a probe to see if you understand the nature of latency distributions. Interviewers want to know if you recognize that latency is rarely a normal distribution and is often characterized by a long tail of slow requests (outliers). Your choice reveals your philosophy on what "performance" means: the typical case, or the full range of user experiences, including the worst ones.
The full answer
A good answer has three parts. First, state a clear preference for the median. Explain that the median (the 50th percentile) is robust to outliers. A single 30-second request won't significantly change the median if most requests are 200ms, but it will dramatically skew the mean. Second, describe the pitfall of the mean. The mean is sensitive to extreme values. If you have 99 requests at 100ms and one request at 10,000ms, the mean is 199ms, which is double the typical experience. The median remains 100ms. This makes the mean a poor indicator of the typical user's experience. Third, and most importantly for a senior role, explain that even the median is insufficient. You must also report on tail latencies using percentiles like the 99th and 99.9th, and always track the maximum value. These "outliers" are not noise; they represent real, frustrated users.
The mistakes people make
A common mistake is to say the mean is fine for a general idea. This misses the point about non-normal distributions. Another red flag is suggesting that outliers (like the max value) should be "cleaned" or ignored. Foundational work in this area argues the max value is the most important signal, not noise. Saying "it depends" without taking a stance and explaining the trade-offs is also a weak answer. Finally, just answering "median" without explaining why and what its limitations are is a junior-level response.
What usually comes next
"Okay, so you're using p50, p99, and max. How would you set an SLO for this service?" or "If you can only choose one metric to alert on, which one is it and why?" or "You see a spike in the p99 latency but not the median. What are your first steps to investigate?"
A concrete example
Imagine an API with 100 requests. 99 of them take 200ms. One request, due to a GC pause or network hiccup, takes 15 seconds (15,000ms). The median is 200ms, accurately reflecting the experience for 99% of requests. The mean, however, is (99 * 200 + 15000) / 100 = 348ms. Reporting a 348ms average is misleading; it suggests a systemic slowness that doesn't exist, while simultaneously hiding the extreme pain of that one request. The p100 (max) is 15s, which is a critical signal to investigate.
Interview question
Which approach to measuring API latency provides the most complete picture of user experience, from typical to worst-case scenarios?
- a.The median for the typical case, supplemented with high percentiles (e.g., p99) to capture tail latency.Correct
- b.The median response time, because it accurately represents the typical user experience by ignoring outliers.
- c.The mean response time after filtering out the slowest 1% of requests to reduce noise.
- d.The mean (average) response time, as it incorporates data from every single request.
Why? this is the answer
The median shows the typical experience, while high percentiles reveal the 'long tail' of slow requests affecting real users. Using only the mean is misleading as it's skewed by outliers, while using only the median hides the experience of the unhappiest users.
Just read this? Test yourself on what you have been reading.
Read the original → bravenewgeek.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on analytics — each one lists the topics its interview covers.
See open roles