Friday, March 03, 2006

I'm not an Expert

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.

4 comments:

Anonymous said...

I feel you. I just wish you all the best and hope you become that expert some day..

Anonymous said...

It isn't about what you know and how good you are. It's who you know and who knows you. Submitting your resume to Cisco online isn't going to get you where you want to go. Do you have friends in Cisco? Have you tried finding people in Cisco via http://www.linkedin.com? Do you know people at other TACs (e.g., Juniper, Foundry, Extreme)? Most of them have jumped from one equipment provider to another.

Having never lived in the middle east, I don't know if that is the place to meet these people. But if you don't build rapport with someone inside the company to walk your resume to the hiring manager, you are going to go down many dead ends.

Just my two cents. Opinions are like noses, everyone has one. But I wouldn't be where I am today if I didn't use these valuable heuristics and tools.

Anonymous said...

Hi, Congrats,I understand you now work within Advanced Services in Cisco Systems.

I will have an interview for a position within Cisco Advanced Services doing Pre-sales/Design. I am not familiar with Cisco's recruiting process, would you mind giving some tips ahead as to how many interviews (technical,non-technical), how in-depth the technical questions would be ?, what do they expect from a good candidate for this position?

any help would be highly appreciated.

thank you

Robert

Himawan Nugroho said...

Hi, Cisco's recruitment process would be the same with any other company. Mind you that the Advanced Services deal with post-migration, project scoping, advanced technology deployment etc meaning most of the time the customers have purchased/ordered the hardware. So it's AS responsibility to deploy them based on best practices and to answer customer technical requirements. Non-technical or pre-sales design are part of System Engineer's job, NCE's job normally started from project scoping, requirement workshop and all the way to low level design, implementation and migration. Unless you applied to AS sales, which means you have to sale/pre-sale AS services. Technical interview for NCEs is expected to be deep down. In my case when I joined AS APAC I was interviewed by 6 NCEs, one-on-one and against 4 NCEs at one time. When I moved to new team I was interviewed by 5 senior NCEs. The number may vary depending on your case and timing, and I would say the non-technical interview should not give big issues. Hope this help