I have been preparing for the CCIE lab exam (Route/Switch track) for 18 months. Many hundreds of hours reading, re-reading, labbing, and practicing. Lots of lost sleep. Lots of stress at work and at home. Just over a week ago, I went to Cisco’s Research Triangle Park facility and took the exam. I failed. Some might sugar-coat it, but not me. I failed to pass the exam; it’s that simple. My social networks erupted with sympathetic comments upon my announcing the news. I really appreciated the outpouring of support, but here’s the thing: I’m OK with it. I went in with realistic expectations and a plan. Not just a plan for how to approach the exam itself, but how to handle the “after.”
Getting Ready
First things first: You have to be realistic about taking the CCIE lab exam. I’ve heard statistics bandied about such as only 5 or 10% of candidates pass the lab on their first try. At lunch, our proctor said that historically there is only a 20% pass rate on any given attempt (again, for R&S). I’d done much preparation with a variety of materials, 10 years of industry experience, and the aforementioned hundreds (thousands?) of hours of lab time. But still, I had to accept that my chances were slim. Most people that walk into the lab for their first time feeling like they’re going to crush the exam will instead have their confidence crushed. I’m not a defeatist (no one that seriously pursues the CCIE can be), but I am a realist. So I set myself some goals for the day that did not include passing. My goals for my lab attempt were as follows:
- Be familiar with all topics on the blueprint to avoid being completely blind-sided by a topic and trying to read up on it during the lab.
- Finish the troubleshooting portion in a position that I could feel like I might have passed it. Knowing I’d failed TS would have made it difficult to really push myself in the config section. But keeping that hope alive was a great motivator.
- Use good time management to get through each section with time for a quick verification pass.
- Track my point count and (to the degree possible) compare with my results to see if I was scoring the points I thought I was.
Notice that “pass the exam” wasn’t in that list. It was more of a bonus. And had I executed all of the points above perfectly I would have had a very good shot.
Doing the Deed
Of course, I won’t be discussing any detail of the content of the exam in this article, but I will say I was pleasantly surprised to find that the exam was very challenging but also pretty reasonable. My TS (as we CCIE candidates call the troubleshooting section) had some very challenging tickets, but they all seemed “fair.” The config section had some curves as one would expect and a huge amount of time pressure, but my fears of tons of dirty tricks and wacky configs needed to work around things seemed mostly unfounded. I liked discovering this as it means the current incarnation of the CCIE lab (at least, the lab I got) was less about parlor tricks and more about just being able to crank out a wide variety of features, configs, and tuning accurately, and in a short period of time. That’s the right direction for the exam in my opinion.
I finished TS in a rush and without sufficient time to verify, but I did feel that if I’d earned the points I thought I had, I’d have passed that section. The configuration portion was an intense race against the clock. I did not finish all of my required tasks, and I had to abandon several high-value tasks because I couldn’t manage to meet some specific constraint or requirement.
The day felt more out-of-control than I wanted, but overall, I enjoyed the experience. I didn’t think I’d passed config, but the next step in my plan would have been the same whether I’d felt confident or I’d crashed-and-burned. My post-exam plan was in motion within minutes of leaving the facility.
In the Car
After walking out of the lab, I got back to my car and immediately started sketching out the lab diagram, specific requirement keywords that stumped me, and as much info as I could about the tasks that I hadn’t completed. I’d left a notebook and colored pencils in the car to be able to do this as soon as I walked out of the exam.
The purpose of this is not for sharing or publishing the information, of course. Those notes are for me, and me alone. But they allowed me to record the specific situations and the general topics where I struggled. I made notes such as “BGP/IGP topology conflict” to give myself some context to go with the drawings.
One thing I missed here was making notes of approximately the number of points in each section and my estimate of how many points I got. This would have been helpful in assessing my accuracy with my self-assessed scoring.
The Results
When I finally got my score report, it confirmed that I’d passed TS, but failed config. My overall scores in the config section seemed somewhat lower than what I had calculated for myself. Due to the oversight mentioned above, I wasn’t able to get a really good read on exactly how my per-topic scores looked compared to what I was expecting, though. Some sections were easy to back into from a point perspective but larger topics were not.
Was this disappointing? Of course. But it wasn’t unexpected. I had come to terms with the difficulty of the exam and my chances of passing on the first try months ago. Sure, a bit of a downer to learn that this journey isn’t over quite yet, but at least I didn’t have to go on a 2-day bender with a crushed spirit to come to grips with it like some candidates I have known.
In the end, I nailed #1 and #2 in my list of goals. I missed #3 for sure, and #4 wasn’t perfect but I was in the right neighborhood. I’m happy with my attempt and my result. My resolve to pass the exam is steeled.
Now What?
So, I’ve failed my first attempt, but I’ve learned. I learned that I need to be faster. Much faster. And more sure. I spent too much time looking up a few commands to verify a keyword or value. I need to be ruthless in my time management. I got myself into the time-pressure mess because I kept working on a ticket or task after I should have marked it for follow-up. Worse yet, in config I did this on two tasks in particular that were not part of establishing basic connectivity. I learned that my weak areas had mostly to do with feature interaction like topology mismatches between IGP and BGP, for instance. These are areas I can focus on in my next round of labbing. Although I will be trying to replicate and figure out the exact situation that I hit on my exam, I’m also generalizing these as broad categories for focus. The areas where I was weak were not due to the exact question asked but because I didn’t have a good approach for that entire topic. I accept that, and I will fix it.
I learned that while I made a good attempt, I have some further development to do, and it will be several months before my next try.
After a couple short weeks off including a much needed vacation with my family, I will be working out a detailed remediation plan and a timeline to go with it. I knew from the start I’d be doing this. It’s all part of the plan.
I am also confirming something I’ve previously hypothesized: those that take the CCIE exam multiple times almost certainly turn out stronger for the experience. If I’d gotten lucky and scored a pass, I might not be going back and digging into the level of detail I’m about to in my studies. Instead, I’m taking those weak areas, and I will turn them into my strengths. If I fail again, I’ll do the same. Eventually, I won’t have enough weaknesses to fail.
About Bob McCouch
