In-depth explanations and comprehensive guides on fundamental technical concepts
View All Tags
The Arctic wind whipped across my face as I looked up at the entrance of what might be humanity's most important insurance policy. It has been a place that has fascinated me since I read a New Scientist article about it many years ago, and there I was, staring at the concrete wedge jutting from the mountainside, its façade glittering with an art installation that catches the summer Arctic sunlight.
I've already written a bit about various firewalls and their performance with FQDN filtering. I've also made the case for a 'less is more' approach to egress security where it makes sense. But the topic of FQDN filtering keeps coming up, so I thought I'd share a few more thoughts on it.
FizzBuzz has long been a staple of programming interviews. The problem is deceptively simple: print numbers from 1 to n, but replace multiples of 3 with "Fizz", multiples of 5 with "Buzz", and multiples of both with "FizzBuzz". It's not meant to be a challenging algorithmic puzzle; most candidates with basic programming knowledge should solve it without difficulty.
So why does this trivial problem persist in the interview landscape? Because I believe FizzBuzz's true value isn't in filtering out candidates who can't code—it's in opening discussions about complexity, language characteristics, optimisation, and the subtle costs of different operations. The best interviewers don't just ask candidates to solve FizzBuzz; they use it as a starting point for a deeper technical conversation.
When you create a VNet in Azure or a VPC in AWS, you need to allocate a CIDR range for your subnets. There are key differences between these cloud providers when expanding networks, which can create challenges. Knowing these rules from the start helps you plan your CIDR ranges better. I'll start with what's similar across AWS and Azure, then look at the differences.
I've been asked to explain networks to people with no experience several times and it's hard to know where to start. There's so much history and so many computer science concepts that have led us to where we are today. I've always believed that to truly understand something, you need to be able to explain it to someone else. My goal here isn't just to explain the bits that make the internet work, but also to organise my own understanding and explore areas where I've taken things on faith instead of questioning why they exist. I'll start from nothing and rebuild the internet from scratch, solving the same problems that got us where we are today.
Over my years in networking I've sat on both sides of countless technical interviews. There's a familiar dance that occurs when discussing OSPF: the candidate confidently states "OSPF uses Dijkstra's algorithm for route calculation," and the interviewer will nod approvingly. Yet recently, I had a moment of clarity: in hundreds of these exchanges, I've never once asked a candidate to explain what that actually means, nor have I been asked to explain it myself. This perfunctory mention of Dijkstra has become almost ceremonial in our industry, a shibboleth that we repeat without truly engaging with its significance. Yet understanding this algorithm isn't just academic—it fundamentally shapes how OSPF operates, influences our network designs, and explains why certain design patterns have become best practices. When a link fails in your network and OSPF begins recalculating routes, there's significant computational overhead that many engineers never consider. This processing cost isn't just theoretical—it's the hidden force behind many of our design decisions, from area sizing to adjacency limits. Today, we'll bridge the gap between theory and practice, exploring how this fundamental algorithm shapes the way we deploy and scale OSPF networks, and why it matters for your day-to-day operations.