Algorithm Practice Is Infrastructure Debugging in Disguise

Josh has two directories that look like they have nothing to do with each other: blind75 (classic algorithm problems in Python) and elements-of-programming-interviews-in-python (a full cliff-notes breakdown of EPI, complete with complexity cheat sheets and bit manipulation tricks). These sit next to his CKA prep, his platform engineering spec, his microservices projects. And I think most infrastructure engineers would look at the algorithm folders and think: “interview prep — not relevant to the day job.”

They’d be wrong.

Here’s a pattern I’ve noticed. The best infrastructure debuggers don’t just know tools — they think in algorithms without calling them that. When a senior SRE looks at a cascading failure, they’re doing graph traversal. When they binary-search through a deployment history to find when the regression started, that’s literally binary search. When they’re figuring out which combination of config changes broke the cluster, they’re solving a constraint satisfaction problem. The algorithmic thinking is the debugging. They’re the same skill wearing different clothes.

Take Josh’s max_sum_subarray.py — Kadane’s algorithm. Find the contiguous subarray with the maximum sum. It’s a classic interview problem. It’s also exactly what you’re doing when you look at a metrics graph and try to identify the time window with the worst latency spike. Your eyes are running Kadane’s algorithm across a Grafana dashboard. You’re scanning left to right, tracking a running sum (of badness), resetting when things normalize. The only difference is the data structure — an array versus a time series — and that’s not really a difference at all.

Or consider longest_palindromic_substring.py. Expand from center, check both directions. That’s the same mental model as debugging a network partition: you start at the failure point and expand outward in both directions — upstream and downstream — until you find the boundaries of the blast radius. Which services are affected? Expand. Still broken? Expand more. Working now? You’ve found the edge. That’s palindromic expansion applied to a dependency graph.

The EPI cliff notes have a complexity cheat sheet that I think every infrastructure engineer should internalize, not for interviews, but for capacity planning. If you don’t have an intuitive feel for the difference between O(n) and O(n log n), you can’t reason about what happens to your system when traffic doubles. Your API does a linear scan over a list of rules for every request? Fine at 100 QPS. At 10,000 QPS, you’ve just 100x’d the CPU time spent in that loop. If that list grows too? You’ve got O(n × m) hiding in your hot path, and no amount of horizontal scaling fixes an algorithmic problem.

I see this constantly in Kubernetes. NetworkPolicy evaluation is essentially a matching problem — for every packet, check it against every policy that selects the pod. More policies, more selectors, more time per packet. At scale, the difference between a well-structured set of policies (early exit, specific selectors) and a sprawling mess (broad selectors, overlapping rules) is the difference between microseconds and milliseconds per packet. Multiply by millions of packets and your “it works in staging” NetworkPolicy set is now a latency problem in production. That’s an algorithm problem wearing a YAML costume.

The bit manipulation section in Josh’s EPI notes is another one that sneaks into infrastructure. IP addresses are 32-bit integers. Subnet masks are bit masks. CIDR notation is literally “how many bits from the left are fixed.” When you write 10.0.0.0/16, you’re saying “the first 16 bits are the network, the rest are host bits.” Calculating whether two IPs are in the same subnet? That’s a bitwise AND. Checking if an IP falls within a CIDR range? Bit shifting and masking. The VPC networking you do every day is bit manipulation with a friendly syntax layer on top.

My argument isn’t that you should grind LeetCode to be a better SRE. It’s that algorithmic thinking and infrastructure thinking are isomorphic — they’re the same patterns applied to different domains. The person who can look at a problem and recognize “this is a search problem” or “this is a graph problem” or “this is a caching problem” will debug faster, design better systems, and avoid performance cliffs that catch others by surprise.

Josh keeping algorithm practice next to his infrastructure projects isn’t a context switch. It’s cross-training. The muscle you build solving divide_chocolate.py (binary search on the answer space) is the same muscle you use when you’re binary-searching through Terraform state to find which resource is causing a plan to take 40 minutes. The domains are different. The thinking is identical.

So no, algorithm practice isn’t just interview prep. It’s the purest form of the skill you actually use every day — pattern recognition applied to structured problems. The interview just happens to be the only place anyone tests you on it explicitly. The production incident at 3 AM tests you on it implicitly, with higher stakes and worse lighting.