What kind of networking questions do you ask an candidate in an interview?

I'm in an interesting issue. My manager has been having me interview new potential network engineer candidates and I've been using what I think are easy questions to screen their technical skills. Without fail, people with 10-15 years of "senior network engineer" experience can't answer 9/10 of my questions.

I ask some pretty basic EASY stuff:
"How do you configure an SVI on a multilayer switch?" (Best response - "You create a subinterface...")
"How do you enable routing on a multilayer switch?"
"You are viewing the ingress traffic on a multilayer switch by means of a SPAN port. Just looking at the packets going in, how can you tell whether the packets are going to L2 or L3 switched?"
"Oh, I see you have experience with (whatever routing protocol listed on their resume). How would you configure that on a router?"
"How do you configure rapid spanning tree?"
"Give me the general idea of STP?"
"What is a VLAN and how do you create one?"
"How do you configure VTP?"

Without fail, people with years and years of experience get 9/10 questions wrong and when I mean "wrong," I mean not even REMOTELY right.

What is the experience of other engineers out there? What kind of questions do you ask?
Am I being too mean or just running into a lot of slow people?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

nerdydad

Zartanasaurus wrote: »

IP protocol #s and ethertype codes.

Really?

If someone has experience I expect they have pushed this kind trivia so far to the back of their heads I would never expect that. We were talking about port numbers earlier at work and I made the joke, "the port number for ftp is eq ftp".

I get that things like this are useful in troubleshooting issues, but there are just way to many things to remember in this field to keep track of the trivial.

NetworkVeteran

nerdydad wrote: »

If someone has experience I expect they have pushed this kind trivia so far to the back of their heads I would never expect that. We were talking about port numbers earlier at work and I made the joke, "the port number for ftp is eq ftp".

It's interesting how we all have slightly different definitions of trivia. While I know ports 21, 22, 23, and 25 intimately (but oddly not port 24!), I also consider these "trivia". On the other hand, I know in detail the OSPF/IS-IS/BGP messages and states. I suspect many of us know very much, and these differences point to the hats we've been wearing. A good engineer is one who knows a great deal of "trivia" related to their current position. A great fit is someone who also knows some "trivia" related to the opening.

One trick I like to use is I have a massive software flash card deck organized by subject. While I only retain ~92% of it, when I know I need to be on-the-ball with respect to a particular technology or OS, I can brush-up on that very quickly. This is an attempt to find a balance between "I can't know everything" and "I'm expected to know more."

I also handle leadership differently than in the past. I am not only quick to help others, but also to ask for help. I realize that everyone I work with has their own special and unique talents. I will never know everything well.

union122

A couple commons questions I was asked.
1. What is Cbit ?
2. What are the errors you look for when a T1 line is reported down ?

chmod

One question that most of the candidates that i have interview always fail is: Please explain how traceroute works 9 out of 10 don't know hahaha.

Based on all the responses of this thread this makes me wonder what should we do with the rusty-out of practice knowledge we have listed in our resumes.

For example lets imagine irishangel is reading my resume she says chmod seems to be good enough, she calls me and ask me to pass by her office for an interview she reads that i have asterisk experience/knowledge i have installed probably 10 asterisk servers for call centers i have my LPI cert so i'm supposed to know everything about linux/asterisk although i haven't done any asterisk installation t since 2008 so she throw me all those technical questions and i fail/don't remeber in detail the half of the questions so she says this guy is a braindump engineer with a resume full of B/S.
I was an SME for a telecom vendor for 3g/ngn/LTE networks i used to know every single detail about the hlr to msc MAP messages exchage handled by the C interface or the MAP/D messages for attaching to the CS network and location update i still understand it but don't know it in-depth anymore i would have to review it for a few weeks and check some traces to refresh that knowledge at that level i don't even remeber the location update flow which is basic stuff.

If i have a technical interview i review whatever i consider relevant but if i'm tested in something i haven't touched/studied/reviewed in years i tell the interviewer the truth: I did that long time ago i'm rusty and i can only give you a general overview but i can't tell you the details nor answer complex technical questions but i can refrest that knowledge in a few weeks if needed is hard to keep up to date in each single topic of IT.

That is why some people can give you an straightforward answer on a switching question(or a bunch of sw questions) but fail on routing or security questions.
Off course we shouldn't "forget" the basics of DNS-ARP-TTL-ICMP-VLAN-Routing-Wireless even of programming because we are engineers we should have at least a basic knowledge of a lot of things.

Mrock4

Yeah, I don't list ANYTHING on my resume unless I feel I know it cold, OR if I don't I use clear wording such as "familiar with..." as opposed to "skilled with.." - so that I'm clear I'm no expert on the topic. My experience has been interviewers are generally pretty understanding if you don't claim to be an expert on topic.

And yes, I learned this one the hard way. I listed something on my resume (can't remember what it was now) that I was "OK" with..and got grilled on it. I removed it from my resume as soon as I got home. I got offered the job in spite of that, though.

nerdydad

The reason I list things on my resume that I may not have use in a while is because I did know it, and I think we all agree that, once you have known it, it is very easy to refresh your skills.

chmod

The reason of my previous post is because irishangel said people with 10 to 15 years of experience don't know the answer to very easy and basic questions but ask a lot of "How do you" type of questions which is hard to answer if you haven't done (in this specific case) l3 switching in a long time that does not necessarily prove you that the candidate do not or do have the knowledge required. Is different to know about switching and how an l3 switch works and how STP works among other technologies than to remeber on the top of your head "how to do" something in a l3 switch specially if you haven't touched one in 2 or 3 years or even more time.
The fact i don't remember a command to enable something does not mean i don't know about switching or in this candidate the candidate don't know about switching or networking in general. I think there are better ways to test a candidate unless you actually need an SME in that case the person that applies needs to be currently working with all SW stuff, for example a consultant working for a cisco partner they for sure have all the commands/image version details for specific products on the top of their heads.

The fact you have a CCNP that does not necessarily means you know "how to do" everything on cisco devices because ccnp covers a lot of things so is better to check the candidate resume assess them in their strong areas and them you can ask them hey i see you worked with BGP-OSPF 6 years ago using linux servers and cisco routers, do you still remember how to do that, do you have a strong foundation on that or you only did very basic stuff? did you design a BGP-OSPF network or just monitored it?

If i need him to design troubleshoot ISP's network as part of his daily task i can them go to the blackboard and have him solve/design something based on whatever i need him be doing daily and from there if he does well i keep asking and asking to see how much he really knows.

Zartanasaurus

nerdydad wrote: »

Really?

If someone has experience I expect they have pushed this kind trivia so far to the back of their heads I would never expect that. We were talking about port numbers earlier at work and I made the joke, "the port number for ftp is eq ftp".

I get that things like this are useful in troubleshooting issues, but there are just way to many things to remember in this field to keep track of the trivial.

I don't expect them to have this memorized (although knowing IP protocols can be useful when writing ACLs), it's more about understanding how the OSI model works layer by layer and the idea of multiplexing. I'm using it as a teaching tool not an interview question. It's something that can be easily looked up in documentation when you need it, but you need to understand the concept of TCP/UDP ports, IP Protocols and Ether Types and what they do.

The port # of ftp is ftp, unless you're using active-mode, then it's ftp and ftp-data.

FTP is a great tool to teach about state tables.

chmod wrote: »

One question that most of the candidates that i have interview always fail is: Please explain how traceroute works 9 out of 10 don't know hahaha.

Windows or *nix based host?

okplaya

The job title "(Sr)Network Engineer" is used too loosely nowadays. Just my opinion though.

Kelkin

Iristheangel wrote: »

I interviewed with a fairly well-known networking company in San Jose for 8 hours straight and I got drilled every which way from configs to design to logic puzzles.

I heard of such interviews before where you are grilled hours on end.. Honestly I don't see the real point of that.. I could be wrong but I feel you can weed out the bad apples in a hour or two with just holding a conversation with them and working through some lab scenarios..

wes allen

Zartanasaurus wrote: »

I can't find the article right now with Google for some reason, but there was a good article over at Etherealmind about how he conducts interviews and the types of questions he likes to ask as well as the ones he doesn't like to ask.

Is this it? How do you interview for technical people?

Mrock4

nerdydad wrote: »

The reason I list things on my resume that I may not have use in a while is because I did know it, and I think we all agree that, once you have known it, it is very easy to refresh your skills.

Definitely. I mean, I can't disagree with you, we're going to be having lunch at RTP in a few months together

But really, I think it's personal preference. I worked with Cisco CallManager 4.1, but I've removed that from my resume because A) I *completely* forget anything about it, and

CUCM 8/9 is so incredibly different from what I used, it's almost worthless for me to list it. I could understand listing technologies that don't change a lot though.

jason_miller13

Completely agree, I see a lot of "Network Engineer" job titles that don't mention anything in the req about networks but require MCSE and powershell exp.

Zartanasaurus

wes allen wrote: »

Is this it? How do you interview for technical people?

No, but I found it. It was at PacketPushers, not EtherealMind.

Four Interview Questions I Have Asked Network Engineering Candidates

wes allen

Cool, a good read for sure.

nerdydad

Mrock4 wrote: »

Definitely. I mean, I can't disagree with you, we're going to be having lunch at RTP in a few months together

I hope so, the current employment environment has been severely cramping my studies.

jason_miller13

Iris - Is this position still available? I'm looking for a transition and am in Cali.

chmod

Zartanasaurus wrote: »

No, but I found it. It was at PacketPushers, not EtherealMind.

Four Interview Questions I Have Asked Network Engineering Candidates

Funny, that article mentioned how i said i interview network engineers, i should apply for a technical recruiter position hahaha.

chmod wrote: »

When I do interviews i never focus on "how to" type of question i focus on his foundation if has good foundation that is what i actually care about, in you understand how things works you can just read a manual and refresh your CLI knowledge is all about understanding the technologies more than knowing a lot of commands you can even memorize them but not understand them, so how you design or troubleshoot something you don't understand deeply.

I love the blackboard so i enjoy asking them: Can you show me how this works, explain to me the process of....., let me picture the following scenario and tell me what would do in this case or show the mistakes, the i ask more questions based on what they respond and engage them into technical discussion but the blackboard is my favorite part it is easy to b/s an answer but to prove it with real life examples is different etc etc etc

chmod wrote: »

is better to check the candidate resume assess them in their strong areas and them you can ask them hey i see you worked with BGP-OSPF 6 years ago using linux servers and cisco routers, do you still remember how to do that, do you have a strong foundation on that or you only did very basic stuff? did you design a BGP-OSPF network or just monitored it?

If i need him to design troubleshoot ISP's network as part of his daily task i can them go to the blackboard and have him solve/design something based on whatever i need him be doing daily and from there if he does well i keep asking and asking to see how much he really knows.

Somnipotent

I'm not sure what resources you have available to you but here's a suggestion:

Have a two part tech interview. The first part being theory and the second being application. The theory should be based off what they've listed on their resume. If they list it, they'd better know it. Start shallow and go deeper until they get stuck. Case in point: Oh, I see you know MPLS, tell me, what's a VRF? What does an RD do? How about a RT? Since you know MPLS, I'm sure you'd know a bit about BGP. Tell me what protocol does BGP run on top of? What port? To their certification level. Ideally this should weed out a lot of candidates off the get go.

If they pass, set up a GNS3 lab for them to perform on. Have a topology already laid out and some basic configuration tasks. Set up BGP between these two neighbors. Load balance between these two circuits. Redistribute. Also, have some broken things set up to. Ensure end-to-end reachability and check outputs to verify. If they can manage these tasks, then they can move on. My boss, (CCIE #7426), would do this and he said this effectively made his choices much easier. Although, this is pretty hardcore, but imagine how many people would just get up and walk away when tasked to the config lab

chmod

Mrock4 wrote: »

Yeah, I don't list ANYTHING on my resume unless I feel I know it cold, OR if I don't I use clear wording such as "familiar with..." as opposed to "skilled with.." - so that I'm clear I'm no expert on the topic. My experience has been interviewers are generally pretty understanding if you don't claim to be an expert on topic.

And yes, I learned this one the hard way. I listed something on my resume (can't remember what it was now) that I was "OK" with..and got grilled on it. I removed it from my resume as soon as I got home. I got offered the job in spite of that, though.

Lets say you are a network engineer with 12 yrs of experience you have listed 10 of those 12 years of experiencie in your resume lets imagine the first 4 years you worked as a linux support engineer working with snort/iptables and bsd the the other 6 years you worked for a cisco partner or juniper tac.

Unless you kept practicing at your own is very hard to remember iptables/snort/bsd in general after 6 years of not touching one. What do you do?
Remove 4 years of experience so you don't get a question on "how to do" something on a bsd box or how to solve a snort-iptables issue?

Mrock4

chmod wrote: »

What do you do?
Remove 4 years of experience so you don't get a question on "how to do" something on a bsd box or how to solve a snort-iptables issue?

It depends:

-If you're applying for a network position, include the linux position, don't highlight it (ie: don't put bullet points about your linux experience)
-If you're applying for a linux admin position, include the network position, but put more focus on your linux experience (less technical details about your 6 years of networking, more of a general overview).

See the theme there? Always include the job experience (ie: worked for company A for X years), but don't include every protocol you've ever touched..UNLESS those are completely relevant to the job you're seeking.

To play off your example, John has 10 years of experience in networking, 5 years in Microsoft technologies (the beginning of his career). He's applying for a network gig:

-Resume includes timeline of positions held (including MS and networking jobs)
-Resume highlights technical details of networking experience (ie: Worked with OSPF/BGP, etc etc)
-Resume does not highlight technical details of Microsoft, but instead an overview (so that the employer can inquire if they feel it's relevant)

Scenario 2, John decides to go back to the darkside, and applies for a microsoft job. It's hard to completely leave out 10 years of networking experience, so he lists it in moderate detail (but again, few technical details), such as "Designed networks for fortune 500 companies utilizing a wide range of LAN/WAN protocols"..as opposed to "expert with OSPF, RIP, BGP"..99.999% of the time, a microsoft hiring manager could care less about these details.

-He highlights his MS experience, including bullets, technologies/protocols relevant (which could possibly overlap with his networking experience)

-John gets job

Make more sense? Not sure I was clear..include the EXPERIENCE, but not the TECHNOLOGIES if they are *not* relevant to the job you are applying for. As a side note, nobody said you had to have one version of your resume either. I've got a R&S version, Security version, and Management- all 3 list the same experience, but each one highlights different aspects.

My management resume highlights leadership experience held while working as a lead engineer, whereas the security version highlights my security experience from that position..

chmod

Got it!!

I also have 2 versions of my resume one with that highlights the technical experience i mean all the *nix and voice stuff i've done throughout the years and other for management positions.

By the way....the darkside lol hahaha

Mrock4

chmod wrote: »

I also have 2 versions of my resume one with that highlights the technical experience i mean all the *nix and voice stuff i've done throughout the years and other for management positions

Right on. I've been fortunate to spend 90% of my career in the same field (route/switch), and that first 10% (Microsoft experience) I pretend was like a sexual encounter gone awry...we just pretend it neverrrrr happened.