Interviewing for the Engineering Mindset

Russ White recently wrote about IT skills and the need to be more valuable to the business. He also touches on something he’s spilled a lot of ink on in the past: Good engineers think like engineers, not just know all of the commands.

I frequently hear people complain about network engineer interviews that play out like CCIE exams. Random questions like “What does the PSH flag in TCP do”? Or “What commands are required to enable $feature”.

But at the same time interviewers feel at a loss on how to ask questions of candidates that truly tease out their skills and ability to think through problems without absurd scenarios like “How many ping pong balls fit in a 747?”

When I was working in the Cisco support organization the most valuable skill we could have was someone that could think through problems. So many different technologies were supported, at such a deep level, no candidate knew all of them.

I didn’t need a BGP expert, I needed someone that could figure out how to become a BGP expert.

In the hundreds of interviews I’ve done as an interviewer the technique I developed was two part:

1.) Make the candidate comfortable. Interview is everyone’s least favorite activity. If you are between jobs and are feeling desperate to get work things become even worse. The less comfortable a candidate is the less real the perception of that individual you are going to get.

2.) Ask questions they have a chance to answer. This indirectly relates to the first point, but you are wasting your time and the time of the candidate if you simply drill questions that the candidate doesn’t know or isn’t familiar with. Don’t just find a weak spot on the candidate’s resume and hammer on it. If someone says they aren’t strong in a technology area, don’t be surprised when they don’t impress you when pressed on that area.

The way I’ve tried to address these two points while looking for an engineering mindset was to specifically ask candidates where they felt the strongest. BGP? OSPF? EIGRP? Multicast? It’s up to the candidate. Let’s find an area where they are confident in their knowledge and work in that area. Ask both fundamental questions like “How does BGP prevent loops?” as well as scenarios that make sure someone can think through the operations of a technology, like “Walk through the loss of a route and how a new best path will be selected”.

The key, particularly for the scenario question, is that the specific answer is less important than how they got there. As long as the candidate’s answer is based on sound logic I won’t hold it against the candidate for being wrong. If the candidate is missing some fact to move forward or can’t remember the specific order of BGP path selection, give it to them. These are things that they would Google in 30 seconds on the job. What you can’t google, is an ability to reason and logically work through difficult problems. 


When you interview candidates the basic skills to do the job are fair game. If you are an OSPF shop and the candidate has no OSPF experience the curve may be too steep. But if they can’t tell you when the M-bit is set, is that really a show stopper? Would you pass up a candidate that can logically walk through a route exchange and say “one of the routers has to start the process. I guess it’s the highest IP address?” because they didn’t recently study the packet format to know the M-bit even exists?

Talk to candidates as stressed out humans. Try to put them at ease and look for engineering skills, not just the rote memorizers. Every engineer will eventually run into a problem they haven’t studied for. With the memorizer how do we think that story ends?


5 thoughts on “Interviewing for the Engineering Mindset

  1. Thank you so much for this article, I agree with many of your points. To me, the best engineer is one who knows his strengths but more importantly, knows his weaknesses and is willing to put in the time to improve on all aspects of his skills. Technical skills are not the only thing that makes a good engineer, communication, a willingness to work with others and to do so well, knowing how to accept criticism and improve from it…all of these make not only a great engineer, but a great employee.


  2. I agree that technical trivia pop quizzes are unfruitful in the interview process for engineers. Candidates need to be able to demonstrate understanding and the ability to think analytically — both of those are much more important than remembering all the little details, and so when interviewing candidates I care a lot more about how they think and whether or not they understand the big picture then all the details of their answers.

    At the same time, candidates do need to convince me that they have the specific technical knowledge and skills required for a job, and I like to see that they know some area well enough to go into good detail about it. The best engineering candidates know at least *something* very well indeed, and they also demonstrate good analytical skills when pushed outside the area(s) of their expertise.

    If a mid-career engineering candidate hasn’t mastered something related to their field well enough to talk about it in great detail, I tend to doubt that they have the passion required to be an exceptional, high-performing engineer. They don’t need to know everything about everything — none of us can do that — but knowing a lot about something is an indicator of technical passion that is a good predictor of future success.


  3. Thank Pete for your great blog ! I started following you after watching your “IOS routing internal” presentation at Cisco Live, which is very useful and informative. Though I think I now have a clearer understanding of what is process switching and what is CEF switching, there’s still a little confusion which I need your help to clarify (sorry for asking unrelated questions at this post, but I found no suitable article to put it):

    In some books, they said FIB and Adjacency table make CEF (or CEF contains FIB and Adjacency table). But in your presentation, Routing table and Adjacency table make FIB, and FIB is equal to CEF. So what is the right definition?

    Thank you very much for your help, and keep up the good work !
    Hoang Tran


  4. @Hoan – I think some of what you are seeing is just the authors trying to simplify the concepts, not being inaccurate.

    In general you have four pieces:
    Adjacency Table that provides Layer 2 to Layer 3 mapping. This would be IPv4 ARP, IPv6 Neighbor Table, Frame Relay Mappings.

    Routing Table – The list of layer 3 routes/next hops. This is also called the FIB.

    CEF table – combination of Routing/FIB table and Adjacency table. This table lives within software/memory. This table is used to program any hardware forwarding engines.

    Hardware CEF table – This is what lives within the hardware/ASIC. It should be the same as the software CEF table, but it is possible, due to software bugs, to differ.

    Hopefully that answers the question.

    Liked by 1 person

  5. Great points. However, I’ve had a lot of problems with softballs – stp, ospf & bgp.

    “Give me a general explanation of the spanning tree election process.”
    “How is an OSPF neighborship formed?”
    “What are the states BGP neighbors will go through?”

    Will test for depth if the candidate spills protocol soup all over their resume, and oftentimes will find myself disappointed. Under duress, these candidates will go to great lengths to explain what they’re configuring – but not why their configuring it a certain way.

    Recently had a candidate tout his experience in financials, where he won an award for designing a low latency colo with Nexus gear. But he couldn’t break down the workflows or the workload and give me rough order estimates on north-south & east-west traffic.

    We had one who came in after a really crisp phone screen, and couldn’t pass a practicals to save his life … simple stuff like mismatched ASN, 30 minutes to solve.

    These are all applicants with CCIEs. I can quote most of the above off top of my head – stp, ospf, bgp, Nexus card/platform latency … and I’ve never gone after a certification in my life!

    Your post edges around what the best mark of a network engineer is – the ability to walk states and determine outcomes. Have a handful of guys on with the talent; hopefully hiring more soon.

    Bonus points if you can break down power & cooling and break down RoMs for gear.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s