Another thing Rik -- I feel your pain. I was once a 20 year old kid getting into network engineering with a fresh CCNA in my pocket and NO EXPERIENCE I landed a job as a network analyst for Ford Motor Company Credit and got some valuable valuable experience. Everything builds on itself. At each job you take on, you will gain valuable valuable experience with equipment and technology you can mention at the next job should you choose to leave.
Anyways, about that first job -- The way I got in was by having my CCNA, by being social with the hiring team, and by demonstrating that I knew all the technical aspects of the job. You do that my knowing your stuff plain and simple and answering any technical questions without a blink. Being social with people is another art and skill all on it's own. But generally, be a nice guy! SMILE, converse like a normal guy, try to be calm and laid back, you OWN THE JOB before you get it. You assume they called you because they want to bring you in. When it comes to experience -- Even at that first big job, I was asked well have you ever done this this or this? Well, not at WORK but that didn't mean I had not played with it on my own. What you want to do is think about all your experiences with technology and tell them something about it...relate what you HAVE done to the question. So maybe they ask you if you have any experience with firewalls. Well, maybe not at work...but maybe you worked on implementing a LINUX based firewall while in college using IPchains or something (example from my background again). Mention that...mention things you have done just for fun, but don't mention they were for fun : ) Just say yeah I have worked on this this and this, and this is what I did with it. It's all about experience and relating to things. HTH On Tue, Oct 13, 2009 at 9:57 AM, Joe Astorino <[email protected]>wrote: > 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] > -- 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
