Tuesday, August 23, 2011

8 Tips to become a relevant network engineer

Over the last few years I've had the opportunity to work with many great engineers and I've also had the displeasure of working with many not so great engineers. I worked a contract at the Sprint World Headquarters in Kansas City where I was in a room with 8 to 10 extremely skilled network engineers who may or may not have been CCIEs and/or JNCIEs. These were the kind of engineers that literally spoke routing protocols as a first language, throwing around the more advanced concepts without thinking about it, much like a book worm uses big words all the time, wondering why everyone else "doesn't get it." These were the engineers who never spoke of their certifications because their extreme skill spoke for itself. Network technologies radiated from their pores and you never once questioned their judgement, their knowledge, or their certifications (if they even had any). At the same time I've had the displeasure of working with newly minted CCNAs who failed to grasp the concept behind drawing physical layer diagrams of not-so-complex networks using CDP. These were the kinds of engineers - and I use the term engineers loosely - who were quite frankly lazy. These are the kind of people who got into IT because of the promise of a big paycheck, nice cars, big fancy homes, huge salaries, never ending vacation time, and so on. These were the people who rambled on and one about how they're a CCNA and they've made the big time. They managed to get hired into a room full of contractors at Sprint and they think they are hot stuff.

It is time to set the record straight people. The economy sucks. Finding a way to pass the CCNA exam is NOT going to land you that dream job you have been searching for. You are going to get run through a technical interview, and I can tell you for fact 95% of you will fail. I have been going through resume after resume after resume for the past 3 weeks trying to find competent engineers. Many resumes looked amazing and I had high hopes of finally striking some golden talent, only to be disappointed time after time. People are CCNAs, CCNA Security, CCNPs, and on and on and on. Tell me, what study methods are people with these types of certifications using that they can't tell me on a phone interview how to create a freaking VLAN. I am extremely annoyed at the lack of talent I am finding in the majority of people I am interviewing.

And this annoyance is what you can thank for this article. My top 10 tips to becoming a relevant network engineer, with or without certification.

1. Drop the brain dumps. I know, you are in a big hurry to get certified because as soon as you get that paper you won't be able to keep track of all the interviews you will be getting. WRONG. I've get 10 telephone interview questions that will weed you out of the candidate pool faster than can hit your #1 speed dial.

2. Build your own lab. I know, it is expensive and you can't afford it. WRONG. You can't afford NOT to build a lab. When you are in my lab doing the break/fix portion of my interview process I will know almost instantly if you've logged in to live equipment. Something as simple as knowing how to work a PuTTy session when you have a console connection to racked equipment will give you away. Another dead giveaway is how clumsy you are at the CLI. Build a lab already. You aren't doing yourself any favors memorizing commands from a book.

3. Put it to use. What do I mean? I mean, when you read about a technology in your exam certification guides, or whatever it is you read to study, put it to use. Find a way to use it. Reading about spanning-tree doesn't help you "get it." It may give you ideas, but nothing solidifies concepts better than putting them to use. If you read about spanning tree, create bridging loop. How can you identify a bridging loop under pressure in production if you've never seen one? How can you have confidence in your spanning tree configurations if you've never seen all the variations of how it can be configured?

4. Get creative. When you are going through your lab exercises change stuff around, mix things up, give yourself different topologies to work with. If you do the same lab over and over and over again, you are certain to miss out on learning opportunities presented by different scenarios. No two networks are ever the same. There are common design principles and expected ways of deploying services, but I promise you, no two networks are the same. Mix it up and it will pay off big.

5. High availability. When I have my rack fired up and I am working with new technology I don't spend too much time on the "simple configurations." Don't get me wrong, I make sure I have the basics down, but if you want to REALLY learn something, you need redundancy. Building high availability lab topologies will bring a whole new set of issues to your door, and with that, you will build a whole new set of skills. I used to frequent a certification exam forum that was pretty good about keeping brain dumpers out, but every once in a while some troll would come knocking asking all the wrong questions. For example, "Why use two links?" My answer, "Why NOT use two links?" "Why NOT have redundant paths?" "I want my network to be available to the business."

6. That lead nicely into number 6. Ask the RIGHT questions. Be a contrarian at times and defend your designs. As you become more skilled you will realize more and more just how unskilled so many people actually are and with that you will come across people who are unsuccessful because they ask the wrong questions. They do this because they are lazy and they just don't get it. They don't know why they have jobs and as a result never ask the right questions, and frankly can't do the job.

7. Teach someone else how to do it and/or find a lab partner. I have to tell you, some of my strongest learning experiences have come from teaching someone else what I know (or thought I knew) and bouncing ideas off someone else. The reason this is so great is because the person you are teaching will inevitably ask questions that you are not prepared to answer in a way that will make you question yourself, and what you know. Getting an answer to the question will cause you to learn, and because you are engaged in an exchange with another human being providing constant feedback and questions, it will be that much more difficult to forget what you have learned. A great sounding board is an invaluable learning tool.

8. Figure out how it works. Always find out how it works, whether it is a PING from host A to host B on the same switch, or a routing update produced by a topology change in EIGRP, always find out how it works. When you are on a production network with things going wrong, you can't even begin to provide effective troubleshooting if you don't know how stuff works. Break things in your lab to test your thesis. Put workstation with wireshark in between two routers and watch the traffic flow. Telnet to port 80 on web server and watch what happens. Overflow the CAM table on your Catalyst and observe unicast flooding in action.

To sum it all up - don't be lazy in your studies. Doing your due diligence up front will pay huge dividends. I'm not a highly certified individual, but I outperform many highly certified individuals. I once had an extremely technical phone interview with a large company here in town who told me I gave them the best presentation of routing protocol knowledge they had ever seen. The certification is not the reward folks. It is the journey that pays the dividends. The certification is just a piece of paper. Don't believe me? Ask the 14 "network engineers" who couldn't answer "How do you create a VLAN on a Cisco Catalyst 2960?"