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. 

Takeaway

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?