4 Must-Ask Interview Questions for Network Engineers
October 10, 2012
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.
- Smarter Process: Five Ways to Make Your Day-to-Day Operations Better, Faster and More Measurable
- Solving Big Data Challenges with Simplicity & Speed
- Approaches to DDoS Protection: An Overview on Keeping Your Networks Protected
- Top 8 Considerations To Enable and Simplify Mobility
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.
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