Memorize — or Think?
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.
Right?
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?
Good points Russ. I hate esoteric questions, they don’t tell you if the person really understands the fundamentals or not and that’s why I don’t ask them any more. Personally I prefer to zoom out and ask “how and why” questions rather than “what” questions. So instead of asking “what is the default BGP keepalive timer”, I would ask “how does BGP detect link failures” or maybe “How does BGP prevent routing loops”. Anybody who read a CCNA book (and maybe not even touched a router before) could tell you what the default timers are but only people who understand BGP and have operational experience would know how it converges and prevents loops.
I don’t have a problem if people want to look up commands during an interview as I don’t expect them to remember each command out there but certainly not protocol operation theory or perhaps details
Thanks for stopping by — I tend to ask “why” rather than “what” questions, as well, as I tend towards “think” rather than “memorize.” I can understand, though, why memorize is important in many situations, particularly when you need to act fast.
Great point Russ! I often run into this type of thing during interviews, and it makes me want to get up and walk out. I especially ‘love’ the opinion based questions, and get told I am wrong.
I was recently applying for an EA position for a company based here in San Francisco. The UC Architect asked me “What do you think of QOS in the campus environment, and what method of QOS would you use”. My answer “Without further information, I prefer to keep this as simple as possible. In a campus environment, typically very high speed links are used, and contention is most likely not an issue. A Simple QOS policy ensures low level engineers can stand up new sites, troubleshoot at 2AM, as well as a host of other reasons. Barring and complications, I’d just use Auto-QOS in the campus, marking traffic as trusted – especially in an all cisco environment, and apply policy at the edge.”
His reponse “Wrong. Absolutely wrong. We have interviewed many architects, and you are the first that believes in Auto-QOS.”
I did not get an offer. LoL.
Sometimes the problem is we have our egos invested in a carefully crafted solution, and don’t want to hear that we’re wrong from an interview candidate — but that’s another post. 🙂 Great story… Thanks for stopping by!
🙂
Russ
Wasn’t it Albert Einstein who said “Never memorise something that you can look up.”? I agree that during certain situations you have no option but to memorise some facts, i.e. default values, protocol numbers/ports and etc. prior an exam for instance. Ideally though you would have memorised these as a result of your extensive experience on the matter which you have come across numerous times during your career that it just got burned into your brain. I think “how and why” type of questions tend to add more value overall.
Also, let’s say you ask two candidates a few “what” type of questions on a particular subject/technology and both manage to answer them correctly. Who knows more about about the given subject/technology? Well, as far as you know both are equal. However, a few simple “how and why, tell me more about” type of questions would within seconds at times show you who really knows their stuff.
Having said that, I believe that answering “what” questions normally shows what you committed to memory, be that short or long term which obviously vary per individual, whereas “how and why” demonstrates knowledge and understanding often acquired by experience.
I once heard a story about Einstein — I don’t know if it’s true, but it illustrates the point nicely. Einstein was once asked what his phone number was — he found a phone book and looked it up. When queried, he replied: “I don’t call my phone number, why would I want to memorize it?” It seems, to me, that some of this comes down to time. What should you take the time to memorize, versus what should you take the time to understand? There’s no clear answer in every situation, but we should choose to use our time wisely. 🙂