Cultivate questions

Imagine that you’re sitting in a room interviewing a potential candidate for a position on your team. It’s not too hard to imagine, right, because it happens all the time. You know the next question I’m going to ask: what questions will you ask this candidate? I know a lot of people who have “set questions” they use to evaluate a candidate, such as “what is the OSPF type four for,” or “why do some states in the BGP peering session not have corresponding packets?” Since I’ve worked on certifications in the past (like the CCDE), I understand the value of these sorts of questions. They pinpoint the set and scope of the candidate’s knowledge, and they’re easy to grade. But is easy to grade what we should really be after?

Let me expand the scope a little: isn’t this the way we see our own careers? The engineer with the most bits of knowledge stuffed away when they die wins? I probably need to make a sign that says that, actually, just to highlight the humor of such a thought.

The problem is it simply isn’t a good way to measure an engineer, including the engineer reading this post (you). For one thing, as Ethan so eloquently pointed out this week—

The future of IT is not compatible with a network that waits for a human to make a change in accordance with a complex process that takes weeks. And thus it is that the future of networking becomes important. Yes, we grumpy old network engineers know how to build networks in a reliable, predictable way. But that presumes a reliable, predictable demand from business that just isn’t so in many cases.

The question becomes: how do we cultivate this culture among network engineers? It’s nice enough to say, but what do I do? I’m going to make a simple suggestion. Perhaps, in fact, it’s too simple. But it’s worth a try.

Instead of cultivating knowledge, cultivate questions.

Let’s take my current series on security BGP as an example. In part two of the series, from last week, I pointed out that it’s a long slog through the world of security for BGP. You have to ask a lot of questions, beginning with one that doesn’t even seem to make sense: what can I actually secure? Cultivating question asking is important because it helps us to actually feel our way around the problem at hand, understanding it better, and finding new ways to solve it.

Okay, so given we want to encourage engineers to ask more questions—that networks must change, now—and the path to changing networks is changing engineers, what do we do?

First, we need to rethink our certifications around cultivating questions. I think we did a pretty good job with the CCDE here, but the concept of asking if the candidate understands the right question to ask at any given phase of the process is an important skill to measure. I haven’t taken a CCIE lab since 1997, but I remember my proctor asking me if I knew what I was looking for at various times—he was trying to make certain I knew what questions to ask.

Second, we need to start thinking in models, rather than in technologies. I’ve written a lot about this; there’s an entire chapter on models in The Art of Network Architecture, and more on models in Navigating Network Complexity, but we really need to start thinking about why rather than how more often. Why do you think I talk about this stuff so often? It’s not because I don’t know the inner guts of IS-IS (I have an upcoming video series on this being published by Cisco Press), but because I think the ability to turn models and networks into questions is more important than knowing the guts of any particular protocol.

Third, we need to follow Ethan’s lead and start thinking about a broader set of skills and technology.

Finally, maybe—just maybe—we need to start setting up interviews so we can find out if the candidate knows the right questions, rather than focusing on the esoteric game, and whether or not they know all the right answers.


  1. Kevin Myers on 8 February 2016 at 12:35 pm

    Completely agree with you that we are guilty of imposing trivial pursuit: network edition on interview candidates. One of the most enlightening questions i’ve asked in technical interviews is: “what is your favorite routing protocol and why?” There isn’t a wrong answer, but the way in which it is answered will tell you a lot about the candidate. Good stuff…

    • Russ on 10 February 2016 at 12:37 am

      I really like that question, actually — especially because there are so many good answers, and no right one, and so many opportunities to ask good questions to clarify. Thanks for stopping by!



  2. alan.wijntje on 10 February 2016 at 3:58 am

    He Russ,

    great post and I fully agree, testing knowledge is good but within reason and not as Kevin noted as a game of trivial pursuit (slightly exaggerated but if this is your best method of selecting candidates, you could get your job-applicants play network-trivial pursuit and just hire the winner and save everyone some time!?).

    Asking questions is the basis for learning in my opinion and we should never shy away from asking questions.
    Thinking back to an article you wrote earlier about teaching, questions should guide teachers (mentors, senior engineer, architects etc) and we should encourage them as much as possible (as you can go from the role teacher to student in the blink of an eye).

    And while I know people tend to be careful when asking questions (especially in groups) as they might think others would perceive it as a dumb question this should never hold us back (in this light I’m not afraid to ask what the answer is to the BGP peering session question as I have really no idea?).



    • Russ on 10 February 2016 at 7:05 pm

      Thanks for the comments Alan — I know it’s hard sometimes, but I try to never, ever treat a question as a “dumb question,” or let someone asking questions irritate me. OTOH, the more we’re “metacognitive” about what we’re asking, the better formed questions we ask, the more we’re going to learn.