Cisco Network Engineer - Technical Interview Questions

I always start out with making them explain basic IP and Ethernet addressing as a packet travels through a network. You would be surprised at how many 'engineers' can't tell you what the source/destination MAC or IP is on a packet at different points in a network.

Other than that it would depend on job specific things and what technologies we use.

Brain_Power wrote: »

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

It doesn't really work like that for me. I'm often choosing questions that a candidate has never heard before. I want to see that they know all the topics that they claim to know.

For an intermediate position?

I might ask "Tell me all of the OSPF LSA types that you're aware of"? If you have ever heard of opaque LSA's, what are those used for? Which LSA types are flooded distance-vector style? Can multiple prefixes exist in a single LSA? Which LSA type(s) do not appear an NSSA area, and which LSA type(s) only appear in an NSSA area? What address are LSA updates sent to?

I might ask them to tell me about the BGP local preference and MED. What type of attributes are they? Do the affect incoming or outgoing traffic? Choose any vendor you like and tell me what are their default values and what commands might you choose to change them?

I might ask them to name all of the fields in an ethernet frame and tell me which field is used to consistently provide the length of the frame, and which field is used for CoS information, and where in the frame an 802.1Q tag would be inserted. What the heck is SNAP and LLC?

You would be surprised at how many 'engineers' can't tell you what the source/destination MAC or IP is on a packet at different points in a network.

Yep! And the wonderful thing is, each time the topology is a bit different. It's not the sort of question you can memorize. You really have to understand what's happening.

NetworkVeteran wrote: »

Yep! And the wonderful thing is, each time the topology is a bit different. It's not the sort of question you can memorize. You really have to understand what's happening.

Exactly! I like to see someones train of thought, not just if they memorized some facts right before the interview.

oli356

Considering I'm 17 I won't exactly be interviewing anyone anytime soon.
But for my Cisco apprentice job, the technical interview* wasn't like a test with set questions; it started off with a quick explanation of OSI model and how switches send data (source mac, destination mac - how does it know these) etc.

He drew a topology with about 10 switches and described a scenario (performance issues), I had to try and identify what it could be. I mentioned spanning tree, so I gave an explanation of what it is and then had a few questions about STP.

My point is, maybe try and not have a few set questions and just push the candidate on what they know.

*basic level - most people will not have any knowledge of networking before Cisco told us to go revise on x, y and z -- not even CCENT level. The interview was also 30 minutes.

Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?

oli356 wrote: »

My point is, maybe try and not have a few set questions and just push the candidate on what they know.

Yes, an entry- or junior-level interviews will be quite different.

At the intermediate- or expert-level, the expectation is that candidates not only have a good thought process, but also a foundation of knowledge and experience to draw on when solving problems. Usually, their resumes boast of all their strong areas, so if they're anything but, they've dug their graves before the interview begins. It's not uncommon to call in knowledgeable subject-matter experts to assess the areas in which a candidate claims to be an expert.

networkjutsu

Roguetadhg

That was a beautiful article. I like how all the concepts were boiled down to simple, short sentences.

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.

YFZblu

networkjutsu wrote: »

Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?

\

Great post! +rep

Roguetadhg wrote: »

Because inter-area OSPF is distance vector, it is vulnerable to routing loops. It avoids loops by mandating a loop-free inter-area topology, in which traffic from one area can only reach another area through area 0.

I admit, the first time I was asked that in an interview, my answer was not so eloquent.

(It was correct, though, and fortunately enough to pass.)

Shanman

What a great article. Thank you for sharing.

drkat

i dont really see the point in asking them where in the frame is this and that.. a frame isnt tangible.. so it makes no difference. -1

drkat wrote: »

i dont really see the point in asking them where in the frame is this and that..

A grasp of Ethernet frames is helpful when configuring/troubleshooting the Data Link layer.

For example, the "Where is the CoS?" would reveal whether the candidate knew that the CoS info is stored in the 802.1Q tag and not the 802.3 frame itself. The difference between tagged and untagged frames is quite significant to a network engineer, as among other things there are configuration differences between tagged vs. untagged ports.

a frame isnt tangible.. so it makes no difference. -1

That failure of logic is unbecoming of a doctor.

IP addresses, subnet masks, and the operation of routing protocols are all intangibles (imperceptible by touch) of importance to those in intermediate- to expert-level networking positions.

drkat wrote: »

i dont really see the point in asking them where in the frame is this and that.. a frame isnt tangible.. so it makes no difference. -1

You are probably the exact type that would fail that question! A deep understanding of the fundementals is the most important thing. If you don't have a solid base to build off of the rest will fall short.

shodown

I usually try to get a good fundamentals of IP routing. Then from there I build on what they have on there resume. I try to leave our specific network off as I dont think its fair to ask questions about a network you have a few years of experience on. I usually don't even ask Platform specific info either. I have found over time that if someone knows the fundamentals then the platform becomes a moot point. If they know how OSPF, BGP, and Vlans work they will just need a small jump start and they can operate on our network in no time.

drkat

networker050184 wrote: »

You are probably the exact type that would fail that question! A deep understanding of the fundementals is the most important thing. If you don't have a solid base to build off of the rest will fall short.

Heh.. You are very ignorant to make such a presumption.

My comment was simply that I want to know if the guy can do the job, not if he can recite theory and book knowledge back to me.

DPG

I look for someone that can solve issues when **** hits the fan, not someone that is only book-smart.

DONQUIXOTE007

I would set up a network lab base on their level of experiance and education, and install a bug in the network set up, and I would ask them to troubleshoot it and fix it. Ask them to explain what was the problem and how he/she solved the problem.

I pretty much always ask folks to explain to me how ARP works. It is absolutely staggering the amount of people who think that routers and hosts ARP for every single IP address.

But I'm not a huge fan of trivia questions, I like to ask scenario based questions to see how people think.

For example, one of my normal opening questions -

"You've received a call that a device out in the field has lost connectivity. The field tech is insisting the problem is the network. You log into the switch the device is connected to, and you verify you're learning the mac address of the device on the correct port, and you can ping it from the switch. The field tech informs you that the device can ping the gateway IP, but nothing outside of it's own subnet. You redo your ping, this time sourcing it from an interface on another subnet, and it fails. Is the problem the network and why or why not?"

Now anyone with any measurable experience is going to immediately say the host is f'ed up, either it's subnet mask or it's default route is wrong.

This was an actual call that managed to get escalated all the way to me. They already had the vendor on the phone, and the vendor was insisting it was the network. I had the vendor get me into the boxes command line, first thing I do is display the routing table, and the default route isn't even present. It was set in the configuration files, but the kernel didn't pick it up for whatever reason. The vendor had egg all over their face, and the problem was resolved shortly thereafter. However, they were dicking around with this for 5 hours, with a video outage occuring because of it the entire time, and it went through some people who should have known better. So for anyone who thinks getting asked basic questions is offensive and beneath you, get over yourself. Thank your lucky stars you're being asked something easy, and use the opportunity to dazzle them with your mastery.

Other questions I ask based on the candidates resume, for example:

"Earlier today, a site reports that their multicast feed for a particular group went away. You login to the router and check the multicast table, and see
the route for the source,group. You see the proper amount of multicast bandwidth being transited out the interface connected to the device. Is the problem the device, or the network, and if it's the network, how do you continue troubleshooting the problem?"

To be able to have a prayer of answering that one, it requires two things - basic CCNA experience in how access-lists work when applied to an interface, and a fairly good knowledge of QoS markings. Oh, and a brain to put all the pieces together. That's important too. That question I wouldn't ask someone who's never had any experience with QoS, or isn't showing any certs that require QoS knowledge on their resume, but for someone who does, yeah, we're going to talk about it.

Now, I don't expect folks to get the questions right all of the time, and I'm just as interested in how they get to their answer than in whether it's right or wrong. If someone freezes and can't even begin to think of where to troubleshoot, then I don't want them on my team. If they can't even talk about where to start in an interview, they're going to be worthless during an actual outage. If someone engages and tackles the problem, and can logically walk me through how they get to their conclusion, I look more favorably on that, even if they're wrong. Deficiencies in skillsets and knowledge I can correct. Can't fix stupid.

lantech

Forsaken_GA wrote: »

For example, one of my normal opening questions -

"You've received a call that a device out in the field has lost connectivity. The field tech is insisting the problem is the network. You log into the switch the device is connected to, and you verify you're learning the mac address of the device on the correct port, and you can ping it from the switch. The field tech informs you that the device can ping the gateway IP, but nothing outside of it's own subnet. You redo your ping, this time sourcing it from an interface on another subnet, and it fails. Is the problem the network and why or why not?"

Now anyone with any measurable experience is going to immediately say the host is f'ed up, either it's subnet mask or it's default route is wrong.

I'm going to get a little off topic here but I'm curious about something. In the scenario after you ping the host from the switch why not use an extended ping command to emulate a ping from the host that is failing to another device outside of its subnet?

Roguetadhg

I'll bite, Forsaken:

1. Switch can ping X (Same Subnet).
-- To complete the ping, no routing needs to be done as it's a same-subset address.
-- Not blocked via port security, port not shutdown - there's life between X and Switch
-- X's subnet information is correct. Otherwise a ping wouldn't work.

2. Switch picks up the correct MAC address, on the correct port.
-- CAM table is correct. So there's not the same mac coming from a different port (MAC Spoof?)

3. X can ping the default gateway. Can't ping anywhere else.
-- At this point I'd say the router was botched somewhere. I'd check the routing table.

Although there's something that bothers me - Can another host on the same subnet/vlan as X get out to the world? This is one spot that hasn't been answered for me.

I tried to look at the problem and not anything afterwards.

Edit: I see that the problem was the host?
"Now anyone with any measurable experience is going to immediately say the host is f'ed up, either it's subnet mask or it's default route is wrong."

Oh, second problem!
Er. Multicast Feed? I have no idea what that means but I'll still bite!

Problem with host? If the correct traffic is going outside of the router then it should work?
Can the device ping the device on it's subnet? Can the device ping the gateway? How about the gateway's other interface? What about the interface on the other router?

Rep for you Forsaken, for making me think first thing in the morning.

lantech wrote: »

I'm going to get a little off topic here but I'm curious about something. In the scenario after you ping the host from the switch why not use an extended ping command to emulate a ping from the host that is failing to another device outside of its subnet?

Good follow up question. The part I held back was that there were other hosts on that subnet (this device was one of seven) and all of them were working fine, which takes a routing problem out of the equation. I purposely withhold some information to see if the candidate is willing to engage and ask questions.

When I was handling the escalation, I made my inband connection destined for the SVI's IP on the switch for that VLAN, so I knew immediately that there was no problem routing to the vlan, the problem was in the response. After checking whether or not a mac was being learned and pinging the host from the switch, that verified that layer 1 to 3 were working to the device. At that point, there's only one thing network side that can really be the problem, and that would be a fudged inbound access-list, but since this device was working fine prior to them messing around with it, that wasn't likely to be the case.

Other variations on this theme include the device being replaced with a new one and presents as not being able to be pinged anymore (that's usually an ARP problem, or someone fat fingered the IP when configuring it). Or the facility lost power, and when the device came back up there were issues, and so on.

For something that was working fine and then stopped working, it is very very rarely a network problem. Network problems tend to be systemic and noticeable to more than a single device, so when a single device presents a problem, I become very skeptical that the problem is actually with the network, and I can usually prove that in under 5 minutes.

Roguetadhg wrote: »

I'll bite, Forsaken:

1. Switch can ping X (Same Subnet).
-- To complete the ping, no routing needs to be done as it's a same-subset address.

Correct, by default, the ping will exit on the next hop interface, which in this case was the SVI of the vlan, which was in the same subnet as the device, so the ping will source from that interface.

-- X's subnet information is correct. Otherwise a ping wouldn't work.

Not entirely true. For example, if my switch has the IP 192.168.1.1/24 and the device has the IP 192.168.1.2/25, the ping will still work. For this reason, I make it a habit to verify the subnet mask on hosts when troubleshooting an issue. It may not be the cause of the problem I'm working on, but if it's wrong, it might cause problems later (or already has but nobody has noticed yet).

The other thing the ping tells you is that it's not an ARP problem. In order to get the ping response from the switch, it has to be encapsulating it to the correct MAC address.

3. X can ping the default gateway. Can't ping anywhere else.
-- At this point I'd say the router was botched somewhere. I'd check the routing table.

And that's the assumption that everyone makes, and it's almost always incorrect. If you could ping some places but not others, then it's valid the router might be botched. If you can't ping *anything*, that's a good indicator that machines routing table is botched, not the routers.

Although there's something that bothers me - Can another host on the same subnet/vlan as X get out to the world? This is one spot that hasn't been answered for me.

And that's part of what I'm fishing for, because yes, as I mentioned, there were six other hosts on that subnet without any issues. If a candidate will ask that question, it tells me that they're using their brain and putting the pieces together, and they're NOT making the cardinal mistake of believing what they're told (every single time I catch a newbie going off only what they've been told on escalation and troubleshooting on the basis that the information they've been given is correct, they get a lecture. Always verify your inputs.)

lantech

I'm pretty proud of the fact you said I had a good follow up question. But curiosity got the best of me as I was reading and I was wondering how it would end so I just kept reading. But reading the answer I could see the logic behind what you were saying.

pert

NetworkVeteran wrote: »

It doesn't really work like that for me. I'm often choosing questions that a candidate has never heard before. I want to see that they know all the topics that they claim to know.

For an intermediate position?

I might ask "Tell me all of the OSPF LSA types that you're aware of"? If you have ever heard of opaque LSA's, what are those used for? Which LSA types are flooded distance-vector style? Can multiple prefixes exist in a single LSA? Which LSA type(s) do not appear an NSSA area, and which LSA type(s) only appear in an NSSA area? What address are LSA updates sent to?

I might ask them to tell me about the BGP local preference and MED. What type of attributes are they? Do the affect incoming or outgoing traffic? Choose any vendor you like and tell me what are their default values and what commands might you choose to change them?

I might ask them to name all of the fields in an ethernet frame and tell me which field is used to consistently provide the length of the frame, and which field is used for CoS information, and where in the frame an 802.1Q tag would be inserted. What the heck is SNAP and LLC?

Yep! And the wonderful thing is, each time the topology is a bit different. It's not the sort of question you can memorize. You really have to understand what's happening.

I really have to disagree with this post. These are the sort of questions I excel at, I am great at Cisco trivia. However, these sort of questions are almost completely useless in determing how skilled an engineer is. I work with guys who know way more than I do and can do everything I do in half the time. Yet if we both had to take the technical interview you're describing I would be running laps around them and appear to be a much better candidate. Which is completely the opposite of the truth. Cisco trivia questions are not good for anything except for entry level people with no experience. Technical interviews are better done by actual virtual labs, or at least scenario based questions. X can't ping Y over Z topology, what steps would you take to troubleshoot it? Then dnamically giving them bits of more info as they explain their process to see how they chase it down will give you real information about the skill of an engineer. Asking them to name every OSPF type will show you who can memorize written material and nothing else.

WafflesAndRootbeer

I agree with Pert. Asking the type of irrelevant queer minutiae questions that you'd find on network theory or fundamentals flash cards (or a CompTIA exam) with the impression that they must answer it quickly is only going to get you disappointed and piss off potential hires. People do not retain that sort of knowledge and even the networking fanatics I know couldn't answer those types of questions without referring back to their books and such because they don't recall that knowledge on a daily basis let alone a regular one.

pert wrote: »

These are the sort of questions I excel at, I am great at Cisco trivia.

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

Yet if we both had to take the technical interview you're describing I would be running laps around them and appear to be a much better candidate.

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.

Asking them to name every OSPF type will show you who can memorize written material and nothing else.

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.

I agree, the facts and methodology are important. Obviously you need to know the facts about the protocols and how they work, but you must also take into account that someone can easily find these facts if they are forgotten. What you want to find out is if the person you have has the right line of thinking that will lead them to either knowing these facts off the top of their head or googling them. For example someone designing an OSPF network may not remember off the top of their head what LSA types are exchanged between certain types of areas, but the fact that they know there are different types and its something that needs to be taken into consideration is more important in my opinion. It shows the proper line of thinking and attention to detail that is far more important in this field than how much information you can retain.

Not knowing the basics is something that should never be tolerated though. If you don't know how packets move through a network you are going to have trouble.

Roguetadhg

You need to know the theory behind why things work to be able to troubleshoot effectively. ...Unless you like the idea of being a blind man feeling around inside a router- sweating buckets in an icebox, listening to your boss on one phone, and the vendor on the other.

You stop in the middle of typing "exit" as words fly across your mind. You suddenly get a hot flash (Like you've just got caught speeding in a school zone.) that you just realized "I'm a fraud." Then another set of word piles ontop, weighing you down more... "I don't know what to do. Where do I begin?"

//End Scene

All Interview questions are there so that above scenario doesn't happen to you.

I think troubleshooting should be the key, scenarios as well - mostly because they test a person on more than just 1 level. Forsaken needs his own "Troubleshoot This" thread. Every morning.

I think there are basic topics persons should know, especially if you tout a "CCNA." Any certification is worthless if you can't remember what you studied. Why list it? Why list something that when you'll go into an interview, the interviewer expects you to be "Down wit it." Would you rather spend a few hours refreshing this information every so often or to forget what you spent your free-time learning? I don't know about you, but I'd like to remember what I spent countless hours studying over the course of 6 months.

I'm sure we all would not like to fall into the position of being labeled a "paper tiger" or a dumper. All because we forgot trival information that our resume says "We know". Just because we have X certification doesn't mean we get a free ride. Remember that scenario and the hot flashes?

For all those that study hard, lab harder and enjoy every freaking moment of it - except for going too typing happy and finding out you forgot to issue a "no shutdown" at the end of the configuration, and spend 2 hours trying to figure out why Frame Relay wouldn't work... Urgh. Humble pie was served. ... For all those that do the work, remember the information. Remember that the CCNA is the foundation for most things. Expect to be quizzed on it. It may not be a formal interview. Worse, It may be under pressure and you'll find yourself saying "The defecation just hit the oscillation"

Do yourself a favor. Do the time. Refresh that memory.

I say this knowing I need to revisit my ICND1 notes. Horrible notes. I guess "Redo" the notes is better said.

Do as I say, not as I didn't do :P

Edit: I spent 38+ minutes for this reponse. Bah!

RouteThisWay

I have been in situations where I didn't know the answer and never considered my "a fraud".

I chalked it up to I didn't know the answer and used it as a learning experience? If you believe you will go into a job and know the answer to every problem you are mistaken.