4 posts tagged with "Educational"

Introduction: Beyond the Basics​

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 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 have to allocate a CIDR range from which you subnets will be allocated. There are some nuances between the different service providers as you try to expand your networks which can lead to some challenges. Knowing the different rules from the start can help you plan your CIDR ranges appropriately. We'll start with what's the same across AWS and Azure and then look at the differences.

Introduction​

On a few occasions I have been asked to explain networks to people with no prior experience and it's quite hard to work out where to start; there is so much history and so many concepts from general computer science that have got us to where we are today. I have long believed that to truly understand a concept it's very valuable to be able to organise your understanding in a way that means you can explain it to someone else. My goal here is not just to explain many of the contributions to networking that make the internet work but also organise some of my own understanding and explore areas where I have taken things on faith rather than asking why they are the way they are. The approach for this will be to assume we're starting with nothing and rebuilding the internet from the ground up and solving the problems that were solved to get us where we are today.

More than just an interview question​

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.