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.