Four Interview Questions I Have Asked Network Engineering Candidates

Being on an interview panel is an experience I thoroughly enjoy. My job in such situations is usually to be the technical heavy. I need to determine what the candidate knows, what the candidate’s doesn’t know, and what I think the candidate could figure out.

First, here’s some things I don’t ask.

1. Trivia. I rarely get into a trivia competition with a candidate. Trivia proves very little to me. If a candidate recently passed a certification exam, they might have a head full of networking trivia. I don’t care, because I don’t want to to see whether or not the candidate has a head full of arcane facts. I want to determine what they can do with their knowledge. Believe me – I can out-trivia you. And you can out-trivia me. All either of us need is enough time with Google or the right books to come up with some obscure questions.

2. Tell me about your ideal job. I don’t care about this one, either. The ideal job doesn’t exist, so if the candidate is looking to work in the tree where the elves make cookies, they’re likely to be disappointed. Besides, that’s a subjective sort of question that the candidate might feel pressured to answer with words they think you want to hear. There’s no point in this for me.

3. Are you a team player? This is a silly question, because they will almost always answer in the affirmative, no matter what the reality is. Honestly, I only nominally care how much of a “team player” they are. I don’t care if they work by themselves as long as they follow standard procedure and get done what’s been asked. Not every corporation could work that way, obviously, but it’s one of those questions I’ve heard often that I think is almost pointless.

And now, here are some things that I have asked.

1. Draw a diagram on the whiteboard of a network you’ve worked on, and explain it to me. This might be the only question I ask in the interview, depending on how it goes. For the right candidate, this will tell me everything I need to know.

  • How did the diagram start? From the center out? Or from the edge in? Or did it seem a bit random? This tells me how clearly the network was in the candidate’s mind, and the way that they thought about it.
  • How does the diagram look? Is it a horrible disaster of overlapping shapes and lines, or is it easy to read? I don’t mind if candidates have to re-draw. That just tells me they care about what their diagram is communicating, which is a good thing.
  • How well is the candidate explaining the diagram? This is where it gets interesting, because as the explanation moves forward, you can begin to probe the candidate to find out what they really know. Oh, so that’s the core switch. Was there one core switch or two? Or more? Did you run a first-hop redundancy protocol on those switches? Why or why not?  What routing protocol did you run in your core? OSPF? Oh, then tell me about how your areas were laid out. Oh, so that’s the edge of your wide area network, I see. What routing protocols did your carrier support? You say you ran VoIP across your network. Tell me how you handled congestion on slow links to preserve call quality. You say your network design was meant to help with PCI compliance. Fair enough. Pretend I’m an auditor and walk me through the various subnets, firewalls, and security policies that are in place related to PCI.
  • And so on. The diagram becomes the basis of an exploration of the candidate’s knowledge. Even for entry and mid-level candidates, this is a fair question to start off with. If an entry level guy draws one switch on the board and then shrugs his shoulders apologetically, you can find out just how well he knows that one switch. Did you provision ports? What did the standard switchport template look like? Why was command X used? What did you do to stop CDP advertisements from leaving unused ports?

2. Your resume says that you worked with BGP. Tell me about that. Or, whatever the skill is – it doesn’t have to be BGP. The idea is to lift a skill exactly from their resume, and see how deep their particular well of knowledge goes. They claim to know BGP? Great. That could mean anything from building simple neighbor relationships and advertising a /24 to managing a complex mesh of autonomous systems with customized policies. The candidate doesn’t need to know everything you know or everything there is to know. The chances are you don’t know everything there is to know yourself. The point is to see just how much they do know, and then see if that’s sufficient for your needs.

3. You’ve got nothing but a laptop that’s been assigned a DHCP address and no other special privileges. Explain the steps you would take to discover the network topology from there. Now, this is a loaded question. Practically speaking, there is a limited amount of network that can be discovered if it’s even vaguely secure, but an engineer that’s been around the block will come up with hopefully several of the following answers. Running a ping sweep against a range of addresses. Running a packet analyzer and seeing what sorts of broadcast frames come across the wire. Running a MAC flooding tool to get the switch to dump all traffic to their port through unicast flooding, and seeing what they can pick up from that. Running traceroute to Internet addresses and then scanning each hop that reports back. Seeing if the DNS server will let them do a zone transfer. Running a SNMP scanner, looking for open systems. Walking around the building and plugging into as many ports as they can find. Setting up a route daemon on their local system and see if they can form an adjacency with something on the local segment. Searching the local RIR database looking for tell-tale records.

The idea with a question like this is to answer the question yourself ahead of time on a sheet of paper, then see what the candidate comes up with that lines up. Then, as they make their suggestions, you can probe them. Oh, so you’d try to get a DNS zone transfer. And if you succeeded, how would that information help you? Ah, so you’d look for broadcast traffic with Wireshark. What sort of broadcasts would you find useful? As the candidate explains their answers, you learn about their knowledge, but you also learn how they think. Is the candidate clever? Resourceful? Independent? Determined? Logical? Or is their only answer that they’d go up to your desk and ask you for a network map (see the next question below)? What happens if you point out a critical flaw in their logic? Do they get defensive? Angry? Or do they see the error they made and move on?

4. Explain how you find answers when you don’t have them. You want to find out one thing from this question: whether or not this person is going to live at your desk, asking you every little thing they can’t grok in two minutes. You don’t want that. You want the person who, within reason, doesn’t bother anyone else until they’ve exhausted every possible avenue to find the answer themselves. You want the candidate to tell you they’ll Google, search vendor manuals, try five different command sequences, build a lab exercise, scour documentation in the local wiki, etc. The last thing they should do is come to you, and once they do, they should be armed with all of the things that they tried that didn’t work out.

To sum up my approach, I want to get inside the candidate’s head as much as possible. I don’t need the candidate to know everything, but I do need to be confident that their thinking process is sound, that they are motivated to discover new things, and that they have the capacity to learn. Anyone like that will likely end up to be a great asset.

Read the follow up to this article, “More Interview Questions To Ask Network Engineering Candidates.”


  1. WaxTrax! says

    This is excellent. As a person who is essentially beginning their career as a network engineer and has not yet pursued a meaningful position to that end, this kind of information is extremely valuable.

      • Evol Syawla says

        First thing is to get Juniper training. Second thing, get Juniper training! Third thing get certified. Practice a lot. Then seek job!

  2. says

    I love question 3! One of my favorite questions is just “explain QoS to me”. Communication skills are as fundamental to the job as the technical chops. It’s amusing how many people just say ” oh that’s easy! That’s just the 802.1p and ToS bits, right?”

  3. says

    Great post! I like all the questions you provided. It really makes me ask the same questions about my network.

    The questions are structured in a way where you think about every aspect of the job and realize where your gaps may be.

  4. Monkey says

    This is great. Working for the state there are far too strict interview guidlines, not being able to ask questions other than pre-approved by HR (eg. follow up questions are forbidden, can only say “please clarify further”) so I am always looking for good open ended questions that can actually show what someone knows without me needing to ask forbidden “probe” questions.

  5. Alexandra Stanovska says

    Nice questions. The third one – would a valid answer be “I’d go to local sysadmin and ask for diagrams”? 😉

    about question to the style of drawing some small network and ask
    question “how would you make this part of network the most reliable” or
    “fastest converging” or similar. Can be quite a brainstorming session
    too – and you do learn about basic spanning tree and routing protocol
    timers at CCENT level. Depending on what people know or are expected to
    know about network they work with, it can go from layer one (UDLD you
    learn about at CCNP level… even chassis itself with dual routing or
    switching engines) up to “EEM triggered MPLS FRR” … okay just making
    up this one :-) May be an interesting discussion – what happens with
    spanning tree if this line goes down, will routing protocol converge if
    you previously said you lowered timers, can you then stop BGP from
    withdrawing and advertising route everytime it goes down … and so on.

    • STP Jocky says

      You mentioned spanning-tree and totally triggered something inside of me. I didn’t do the CCENT, I did the full CCNA exam -> But I remember STP being so utterly complicated & convoluted that it was impossible at that level (of just being thrown into such complexities) to actually understand how to implement spanning-tree effectively. It was only when I made it to the NP level was I actually able to understand why and how STP worked. The realities of STP are that it is complex, however, it’s easy to not make it complex and plan for how secondary root bridges would take over and predict where blocked ports are going to be, etc.

      In fact, on Cisco’s website, there’s “recipes” if you will, for proper implementation of spanning-tree in different network designs and topologies.

      I guess what I’m saying is, for me at least, spanning-tree was more complicated at the NA level than at the NP level.

  6. says

    Good, timely information. As I posed to Twitter the other day, our technical interviews have typically been of the trivia quiz-show variety and it’s not been successful in learning whether a candidate really has real world skills. Candidates that have done pretty well at trivia have crashed and burned when they get on real customer networks.

    I always go after things on the resume, especially long lists of hardware models or the “fit every routing protocol in here” portion. If you’re going to have products and technologies on your resume, your experience with them better be beyond “we had one in the data center and one time I plugged a new cable into it.”

    I’m still kicking the idea of a short hands-on lab around, too. Solid design, theory, and communication skills are all very important but there’s also a point where the rubber meets the road and especially as a consultant sometimes you really do have to sit down in front of someone who is watching you carefully and troubleshoot a weird spanning tree topology or modify a BGP policy to advertise another prefix or expand a LAN-to-LAN VPN tunnel safely.

    Thanks for the additional screening ideas. I’m shamelessly stealing them. :-)

  7. MDG says

    Hi Ethan,

    Just wanted to let you know that this is very useful. I can think of some really interesting tasks to do on our network.

    P.S. Comments do not show up on on Mac OS X latest Safari, though on Opera it is fine.

  8. ktokash says

    I do the first question every time, I call it “the life of a packet.” I want to see them trace a packet entering the network all the way to whatever service they offer, and back again. That forces a diagram, well that and me handing them a marker while I ask, and we stop at every interface on the way. Is there load balancing? Where does it go from here? How does it know? What protocols? Any segregation at L2 or 3 here? A senior neteng that worked on the same network for a year+ should say logical things with confidence, and answer followup questions without trouble.

    The other one I like is something Jeff Doyle recommended on a blog years ago – why do you need to connect all areas to area 0? My experience is that every CCIE I’ve asked knows this one, and not one non-CCIE does. Obviously that doesn’t mean they can’t, but the overwhelming norm in OSPF is to get it working and stop asking questions. The answer I’m looking for is link-state vs distance vector, not, “because it won’t work otherwise.”

    • Evol Syawla says

      I know this may bust your bubble, but it seems like you and the people you have interviewed and asked this question need to update your information. I love those kinds of questions. So the first thing I would say is that “You do not have to connect all areas to Area 0. And watch your eyes pop out. And then tell you, in fact you do not have to have an area 0. And I will let you ask me to explain and I would. If you have a single area, it can be any 32 bit number. If you have 2 areas, they can be any 32 bit number. Only when you have more than three areas is there a requirement for Area 0. And that is because the loop mechanism kicks in and you will lose connectivity to the area not connected to Area 0 (backbone). You see the ABR connected to Area 0, will stilI get the Type 3 LSAs form the area not attached to Area 0, but they will only remain in the LS db and not used in the calculation. I always like to see the perplexity on engineers faces when you inform them that what you thought you knew does not work quite that way. Truthfully, I prefer these kinds of questions which test your ability to think and apply the knowledge, rather than those old tired questions. It can be a double edged sword. I remember one interview did and was asked a question and I gave the answer. The interviewer, a Net engineer informed me that I was wrong. I smiled because I just did exactly what he had asked me about, the very night before the interview so I knew it could work. So I said, well, maybe something went wrong, and I further explained what I did and why it worked. He then called another person and he said I was right. I understand, I thought X was the case for years until I learned otherwise that it is actually Y on some other issue. I did not get the job.

      • says

        Are you sure about this statement:
        “If you have 2 areas, they can be any 32 bit number”

        It doesn’t seem to be true for IOS.

        Consider this simple network.

        R1 R2 R3

        I put a loopback interface on R1 and R3. On R1, I put all interfaces (including the loopback) into area 12. On R3, I put all areas (including lo0) into area 23.

        On R2, I put the interface facing R2 into area 12. Once that’s done, the neighbor relationship is formed, and R2 gets an OSPF route for R1’s loopback. Now I put the interface facing R3 into area 23. Again, neighbors form, and R2 sees the route for R3’s loopback. R2 now has all expected OSPF routes.

        BUT: R1 does not see any OSPF routes, nor does R3. R2 does not pass the routes between the non-backbone areas.

        In order to get R2 to pass routes between the areas, I need to put R2’s loopback into area 0. Then it considers itself an ABR, and it passes the routes through.

        The interesting thing is that JunOS behaves differently in this regard – see Marko’s blog for more on this – he covers all the configs and outputs:

        One interesting point is that it’s a bit precarious if you do this with JunOS – adding any other interfaces to area 0 later will break it.

    • Andrewmag166 says

      In general I think people that give interviews get caught up in their own ego (I know because I have done it). They think they are better and more knowledgeable by far than the person they interview. Often they spend weeks or months making questions they couldn’t answer themselves in an hour and they came up with the questions but somehow they expect this guy to answer them like a machine. Also I have interviewed and the interviewer didn’t know the right answer when I gave it to them, if guys keep giving you a different answer than you think is right, maybe you should read through it again, isn’t your boss starting to wonder how its possible you reject everyone and you are the only one on Earth that knows anything? Some questions are good just to see how they respond under pressure but I think its more important to look at accomplishments. Degrees, Grades, Certs, Experience, Passion, willingness to jump in work and learn and most important can you work with this guy. Just my two cents after 25 years engineering I know no one can know it all. And maybe its better they know the things I don’t know and don’t ask about, then for the company to have another carbon copy of me.

      • Michael says

        Couldn’t have said that better myself. Unfortunately you just have to take those sorts of interviews on the chin – they happen. Luckily it also gives you an idea of what they might be like to work with so no big deal, If I aced an interview like that I would still turn the job down. I have some friends in networking that are like that and they have casually tried to be clever and ask me about ISAKMP or something, only to explain it and then find out they themselves knew nothing about it.

        I am interviewing at CCNP level for the first time having had only one CCNA level job after leaving uni, and I have to say the majority of questions are really rather simple and require a technical overview (spoken in laymans terms). What is routing? Explain the difference between a hub and a switch, what is HSRP. Explain how ARP works (Rather how does host A communicate to host B). Some of these caught me off guard to begin with.

        Ive had a scenario – where I had a list of switches and hardware etc and been told to draw it out, explain things, thought that was quite good.

  9. layer4down says

    Hi Ethan,

    I thought these were great questions and I’m glad to see that we’re promoting a more comprehensive and creative interview style.

    In my opinion, however, if I had to answer question # 4 in an interview, I might just respond with “it depends”. Although I (and I presume most NEs) am perfectly capable of sinking some cycles into trawling Google and our local knowledge bases, there are times when this is less practical (or even less preferential). There have been many occasions where I may have spent 30 minutes, or even several hours, trying to research a matter which another engineer was able to answer in just a few minutes. Invariably, they follow with,”Well why didn’t you just ask me?”, in addition to sensing some occasionally awkward feelings of inadequacy on their part. I would opine that part of being a team player is being able to gauge and understand our team members. Although you certainly don’t need to live at their desk, asking input from your peers exhibits a level of humility and maturity on your part, showing that you’re not only teachable and approachable, but that you trust and are interested in the input offered by your peers. I find it is a careful balance between managing autonomy and massaging a few egos which can help to build the best strategic bridges (particularly in our line of work, lol). Just my thoughts. Great article!

  10. Nishikant Shirke says

    Hiii I have completed BE in Computer Engineering.I am fresher searching job in networking field for post of Network Engineer or System Engineer . What will I have to do? I dont have CCNA certificate.Plz give me some guidance for that…….!!!!

  11. Luke Filewalker says

    Ideal answer to # 4:
    First, I would get to know my team. Some teams I’ve worked with love team interaction that comes with answering questions and providing general assistance. Some teams prefer that you seek the answer out yourself first, even if it takes hours to find the answer as opposed to the few minutes it takes to ask someone a question. That said, I love figuring things out for myself and I stick to it until I find a complete solution–then I make sure to document that solution. If I am on a team that is open to collaboration, then I’m OK with asking around first to save myself and the company time. Of course I would never take the few minutes to ask someone a question that can be answered with an equal amount of thought or research. That’s just lazy!


    I’ve been a network engineer for 15 years, and though I think your questions are great, some of the examples you give do come across as unimportant minutia. First Hop redunancy protocol? OSPF? Are you looking for someone to design the Internet?

    I’ve had those trivia interviews, and they are the WORST.

Leave a Reply

Your email address will not be published. Required fields are marked *