4 Must-Ask Interview Questions for Network Engineers

I enjoy being on an interview panel for networking candidates. My job is usually to be the technical heavy. I need to determine what the candidate knows, what the candidate doesn't know, and what I think he or she could figure out. I rely on four questions to get at this information. But first, here are some things I don't spend time on.

Trivia. I rarely get into a trivia competition with a candidate because it proves very little. If candidates recently passed a certification exam, they might have a head full of arcane networking facts, but what's really important is what they can do with their knowledge. A trivia contest won't tell you that.

Tell me about your ideal job. I don't care about this one, either. The ideal job doesn't exist, so if candidates want to work in the tree where the elves make cookies, they're going to be disappointed. Besides, candidates might feel pressured to answer with words they think you want to hear, which makes it a pointless exercise.

Are you a team player? This is a silly question. Of course they'll say yes, no matter the reality. I honestly don't care if they work by themselves as long as they follow standard procedure and do what's been asked of them.

And now, here are four questions that I have asked.

1. Can you 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 clear the network was in the candidate's mind, and the way that he or she 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.

interop-las-vegas-small-logo.jpg

Hear more from Ethan Banks live and in person at the Future of Networking Summit presented by Packet Pushers at Interop Las Vegas, May 2-6. Register now!

How well does the candidate explain the diagram? This is where it gets interesting, because as the explanation moves forward, you can 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.

The diagram lets you explore the candidate's knowledge. It's a fair question even for entry- and mid-level candidates. If an entry-level candidate draws one switch and then shrugs his shoulders apologetically, you can find out how well he knows that switch. Did you provision ports? What did the standard switch port template look like? Why was command X used? What did you do to stop CDP advertisements from leaving unused ports? And so on.

Next: More Questions

2. Your resume says that you worked with BGP. What can you tell me about that? Lift a skill 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 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. Chances are, you don't know everything there is to know. The point is to see just how much they know, and determine 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. What are the steps you would take to discover the network topology? This is a loaded question. Practically speaking, there's a limited amount of network that can be discovered if it's even vaguely secure, but an engineer who has been around the block should be able to come up with multiple answers. For instance, run a ping sweep against a range of addresses. Run a packet analyzer and see what sorts of broadcast frames come across the wire. Run a MAC flooding tool to get the switch to dump all traffic to their port through unicast flooding, and see what they can pick up from that.

I could go on, but the idea with a question like this is to answer it yourself ahead of time, then see what the candidate comes up with. As they make their suggestions, you can probe them. Oh, so you'd try to get a DNS zone transfer. 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 candidates explain 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 for more about that.) 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. How do you find answers when you don't have them? You want to learn one thing from this question: Whether 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, and so on. The last thing they should say they will do is come to you. If they do say that, they should add that they would come 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 candidates 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. Such a candidate will probably be a great asset.