One thing that I find very important in interviews is not to let yourself be STUMPED by any technical question. If a question stops you cold, you are dead meat. What you can do when you don't know the specific answer to a question is talk about what you have done...let the lead-in question allow you to talk about other topics that are related. Perhaps you didn't resolve an issue using the specific technology the interviewer is asking about, but don't let that stop you from telling about a similar problem where you came up with the resolution using a different scheme. Show initiative - always have some concrete experience to bring up in the interview. I am always a bit slow to get started in an interview - I'm shy that way - but once the technical questions/experience questions start coming in, I try to let one experience lead to another to show the wide breadth of things I've done.
My last interview was absolutely killer...worst experience I've ever had. The interviewer likes to find areas of weakness and then hammer away even if the technology has little to do with the position or responsibilities you'll be doing. At the end, I asked him point blank how I did and he played down my performance - maybe he'd call me in a couple weeks...Two days later I got a call asking me to come in for the final HR interview and I find out later they'd been looking unsuccessfully for almost a year. I never really thought of an interview as a psychological game before - I used to interview people at my last job and was always pretty straightforward about what I was looking for with the candidates, but not everyone is so it's important to be confident about what you bring to the role you are interviewing for. And...sometimes you have to start lower than you feel your qualifications warrant and work your way up. I was a senior network admin at a small startup financial compay at my last job...now I'm working for a much larger financial company making more, but I had a lower title of Network Engineer and had to prove that I could do what they wanted on the scale they wanted but I was moved back up to Senior Network Engineer in less than a year. All thing to consider. Good luck, Michael On Tue, Oct 13, 2009 at 10:03 AM, Joe Astorino <[email protected]>wrote: > 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 > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
