I have several friends with either photographic, or near photographic, memories. For instance, I work with someone (on the philosophical side of my life) who is just astounding in this respect. If you walk into his office and ask about some concept you’ve just run across, no matter how esoteric, he can give you a rundown of every major book in the field covering the topic, important articles from several journals, and even book chapters that are germane and important. I’ve actually had him point me to the text of a footnote when I asked about a specific concept.
It seems, to me, that the networking industry often focuses on this sort of thing. Quick, can you name the types of line cards available for the Plutobarb CNX1000, how many of each you can put in the chassis, what the backplane speed is, and what the command is to configure OSPF type 3 filters on Tuesdays between three and four o’clock? When we hit this sort of question, and can’t answer it, people look at us like we’re silly or something.
I know, because I’ve been there. I’ve had people ask me the strangest questions in interviews, such as how many spine and leaf boxes it would take to support a specific number of edge ports given a specific set of boxes (sorry folks, I can’t work it out in my head, I need a calculator and hopefully a white board), how many subnets are there in a /22 (these I can calculate in my head for v4, and I’m trying to get to the point of being able to do it in v6), how to configure a specific feature on three different boxes, and a few other odds and ends. In fact, the majority of the interviews I’ve been involved in, across my career, have involved at least one person asking me these sorts of questions.
Most of the time, the answer I really want to blurt out is, “I don’t care.” Most of the time, I don’t. I did, one time, challenge the interviewer to an esoteric match, though. I was asked about something odd to which I didn’t know the answer, so I answered, “I’ll make a deal with you — for every esoteric question you ask, I get to ask one back. If I stump you more than you stump me, I pass the interview. Deal?”
I think I understand why we do this — one of the first temptations of the teacher is to ask questions that are easy to grade, rather than questions that actually cover the required material.
But I also think we need to think more about what we’re trying to build as an engineering community. Should we memorize more, or think more? I know, to some degree, that this is a false dichotomy; you can’t think without something to think about. Memorization is a critical skill. Even as a PhD student in a philosophy program I need to memorize things (in fact, lots of things). If I don’t memorize the author’s line of argument in a text we’re studying, for instance, I’m pretty useless in class discussion.
There needs to be a balance here, though. The question is — how do we reach the balance? What does that balance look like? Of course, the balance isn’t going to be the same for everyone, and every position. Sometimes you just have to develop a habit of actions that will serve you well in times of crisis, for instance. But other times you don’t. How do you know? I have some suggestions here, but feel free to add more in the comments. My suggestions are…
First, ask why do I care? If the job is in a NOC, and the candidate is going to be troubleshooting OSPF adjacency problems at 2AM, they probably need to know the OSPF adjacency process, including things like what multicast addresses OSPF uses for particular reasons, the stages of the process, etc., very well. So first, know what they need to know.
Second, ask how should I ask this? If you’re asking about troubleshooting OSPF adjacencies, do you ask what commands you would use to troubleshoot an OSPF adjacency problem? Or do you ask what the stages of an OSPF adjacency are (in detail)? Or do you set up a broken adjacency and ask the candidate to mock up fixing it? Each of these tries to get to the same information, but in different ways. Which one makes the most sense for your environment? And which one asks more for thinking skills rather than memorization skills?
Let me try to encapsulate these two into a simpler form, though.
What would you allow someone to search for during an interview?
Command line information? Protocol operation details? Protocol operation theory? Or nothing?