Explain the difference between correlation and causation with a software example.

WHAT THIS TESTS: This question tests your ability to reason about observational data without falling into the cum hoc ergo propter hoc fallacy. Interviewers want to see that you understand a metric relationship is not enough to justify an intervention. In production systems, acting on a spurious correlation can lead to wasted engineering time, bad autoscaling rules, or incorrect alerting thresholds. The goal is to see if you ask what hidden variable could explain both observations before committing to a causal story.

A GOOD ANSWER COVERS: First, a crisp definition of correlation as a statistical association or co-occurrence between two variables, and causation as a directional relationship where manipulating one variable changes the other. Second, an explicit mention of a confounding variable or common cause that links the two metrics. Third, a software example where two metrics move together because of an underlying third factor rather than a direct causal link. Fourth, a brief note on how you would validate causation, such as controlled experiments, randomized load tests, or instrumental variable analysis.

COMMON WRONG ANSWERS: Claiming that correlation never appears alongside causation, or that correlation is simply useless. Another red flag is offering a purely physical example like ice cream and drowning without connecting it back to software. A dangerous pattern is suggesting you would immediately scale CPU because it correlates with memory, without questioning whether traffic is the real driver. Also, confusing the direction of causation, for example asserting that high memory causes high CPU when the reverse could also be plausible.

LIKELY FOLLOW-UPS: The interviewer might ask how you would prove causation in a production system without running a full experiment. They could ask you to design an A/B test or canary deployment to isolate the effect of one variable. Another follow-up is distinguishing between correlation, causation, and mere coincidence in a noisy metrics pipeline with thousands of time series. You might also be asked how spurious correlations affect alerting and SLO definitions.

ONE CONCRETE EXAMPLE: Consider a microservice where CPU usage and memory usage both rise sharply at 9 AM every day. A naive reading suggests CPU spikes cause memory pressure, or vice versa. The actual cause is a scheduled batch job that sends a burst of requests; request volume is the confounding variable. If you vertically scale CPU based on the correlation alone, you waste money and still hit memory limits because the root cause is unaddressed. A better response is to throttle the batch, cache results, or scale horizontally based on request queue depth rather than the correlated symptoms.