6 posts tagged with "Programming"

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 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.

A little while ago I set out to find a way to measure the overhead that FQDN filtering places on HTTPS web traffic. I've shared the results here, but I thought I'd take the opportunity to discuss the methodology in a bit more detail.

Introduction​

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.

I've put together a summary of some common search algorithms and how they work. This post covers key search algorithms used in computer science, explaining their approaches, strengths, weaknesses, and showing Python implementation examples.

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.

There used to be a great little website for route summarisation and it did it far more intelligently than Cisco kit does it. It looks like the site has dropped off the internet which is a shame but there is a handy python library called netaddr with has the same capabilities.

I have written a little wrapper for it which will regex the prefixes out of a ‘show ip bgp’ and then list the summary routes. You pass the output of ‘show ip bgp’ as a text file, it’s the only argument the script expects.