We all have weaknesses, and one of mine is that I’m good at starting things and bad at finishing them.  Two years ago (gasp) I had started writing a series about technical interviewing.  I wrote two posts (here and here) on the subject and never finished.  A recent commenter asked for me to keep writing on the subject, so here goes.

Whenever we, as hiring managers, post a job, we have a specific idea in mind of what the ideal candidate would look like.  We are looking for a combination of skills, personality, experience, and credentials.  The fact of the matter is, we can create an ideal candidate in our head, but that person does not exist.  We will never hire this fictional person, so we have to look for the closest match.  We need to decide which of these skills, credentials, etc., we are willing to compromise on, and which are non-negotiable.  Historically, the process for deciding the match used two pieces of input:  the resume (or CV) and the interview.  The resume provides a rough view of how close the candidate is to the ideal, whereas the interview allows the hiring team to explore more deeply the closeness of the match.  I said “historically” because I’ve seen some companies using newer techniques, such as administering programming tests.  I’ll leave these newer techniques aside to focus on the interview.

The interview is an attempt to evaluate the candidate’s “fit” by asking questions of the candidate.  The largest part of this effort is trying to understand if the candidate’s skills fit with the skills we believe are required for the job.  A secondary part of the interview is assessing the candidate’s personality and “soft” skills.

How do we assess technical skill?  Let’s say the job we are hiring for is a low-level network engineer.  We need someone who has basic skills in configuring Cisco switches, routers, and wireless.  We want someone with a basic understanding of TCP/IP, IOS-XE, NX-OS, routing protocols like EIGRP and OSPF.  Often all these will be listed at the top of the candidate’s resume.  But anyone can put anything in the alphabet soup.  The interview is our chance to determine whether the alphabet soup is true.  (Hint:  DO NOT put anything in your resume you are not comfortable talking about.)  There are generally two ways of doing this.  First, we can assess the candidate’s hands-on experience with these technologies.  We can use questions like:

  • Did you work with EIGRP in your last job?  If so what did you do with it?
  • How much hands-on experience do you have with NXOS?  Tell me the environment where you configured it and what specifically you did.

In this case, I’m trying to understand whether you’ve worked with the technologies and how much you have worked with them.  You might claim experience with NXOS, but you only looked at “show interface” outputs in your last job.

The other way I can assess technical skill is by asking theoretical questions about the technologies in question.  For EIGRP, for example:

  • Can you tell me all the different components of the EIGRP metric and which are the defaults?
  • What is an EIGRP SIA condition and how would you go about resolving it?

Any skill is a combination of theory and practice.  If you don’t understand the theory behind a wing stall in an airplane, you won’t be able to resolve it, but if you don’t go out and do stall practice in the airplane, you also won’t be able to resolve it.  Most interviewers will use a combination of these techniques to assess your competency.

Another technique is to provide a theoretical scenario.  I can get up on the whiteboard and draw a bunch of OSPF areas with different types and ask you how routing would work between them.

As an interviewer, I now need to think about your answers and how they align with what I’m expecting.  What if you know a lot of EIGRP theory, but you’ve never configured it in the real world?  What if you know a lot about switching and routing but nothing about wireless?  And, most importantly, how do you compare to the other candidates I’ve interviewed?  The other strong candidate might know a ton about wireless and nothing about routing.  I also have to consider whether I want a “ready-made” engineer who can just walk in and start working, and how willing I am to provide ramp time to the hire.  If you know you’re stuff in routing and switching, but don’t understand wireless, I might assume your overall technical competency will enable you to learn wireless with relative ease.

How effective are these techniques?  Well, if I remember to continue with this series, I’ll discuss it in the next article.

In the last article on technical interviewing, I told the story of how I got my first networking job.  The interview was chaotic and unorganized, and resulted in me getting the job and being quite successful.  In this post, I’d like to start with a very basic question:  Why is it that we interview job candidates in first place?

This may seem like an obvious question, but if you think about it face-to-face interviewing is not necessarily the best way to assess a candidate for a networking position.  To evaluate their technical credentials, why don’t we administer a test? Or, force network engineering candidates to configure a small network? (Some places do!)  What exactly is it that we hope to achieve by sitting down for an hour and talking to this person face-to-face?

Interviewing is fundamentally a subjective process.  Even when an interviewer attempts to bring objectivity to the interview by, say, asking right/wrong questions, interviews are just not structured as objective tests.  The interviewer feedback is usually derived from gut reactions and feelings as much as it is from any objective criteria.  The interviewer has a narrow window into the candidate’s personality and achievements, and frequently an interviewer will make an incorrect assessment in either direction:

  • By turning down a candidate who is qualified for the job.  When I worked at TAC, I remember declining a candidate who didn’t answer some questions about OSPF correctly.  Because he was a friend of a TAC engineer, he got a second chance and did better in his second interview.  He got hired and was quite successful.
  • By hiring a candidate who is unqualified for the job.  This happens all the time.  We pass people through interviews who end up being terrible at the job.  Sometimes we just assess their personality wrong and they end up being complete jerks.  Sometimes, they knew enough technical material to skate through the interview.

Having interviewed hundreds of people in my career, I think I’m a very good judge of people.  I was on the interview team for TAC, and everyone we hired was a successful engineer.  Every TME I’ve hired as a manager has been top notch.  That said, it’s tricky to assess someone in such a short amount of time. As the interviewee, you need to remember that you only have an hour or so to convince this person you are any good, and one misplaced comment could torpedo you unfairly.

I remember when I interviewed for the TME job here at Cisco.  I did really well, and had one final interview with the SVP at the time.  He was very personable, and I felt at ease with him.  He asked me for my proudest accomplishment in my career.  I mentioned how I had hated TAC when I started, but I managed to persevere and left TAC well respected and successful.  He looked at my quizzically.  I realized it was a stupid answer.  I was interviewing for a director-level position.  He wanted to hear some initiative and drive, not that I stuck it out at a crappy job.  I should have told him about how I started the Juniper on Juniper project, for example.  Luckily I got through but that one answer gave him an impression that took me down a bit.

When you are interviewing, you really need to think about the impression you create.  You need empathy.  You need to feel how your interviewer feels, or at least be self-aware enough to know the impression you are creating.  That’s because this is a subjective process.

I remember a couple of years back I was interviewing a candidate for an open position.I asked him why he was interested in the job. The candidate proceeded to give me a depressing account of how bad things were in his current job.”It’s miserable here,” he said.  “Nobody’s going anywhere in his job.  I don’t like the team they’re not motivated.”  And so forth.  He claimed he had programming capabilities and so I asked him what his favorite programming language.”I hate them all,” he said. I actually think that he was technically fairly competent but in my opinion working with this guy would’ve been such a downer that I didn’t hire him.

In my next article I’ll take a look at different things hiring managers and interviewers are looking for in a candidate, and how they assess them in an interview.