Hi Rik, It is all going to depend on the job. How anal is your boss going to be...how anal is the policy of the company going to be...how much information do you and your team want to have at the drop of a hat to run reports or if things go wrong? With that being said, most high level enterprise network jobs do involve a lot of politics, and a lot of documentation of things that are not necessarily the most technical in nature.
Most places I have worked have of course some sort of spreadsheet or documentation on the LAN and the WAN. This would include things like IP addresses, interfaces, host names, IOS versions, hardware platform...in some cases if they are really anal even an accounting of what is connected to each switch port (yes, I was the low man on the todem pole at one time doing inventory of EVERY switch port on dual 6509 cores...including MAC addresses for each port) All this is great information until it needs to be updated and you find that it has not been updated in three years...and you are the new guy on the team : ) When things go wrong, it usually is going to be in the form of a trouble ticketing system or a phone call. If you don't get a trouble ticket or a phone call, do as you think necessary. Usually the hasstle of writing up resolutions to cases and such is because you are under and SLA to close the trouble ticket in a certain amount of time. Any kind of new design or modification to an existing design is typically going to require lots of documentation. The other things is the dreaded change window. Depending again on the company and their change control policy this can quickly become the worst part of your job. Some places require sickeningly detailed change control information every time you wish to make a change to the network. This would include things like when and what you plan to do, specific commands you wish to implement, what your backup plan is if things should fail, the severity of the change, if the change was successful or not successful, etc. Basically it's a pain : ) I've had jobs where it took me longer to write the damn change control than it did for me to implement the change. The bottom line with that is this: It's their network and it's their money. If they want to pay you to sit around and write documentation and change control fine, but they need to understand that things will not get done as fast either. You can't do both. At a previous job, we screwed the pooch on a minor change, and management came down hard requiring an approved change control for every possible change to the network. Great, a user calls you up because his port is slow. You investigate and find it is set to 10/half. Change control. Servers are being added to a datacenter switch and you need to provision the ports in the right VLAN. Change control...they quickly got rid of that policy : ) I hope that helps. On Tue, Oct 13, 2009 at 7:37 AM, Rik Ryder <[email protected]> wrote: > Hi guys, > > Thanks for your replies, your advice is invaluable. > > I'll certainly try and turn things around and be proactive in the > interviews from now. Prior to the ones I have had recently, I haven't been > interviewed in a while, so I'm a bit rusty! > > Even though i'm being upfront about my lack of real world experience, the > problem I have is that because I've never worked in the actual role, I get > those peering looks over the glasses & an uncomfortable silence. > > So I want to dazzle them with my awareness of what is expected of me. > > If somebody would be kind enough to help me with these questions: > > I was wondering how much documentation is usually undertaken by a network > engineer. For example, If you follow any anomalies, set alarms or triggers > does this usually all have to be be documented? > > Also, how often do you communicate with Cisco? for example, if you are > replacing end of life equipment or project their solutions is there much > involvement from Cisco? > > Thanks again, > > Rik > > > > > > 2009/10/12 <[email protected]> > > When I have interviews, I usually get the tell me about yourself question. >> Normally after that ill do what joe says and own the situation. I normally >> ask the questions like what you presented first and reverse it so it shows >> my excitement. Not only that but showing off ethic integrity will go a long >> way so don't forget while its a technical/management interview you have to >> show clear and fair judgment. Back that up with examples of situations where >> you had to make a tough call. Remember tech geeks like us still have to talk >> to the business and act as liaison to the IT side of things, something I >> have had to do heavily......when I was employed .....but hopefully I get >> lucky soon and so will you. >> >> -nick >> >> >> Sent from my Verizon Wireless BlackBerry >> >> -----Original Message----- >> From: Joe Astorino <[email protected]> >> Date: Mon, 12 Oct 2009 10:20:05 >> To: Rik Ryder<[email protected]> >> Cc: <[email protected]> >> Subject: Re: [OSL | CCIE_RS] Day in the life of a Cisco Network Engineer >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> > -- Regards, Joe Astorino - CCIE #24347 R&S Technical Instructor - IPexpert, Inc. Cell: +1.586.212.6107 Fax: +1.810.454.0130 Mailto: [email protected]
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
