Networking Interviews – How to Ask Good Questions

I’m not sure if it’s just us in networking/IT, or people leading interviews in general (probably the latter), but we have a tendency to ask really bad questions in interviews. Often the questions revolve around factoids or things that need to be memorized. Some interviewers will even intentionally try to “trick” you. This is a really bad way of conducting an interview and will guaranteed lead to poor results. Instead of asking someone to quote an RFC, you should focus on asking open-ended questions and even guide the candidate if they are getting stuck on something. Why?

Reasoning – You want to see how people reason their way to answering a question. What is their thought process? Asking the administrative distance of BGP will just give you back a one-sentence answer or no answer at all. You can learn much more about someone’s skill level if you give them some clues and see if they can take the discussion forward. Are they comfortable asking you for input? Are they comfortable saying that they don’t know something?

Remove tension – Most, if not all, people are somewhat nervous when being interviewed. You want get an accurate representation of their skill so you want them to feel comfortable. That doesn’t mean you can’t discuss tough technical topics but you don’t want to have a super qualified candidate bomb the interview because they were too nervous. The goal should be to have them perform at their best, right?

Design – When you ask open-ended questions, you can add details or describe scenarios and see if they can design and tell you the impact of different choices. Would you add a firewall here? Why or why not? There’s no one correct answer but you want to see if they can piece things together. Someone can be really knowledgeable and recite RFC 2328 by heart but do they know how to put the pieces together?

Troubleshooting – Does the person have troubleshooting skills? How about asking them a scenario you ran into? Give them some hints and see what their troubleshooting process is. It’s not about only finding the answer but rather getting them to ask questions that would take the troubleshooting forward. Give them some hints if needed.

What are then good questions to ask in an interview? Let me give you some examples.

Traceroute – Traceroute?! How much can you learn from asking someone about traceroute? A lot. Do they know that some operating systems use UDP while others use ICMP? Do they know about port numbers? Can they describe how TTL works? Why do you sometimes see asterisks in the traceroute? What does the latency reported tell you about the path? Is the path that traceroute shows you representative for other data packets? Do they know that you can traceroute with TCP? How is running a traceroute with UDP or TCP different than ICMP? What does traceroute tell you about the return path? The goal here is not to have them recite everything they know but rather tell them a story and ask questions along the way.

Browsing the internet – This is a question that can get super detailed with probably hundreds of steps. How detailed knowledge do they have? Start a story that you are sitting on a client and want to browse something on the internet. Do they know about DNS? Can they give an overview of the DNS process? If something is in the cache or not. Do they know about root servers? Can they describe how a packet travels the network through switches, routers, firewalls? Do they know about NAT? MTU? Do they have any knowledge of BGP and Anycast? You could probably spend an entire interview just on this question.

Switching – Why do we need something like STP in L2-based networks? What happens if we don’t run STP? Can they describe a bridging loop? Why do frames keep looping? How do switches know where to forward frames? What do switches do with broadcast, unknown unicast and multicast frames?

Routing – Can they describe how a router knows where to forward a packet? Do they know about RIB and FIB? How does a router select between two routes that are equally long? Do they know about ECMP? Can they describe longest prefix match?

BGP – Rather than asking ridiculous questions on what attributes are mandatory or not, describe a BGP scenario. Can they tell you different options for trying to influence traffic inbound and outbound? Have they heard of communities? What happens if someone ignores your attempts at influence traffic? Is it possible to hijack prefixes on the internet?

OSPF – Why do we need area 0? Can they briefly describe how a link state protocol works? Why do we need a LSDB? What are different ways of reducing the number of LSAs in an area? What tools are available to increase the stability and have less SPF calculations?

I hope I made it clear that these questions should not be asked like “Tell me everything you know about OSPF”. Rather, walk them through a scenario. Tell them of a problem you are trying to solve or how you are trying to make a design more optimal. By giving the candidate hints you can move the discussion forward and learn a lot about them. Doing an interview in this style will tell you a lot more about someone than just asking questions where there is a single answer.

I hope we can provide better interviews in the future! Let me know if you have any feedback.