Episode 125
# Episode 125
Welcome to episode 125 of the Nerd Journey Podcast @NerdJourney! We’re John White ( @vJourneyman) and Nick Korte ( @NetworkNerd_), two Pre-Sales Technical Engineers who are hoping to bring you the IT career advice that we wish we’d been given earlier in our careers. In today’s episode we share part 1 of our interview with Tom Hollingsworth in which he shares how his Networking specialty came to be, the journey to a major certification and beyond, and some advice for those looking to get into Networking.
Original Recording Date: 06-01-2021
Topics – Birth of a Specialty, CCIE and Beyond, Advice for Those New to Networking
===========================
# 2:06 - Meet Tom Hollingsworth
Tom Hollingsworth has been the Tech Field Day event lead for about 8 years as part of his role at Gestalt IT after serving as a Network Engineer for many years. Tom Hollingsworth Tech Field Day Gestalt IT #CCIE
Tom’s handle in communities is Networking Nerd due to his deep expertise in Networking. Nick points out that he chose NetworkNerd because it sounded fun.
Tom gets contacted from time to time because people think he is a master of social networking.
# 3:34 - Birth of a Specialty
Tom spent about 6 months on the phone supporting Gateway computers but knew the role would not last.
He did some contract work and then found a position that was junior level help desk and did a lot of work with schools.
This allowed Tom to gain a variety experience with different technologies and grow his career at the same time.
The company was only about 40 people, and the team on which Tom worked had only about 8 people, each with their own specialty. Tom’s specialty was in networking.
The networking specialty came from the last month on the phones at Gateway (around the 2002 - 2003 time frame when dial up was still popular).
Listen to Tom describe how he would have to fix AOL for someone.
In the last month of his time at Gateway he started getting calls about cable modems, which was pretty new to him. He was able to search online for some ideas but would otherwise have to direct the caller to contact their internet service provider.
At the time, Tom suspected there had to be something to networking at which he needed to take a hard look.
When ramping for this new role, most of what they did was server based. Tom had to learn some other technologies but noticed there was really a need to fill a networking void.
A mentor at work walked Tom through Cisco router troubleshooting but said Tom would have to learn it and to go buy a book.
This was a time when the best way to learn was from technology books.
Tom knew he had learned quite a bit when Barnes and Noble didn’t have the books he needed any longer.
He had to buy Routing TCP/IP, Volume 1 by Jeff Doyle and several others.
In the late 2000s, online forums picked up speed and aligned with Tom’s expertise gains. He was able to jump into a forum and get help on specific problems instead of just reading a book.
Tom remembers watching War Games and seeing what the main character could do on a computer. Then at one point Tom could do that too.
What you may excel at may not be something your company is really looking for.
At first, Tom needed to know a little bit about everything in his job.
As he progressed, the networks the company deployed became more complicated (or more feature rich).
Tom was eventually asked to work on phone systems as well.
Some of the work Tom did was out of necessity for the company, but there was a whole other side of networking he kept up with at the same time.
# 11:31 - Achieving CCIE and Beyond
The company had to balance the work coming in with what it would cost to pay for Tom to get certified.
After Tom got certified his company was able to bid for a project that required they have a CCIE on staff and eventually became proud that they had someone on staff with those credentials.
There are generally fewer paper tigers who hold the CCIE due to its practical lab component.
Tom passed the CCIE in 2011 and is currently on the CCIE Advisory Board.
The test is two parts - a written portion and a practical lab portion. It used to be you could take the written portion every 2 years to keep your certification status.
Listen to Tom share some details of the recertification policy.
Tom buy a lot of used hardware on eBay to help study for the certification and create his own lab to simulate the exam.
Listen to some of the limitations of what he could do with the gear he had compared to what is available now with some of Cisco’s emulation software (which runs a large portion of the lab now).
It’s nice to train on the exact same thing you will be seeing when you take the exam.
At one time there was a rack of gear in the room where CCIEs went to take the exam.
Listen to what some exam candidates did to try and get exam proctors to give away information.
Several years ago Tom was asked by the program manager within Cisco to take part in the advisory board mostly because he wrote a blog post on the exam based on some community feedback he had heard that prompted an in person meeting to discuss it.
The program manager at Cisco wanted Tom to work with them to make the exam better.
Tom and a number of others in the community debate changes to the exam and value to the greater community.
Many of the changes to the exam in the last 2 years have been very well debated by the advisory board as it relates to community value.
Tom gives examples of things that were not as valuable like a CCIE for OpenFlow.
The CCIE doesn’t move without a good reason because it does not follow trends. It sets trends.
Getting a CCIE is like getting a PhD. You’re adding to the body of knowledge in a field. You don’t just say you want to do it to be the best.
In any certification program, you have to want to understand things at a deeper level.
Most of the jobs of the average operations team does will not go beyond the CCNA+.
Tom gives an anecdote about knowing BGP and its applicability to his job role.
If your job is 95% basic tasks, this is not something you can work on through job training.
If you are not willing to put in the time to study each day and do the work, it may not be for you.
You almost have to be obsessed with it, the type of attachment that makes you want to work on it when you’re sitting there not doing anything else.
You have to know the technology at a deep level and understand every possible outcome so you can determine the best path forward when it comes time to take the exam.
Once you dive in you will realize how much time it takes to get to that level of understanding.
Nick compares this to Scott Lowe’s concept of the full stack engineer. Full Stack Engineer
Listen to Tom talk about a boot camp he attended which provided some pretty outlandish tasks and the reasons behind making attendees do them.
High level technology certifications like CCIE, VCDX, or other are really testing you on what happens when someone throws a curve ball at you.
Tom gives some great examples of how this might happen on the CCIE exam, how one might think through them, and how this simulates what working in a real environment is like.
Anyone can type in a command they found in a book or online. But when that command wrecks something and you have to come back from it, that is the learning experience.
Nick recounts plugging both ends of the same cable into a switch and taking part of the network down, and Tom shares an experience in troubleshooting a similar situation that he never forgot.
When possible, Tom liked to let a junior level person noodle through a problem on their own before offering any help for the benefit of the learning experience.
You have to think beyond what the book says, beyond what the internet says the problem is. Think about all the scenarios and eliminate them one at a time, even if they seem crazy at first.
# 28:58 - Advice for Those New to Networking
Learning a scripting language if you’re going to be in the Networking field is important.
Listen to Tom’s analogy of mechanics needing to know how combustion engines work and the tools they need today.
Learning a language like Python is helpful, but if you’re automating VLANs, you still have to know what a VLAN is (the basics).
Take the fundamentals and start to orchestrate based on the basics you understand (i.e. automatically bounce a switch port that errors). You will still need to be able to do root cause analysis for something that was automated.
Tom has a nice analogy here about a backhoe and a shovel.