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.
About Ethan Banks
