Cisco Network Engineer - Technical Interview Questions

RouteThisWay

Oh I agree completely with you Forsaken. If it is on your resume, it is absolutely fair game. Thats why when I see all of these network engineering questions you pose on these forums- I think twice before listing anything network related on mine!

I was just responding to Rogue's post. You are going to find yourself in a situation that you don't know the answer to. It doesn't mean you are a fraud- it just means you don't know the answer yet. As you mentioned in a previous post- a knowledge gap can be corrected. In fact, it does it by itself with intelligent people over time. But you can't fix stupid.

And if someone truly is a "fraud" and was hired as a network admin/engineer and doesn't even know how to run basic commands and troubleshooting- that is the fault of the hiring manager and not the employee. His task was to hire a qualified candidate for his team.

DPG

How may of you are actually hiring managers?

networker050184

I'm not a hiring manager, but I do the 'technical questioning' portion of interviews and have significant input. I do not make the final decision though.

Roguetadhg

RouteThisWay, I wasn't trying to say anyone should know all the answers. There's too much to know, too much to experience, and sometimes people get dragged into complex answers for a question when the answer is quite simple. Maybe it's a shutdown port?

Mostly I was envisioning just that you mentioned in your third paragragh - someone who doesn't know how to do basic commands, and can't start to troubleshoot the theory end. For example myself: I have no idea about Forsaken's QoS scenario. I gave it a shot that I knew of at that time. I didn't research anything for that 'answer'. I was most likely so wrong that anyone else with the knowledge to troubleshoot it probably got a good laugh. :P

There are plenty of questions that we don't know, there's Google and other places. Not to mention higher ups.

Also, There are going to be times we don't know what to do. That's a given. How you handle those situations will show their worth.

For example freezing on the phone trying to troubleshoot a problem is one way to deal with it.
You can also push it off onto someone else's problem without evidence to prove it isn't your problem. You could hang up the phones. Googling, Book, Cisco, Whitepapers,... Just because you can run around the server room naked saying "I'm the king of the Routers!" doesn't mean you should - ever.

MAC_Addy

This is a great thread! I'm not a hiring manager, but have been in some technical interviews. We were looking for a CCNA level candidate and someone with "CCNP" on their resume applied. I had asked them about their CCNP and why CCNA wasn't listed. He then stated that "I didn't want to mess around with taking the CCNA and went straight for the NP" needless to say that interview went south. I had asked some basic, basic questions and he couldn't even conjure up a decent sentence - he tried to bullsheet his way out of it. Now, my HR manager was impressed because he used words like TCP/IP and OSPF (which, he got all the OSPF information wrong btw), I'm glad I sat in that interview, because if my HR manager hired this guy I'd probably quit.

networker050184

Why would the HR manager be the one who decides who to hire?

MAC_Addy

They wouldn't be. But afterwards they said, he seemed pretty good, what do you think? Obviously I said this guy is a no go.

Forsaken_GA

networker050184 wrote: »

I'm not a hiring manager, but I do the 'technical questioning' portion of interviews and have significant input. I do not make the final decision though.

Likewise. Our bosses make the final hiring decisions, and they handle the head games with a candidate (ie, are they a good fit, ambitions, etc). They just call me or one of the other guys in to make sure they've got the technical chops. We provide a recommendation and then go back to work.

Forsaken_GA

MAC_Addy wrote: »

This is a great thread! I'm not a hiring manager, but have been in some technical interviews. We were looking for a CCNA level candidate and someone with "CCNP" on their resume applied. I had asked them about their CCNP and why CCNA wasn't listed. He then stated that "I didn't want to mess around with taking the CCNA and went straight for the NP" needless to say that interview went south. I had asked some basic, basic questions and he couldn't even conjure up a decent sentence - he tried to bullsheet his way out of it. Now, my HR manager was impressed because he used words like TCP/IP and OSPF (which, he got all the OSPF information wrong btw), I'm glad I sat in that interview, because if my HR manager hired this guy I'd probably quit.

I sincerely hope you pointed out to the HR dweeb that you can't be a CCNP without a CCNA, hehe. I've had a couple folks try that on me as well, and I call off the rest of the interview immediately. If someone displays an integrity problem like that right out of the gate, I don't want to work with them.

YFZblu

The one question that always bothered me was this: "How would you troubleshoot a T1?"

Obviously this is more of a 'how you think' question, but I was super annoyed at the lack of context, even after I asked for some. The interviewer just continued to ask "how would you troubleshoot a T1?" after I asked for a little bit more detail.

MAC_Addy

Forsaken_GA wrote: »

I sincerely hope you pointed out to the HR dweeb that you can't be a CCNP without a CCNA, hehe. I've had a couple folks try that on me as well, and I call off the rest of the interview immediately. If someone displays an integrity problem like that right out of the gate, I don't want to work with them.

I most definitely did notify HR. They completely convinced the HR person just because they added technical words. What's bad is that they're extremely gullible and have hired people in the past that clearly don't have experience and have just lied in their interview. It'll come back at them.

Brain_Power

Roguetadhg wrote: »

Just because you can run around the server room naked saying "I'm the king of the Routers!" doesn't mean you should - ever.

LOL!!! This would be a great youtube video...

NetworkVeteran

DPG wrote: »

How may of you are actually hiring managers?

Usually, the technical interviewer and the hiring manager are different people.

I have always been in the technical interviewer role.

In a previous role for one of the largest networking companies I reached out to obtain an initial list of candidates, defined the screening to narrow it down, and setup interviews to identify a preferred candidate. Once I had identified that preferred candidate, the hiring manager made a final go / no-go decision, and then paid me. She always agreed with my selections.

In my current role I am one of several who provide leads and technical assessments of candidates. The hiring manager is responsible for the overall evaluation and makes the final decision. If I say "no-go" it's almost certainly a no-go, but if I say "go" it's not necessarily so. This is probably the most common technical interviewing setup in the industry.

shodown

Yall got me thinking I need to take my CCNP off my resume. I haven't done CCNP level work since 2009.

pert

NetworkVeteran wrote: »

The first sign you are not, is that you believe those questions are Cisco-specific.


Both facts and methodology are important. A math whiz knows his addition and multiplication tables. A good networking engineer has accumulated a large body of knowledge. Technical interviews generally involve both scenarios and the recall of important facts, as do many certfiication exams. This is an acknowledgement of the merit of each.


The goal isn't to discover who can memorize enough theory to be a good engineer--untapped potential is a dime a dozen. The goal is to discover who has done that work.

Of course OSPF isn't Cisco specific, I never implied it was. My point was your questions would lead you to believe I was a better candidate, when in fact the opposite is true. If that isn't proof positive the questions are not good at assessing the merits of a candidate I don't know what is.

Virtual Labs and Scenario based questions are so, so, so much better than asking about LSA types, listing every BGP route metric, etc. If you can answer the question with google in under 15 seconds its probably not a good question.

NetworkVeteran

If you can answer the question with google in under 15 seconds its probably not a good question.

I remember, not long ago, an engineer working very hard to understand a problem. They were working quite persistently to analyze the RSVP-TE physical interface and tunnel configuration for any errors after determining the OSPF neighbors were FULL and the BGP sessions were all ACTIVE.

What would've weeded out this engineer?

"Name all the BGP states and tell me what they mean."

Yes, you can Google that in under 15 seconds. It's still important knowledge if an engineer's role will include troubleshooting BGP. When the moose droppings hits the spinning thingy, there isn't time to Google everything you see. You must have enough knowledge to spot and solve problems fast.

Which is more time-efficient and vendor-neutral?

(1) Spend an hour recreating this in GNS3 and give them 15 minutes to spot something.
(2) Ask that question.

Edit: I would add, it's okay to agree to disagree. Testing both knowledge and thought process has always worked well for me, and it's what I usually face in interviews and certification exams. If another process is working well for you in screening engineers, keep at it.

Forsaken_GA

NetworkVeteran wrote: »

"Name all the BGP states and tell me what they mean."

Yes, you can Google that in under 15 seconds. It's still important knowledge if an engineer's role will include troubleshooting BGP. When the moose droppings hits the spinning thingy, there isn't time to Google everything you see. You must have enough knowledge to spot and solve problems fast.

Note, I'm not trying to pick on you.

In this case, I would actually be somewhat lenient. I don't think a new candidate necessarily needs to know all of the BGP states, as long as they know anything other than Established means there's a problem. During an outage scenario, a BGP session going down is almost always a problem with a link, and not configuration related, and when I see a previously working link cycling between Active and Idle, it's almost always because a piece of transport gear went down. Connect, OpenSent, and OpenConfirm states are usually configuration or firewall related, and on previously established links, those should already be sorted out. The only time I've ever personally seen those come into play was during new link turnup, and for that, you most certainly do have time to Google.

Now, with that being said, if someones resume basically says "IM A BGP GOD!", then they'd better know it, in addition being able to give me the full list of BGP Path selection attributes and their precedence (and I'll admit, I don't even know those off the top of my head anymore, because if you get past MED, you've got something seriously screwed up going on)

NetworkVeteran

Forsaken_GA wrote: »

I'll admit, I don't even know those off the top of my head anymore, because if you get past MED, you've got something seriously screwed up going on)

We Love Oranges As Oranges Mean Pure Refreshment.

I don't require 100% on all my questions, of course. There's a difference between someone who says "Active" is good and someone who can't remember "Connect".

(I give more points for "I don't know" than a wrong answer.)

Roguetadhg

I have to respectfully disagree, NetworkVeteran. Apples.

Apples is where it's at.

Forsaken_GA

NetworkVeteran wrote: »

We Love Oranges As Oranges Mean Pure Refreshment.

You're missing a few

1. Weight
2. Local Pref
3. Local Origination
4. AS_PATH
5. Origin Type
6. MED
7. eBGP over iBGP
8. IGP Metric to Next Hop
9. Age
10. Router ID
11. Cluster List
12. Lower Neighbor Address

Once you get past MED, I tend to not remember the order (well, I always remember eBGP is preferred
over iBGP, but that concept is easy to retain just because of the AD difference between the two, so there's more reinforcement).

And then of course there are considerations as to whether or not multipath is enabled, plus you can short AS_PATH entirely, screw with the conditions under which MED is considered, and so on.

Most of that is trivia though, as BGP path selection is pretty much determined by two things in the real world: Local Pref set via communities, and AS_PATH prepending. Anything more complicated, and your upstream tends to start getting bitchy hehe

xxjojoxx

I can answer most of these questions off the top of my head...the troubleshooting is most important to me. I agree that source and destination for mac addresses changes based on network topology (how far across the network does the vlan go?). Some of the minutiae (a good word even if it sounds disparaging), I only study for interviews. So far I understand I should be looking at BGP, and QoS, and I should refresh OSPF stubby and NSSAs. I have taken a look at TCP transitions, but I've come to the conclusion this is primarily a programming exercise, unless you're seeking to recognize DDos issues implicitly. I cannot make a loopback DS-1 with a cable and pair of scissors....but I could probably beat someone to death with them (i've recently completed Army anger management if that's any consolation). What else should I be looking at we haven't covered from a network engineering prospective, aside from me going to wikipedia to memorize the cable standard for a t1, and remembering that the 802.1p extension to the dot1q tag has the cos field? Who here asks about tcp headers and ethernet fields? What firewall questions do you ask?

Brain_Power

The original question was "If you were a hiring manager, what is your top 3 technical interview questions for a Cisco Network Engineer?"

This is for junior to intermediate level.


So far, I am expecting the following as my top 3:

1. Explain the process of ARP

2. Explain the process of how a frame, packet, segment travels through the OSI model.

3. How does OSPF work?

sombn

May i know why every are in OSPF must connected to banck bone area

sombn

1)ARP means address resolution protocol
ARP is a protocol used by the IP (internet protocol).To map ip address to MAC address

example : when you try to ping from A(10.0.0.2 ) to B (11.0.0.2) from A ping 11.0.0.2 (assume A&B is connected to switch )switch won't understated ip address .only deal with physical address that is 48 bit MAC address . Switch will generate a broadcast (ARP request)

four types of arp messages

ARP request
ARP reply
RARP request
RARP reply