Couple of days ago I had a job interview over the phone. Guess what, it was from one networking company in San Jose, US. From one of my dream workplace in the world. No, it’s not from Cisco Systems. Even I’m willing to sell my soul to join them and I have sent my resume for the 4th time, they are still not bothered to contact me.
So, the call was from Cisco’s younger brother :) . Okay, I’m not sure how was my performance during the interview, but that 45-minutes phone call really taught me one important lesson: I’m still very far from an expert level.
I have 2 CCIE. And ‘E’ stands for Expert. So I’m 2 times expert. Yeah, rite. Having CCIE, even multiple CCIE, doesn’t mean we are an expert. It only means: we have passed the goddamn hard 8-hours exam. It means we are self-motivated, hard worker, well-driven, eager to learn and bla bla bla, but not necessary an expert.
As always, everything happens for a reason. Regardless whether we do well or bad, the most important thing is to learn from our past. So I tried to evaluate why someone who has years of experience and multiple CCIE like me, still can get confused with some basic question. And following are my findings:
- I keep jumping from one topic to another topic
My job nature forces me to always work on different technology from time to time. Last week I might dealing with Wireless, yesterday was IPSec, today is for QOS, and tomorrow will be for VPLS. Doing all this stuff within short timeframe is good to become a consultant, but it won’t give enough time to dig into the detail on each technology. So broader knowledge, but lesser detail.
- I’m a system integrator, a solution implementer
I have to deploy solution that fits with customer requirements. Sometime it requires me to integrate multiple systems from different vendor. But the main idea is: to have a working solution. If we have to bundle multiple products into a single infrastructure, our main concern will not on the bit and bytes of the traffic. It will be on higher level. Knowing the OSPF LSA header will not help, but knowing the best practice to deploy OSPF with multiple areas obviously is required.
- No project has ever challenged me enough
Well, this is back to my 2 Law. If there is not any projects that complex enough and require lots of testing, than it’s difficult to force us down into very detail. If the mindset is only to make it works, than we won’t bother to search for more information. Delivering project means there is a timeframe, there is a target date to achieve. I can’t tell the customer that the project has not finished yet because I'm still curious and investigating the layer 2 header mapping in VPLS. Project management is so complicated and sometime there is political issue involved, so it provides no slot left to have fun in the devices.
Personally I believe there are several levels of engineer: one who can deploy, one who can troubleshoot, one who can design a solution and one who designs the system. The first one is the most common. To configure a device, even multiple devices, sometime is no-brainer. Just read the manual and try to find sample configuration from vendor’s website, and it’s done. To be able to troubleshoot, one needs to know in more detail. We can’t troubleshoot if we don’t know how it works. CCIE can make us reach this level. It can make anyone who passes to design solution as well. But it won’t teach how to design a system or device.
By designing the system I mean these are the guys behind the device architecture. Who define why and how the device will be developed. They are not necessary the developer. But obviously they are the ones who decide which features need to be added or removed. They are the ones who think about what need to be done in the next product release. They are the ones who test the new products, simulate real-life scenarios and verify the result, and provide critical feedback to developers. Read the RFC and follow the standard to guarantee inter-operability with other vendors, and sometime involve in making the Internet draft to become a new RFC.
They define the future of the product.
Most of the time, the future of the technology.
This post is for all system designers and testing engineers out there.
I respect all of you guys. And becoming one like you, most probably is my ultimate goal.
