What specific metrics define a 'fast' report export?
Turning vague promises into precise SLIs and SLOs.
Propose user-facing latency percentiles and throughput; split SLI from SLO target; pick realistic targets.
Only infra metrics like CPU, not user latency.
WHAT THIS TESTS: This question tests whether you can decompose a vague product adjective into rigorous, quantitative service level indicators and objectives. Interviewers want to see that you understand the difference between a metric and a target, and that you choose measurements that reflect the user experience rather than internal system health.
A GOOD ANSWER COVERS: First, name specific SLIs drawn from the user journey. For a report export, the most relevant SLI is end-to-end latency measured from the moment the user clicks export until the file is ready for download, ideally captured at the client or as close to it as possible. Second, specify the aggregation: raw latency data should be turned into a percentile such as the 95th or 99th percentile over a rolling window, because averages hide tail latency that frustrates users. Third, add complementary SLIs like throughput in rows per second or megabytes per minute, and availability defined as the fraction of well-formed export requests that succeed. Fourth, state a concrete SLO target for each SLI, for example ninety-five percent of exports complete within ten seconds, and explain that the SLO is the goal while the SLI is the measurement. Fifth, acknowledge trade-offs: a sub-second SLI for a ten-million-row report is unrealistic, so the threshold should be grounded in data size tiers or user expectations.
COMMON WRONG ANSWERS: A weak answer lists only infrastructure metrics such as CPU utilization, database query execution time, or disk IOPS without mapping them to user-perceived speed. Another red flag is proposing a single average latency figure, which masks outliers and fails to capture the tail behavior that defines a fast experience for all users. Confusing SLI with SLO, or offering one hundred percent availability, also signals inexperience.
LIKELY FOLLOW-UPS: The interviewer may ask how you would measure client-side latency if you only have server-side logs. They might also ask what happens when the SLO is breached, how you would tier SLOs by report size, or how you would validate that the chosen threshold actually satisfies users.
ONE CONCRETE EXAMPLE: Suppose users export a monthly sales report. A strong candidate proposes an SLI of end-to-end latency measured at the application layer with a ninety-ninth percentile aggregation over a one-day window. The corresponding SLO is that ninety-nine percent of exports under one hundred thousand rows finish within five seconds. For larger reports, the candidate defines a separate throughput SLI of at least ten megabytes per second and an availability SLI requiring that ninety-nine point nine percent of requests return a valid file. This shows the candidate can apply the SRE framework to a real product surface.
Read the original → sre.google
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.