Technical Interviews
Strata Rose Chalup
VirtualNet Consulting
strata@virtual.net
[Copyright 2000 Strata Rose Chalup, plus whatever login likes… ]
Introduction
This article was inspired by reading an article about techical interviewing that seemed, frankly, to have its head up its /dev/null. An online pointer to said article was forwarded to a social/technical mailing list of which I am a member, and a couple of folks said, "Do you think this is reasonable?" to the assembled multitudes. As a 100% card-carrying lurker, I tend not to respond to things unless they hit one of my hot buttons. One well-established hot button is any of a large class of articles on hiring and interviewing that I have seen in the trade press lately.
These articles are geared toward new and established managers, and purport to deliver "the essentials" of the hiring process. The vast majority of them seem to make several assumptions which are insulting to most of the participants, including the company doing the hiring. Common themes include:
Anyone who has hired sysadmins will realize how profoundly bleak and inaccurate a picture is presented by these worldviews. Let's see if we can combine some less degrading worldviews with some practical advice. If we're lucky, the combination will help those of you looking for new hires find and attract good ones. If not, we'll get a whole pile of flame mail. I already have a button that says "oh no, not another learning experience". Yee-ha-ha! Full speed ahead, and clri() those torpedoes…
Not a unique problem
You can't get what you want until you know what it is, right? We are usually looking for a rare combination of independence and diligence, ability to groundbreak but also to follow procedures. In some cases, depending on the position, what a candidate already knows is much less important than how the candidate thinks and acquires new knowledge. Of course, they'd better already know "enough", or they'll spend too much time coming up to speed.
As a profession, we tend to feel that we are fairly unique, but in fact the medical profession has some very similar needs. An acquaintance in that field described the process of hiring clinical staff, saying "What I want are staff that are resourceful and able to problem solve to some degree on their own. We definitely set guidelines as to what they are and aren't able to advise patients on, but a little independent thinking on their part allows us to work without constant interruption. They have to be able to triage the urgent problems and do so without panicking (at least not in front of the patient!) ." Sound familiar?
Baby-size holes in /dev/hiring-filters/bathwater
We all like to joke along the lines of "Where are you working?" "Hmm, what month is it?", but few people enjoy the disruption that comes with settling into a new position frequently. Our own SAGE salary survey shows that other factors besides money are often the prime factors in job changes. Good sysadmins are a scarce resource, and they know it. They usually view shopping for a new job as a pain, rather than a necessary once a year salary increase, and will put a great deal of thought into picking the position that seems to emphasize fun and learning.
Too many participants regard the fundamental purpose of technical interviews as a winnowing or weeding-out process. This kind of attitude leads them to structure the entire process as a series of ever-higher hoops that the candidates have to jump through before they are judged good enough for a second round, let alone an offer. Unfortunately, this kind of tough-guy interviewing often backfires, giving the impression that your workplace is arrogant and uninteresting. We need to consider two fundamentals, not just one. "Screen each candidate rigorously is the obvious first. The oft-neglected second is, While doing this, how do we simultaneously convince them that we have a good work environment?"
I don't for a moment suggest that one should relax one's standards for technical contribution. The truth is that it is difficult to switch horses in midstream from "we're not sure you're good enough to work here" to "we're such a great place and that's why you should work here!". At least, it's difficult to do it and not sound completely fake-- I've certainly seen it done many times, just rarely seen it done well. The interview process should be designed to convince every candidate, even the ones who are hopeless, that you have a great team and a great workplace.
It's the mindset
If you view this as "wasting effort", you are already part of the problem. Even the worst candidate has friends who are more talented-- perhaps especially the worst candidate. People grow and change. Here in Silicon Valley, a year can make a huge difference in someone's skills and maturity level. When Joe Clueless turns into Joe Admin, you would assuredly rather have him resubmitting his resume to your group than telling all his friends, "oh, I interviewed there a year ago and they were a bunch of fascist losers; don't bother!" Even better, when Joe Clueless goes to one of the many technical group meetings or conferences, he might tell Jane SuperAdmin, "Hey, I interviewed at FooGroup the other day. They were looking for someone a lot more like you than like me, and they looked like a really fun place to be!"
Please note that I said "participants" a few paragraphs above. Usually the candidates, as well as the interview team, are often indulging in this kind of zero-sum thinking. To be sure, only one person will get the job-- this job. What about the next job, for a more junior or more senior candidate? What about the job at the company where an interviewer's spouse, friend, or colleague works? Or the job a year from now at the candidate's employer, where the candidate needs someone like you on his or her team? One of the most valuable pieces of "technical" advice I've ever received was given to me by my first real IT manager, Alan Wu at MIT-EECS. He told me, "It's a small world, and nobody ever really goes away. That means that nobody is disposable, because you'll be running into them again and again."
Think of the interview as merely the first time that you will encounter a particular candidate. If you are both good, the chances are that you'll see each other again. It may even be on a different side of the interview desk.
The Interview Lifecycle
Create a job description
Include any hard and fast requirements right in the body of the description, like Oracle experience, sendmail experience, etc. Describe things in the most specific terms possible-- they will probably make you edit it down, but at least you have it clear in your head now!
Depending on your group style and responsibilities, your team may help you come up with the wish list. Be sure you distinguish between "must have" and "would be nice".
If you are a believer in certification, and have chosen to require it for a candidate to be considered, be sure to specify the type and how to recognize it for HR, e.g., "Linux certification" vs "RedHat certified" vs "must have RedHat XYZ certification, would like RedHat ABC certification as well". Bottom line: anything that is very important to you will need to be specified in ways that a non-technical recruiter mining a bad database engine can pull out for you, or you will miss good candidates!
Create a requisition or budget item for the position.
This one is really crucial, especially if you know potential candidates. Don't go getting your friends' hopes up until you do! As part of this process, you will have identified who is the hiring manager, and who is the reporting manager. Yes, Virginia, due to extreme trust or extreme department politics, they may not be the same person. You, or someone who can represent you, must have a budget for the candidate. This is generally the toughest part of the process, as the necessary paperwork and approvals can literally take weeks.
You may think, "shouldn't I get the budget first, then do the description"? Perhaps, but we are not all that fortunate. In many organizations, it is necessary to create a job description first, including the duties to be performed, to demonstrate that there is a need for the position. You may end up crafting a two-part document, where the first part is the traditional job description and the second part is the job justification, including a detailed description of what currently neglected tasks will be performed by the new hire.
Make your requirements known to your Human Resources department.
Brief your HR people about what characteristics and experience are important to you. Unless your organization is atypical, you will need to make sure they are not using some kind of lame keyword-driven resume search service, and you will probably need to show them Internet resources like the SAGE Jobs Board, Unix Guru Universe, Monster.Com, Dice.Com and so on.. When you talk to HR, make it a two-way conversation.
You need to be sure of the requirements for introducing a candidate into the process, in the event that you or a team member will be referring someone, or if you encounter a potential candidate's resume online. In some firms, you cannot just snag a resume off the net and call the person. There may be a requirement to have HR perform some initial screening. Be sure that you include salary information for the position in the material given to HR.
Do the "team huddle".
Talk to your existing team about the position, if you haven't already. It can be quite unsettling for a group to suddenly be told "here is your new coworker", as is the custom on many organizations. A good manager will make sure that everyone knows why another pair of hands are needed, and what responsibilities will be transferred to the new position. He or she will also work with employees whose job duties are directly affected by the new position.
In many cases, the position will have been created in response to overload on the part of existing employees. This does not absolve a manager from taking time with each of them to make sure that the new position is seen in a positive light, and to do a sanity check on how the work will be apportioned. I have heard a number of tales of people who were wearing several job hats they detested and one or two that they liked well enough to keep them at the job. Figuring prominently in these tales is a well-meaning but clueless manager who transfers their favorite hat to a new hire to "take off some of the pressure"…
The nitty gritty process.
"Is that your final, final answer?"
No one wants to be disappointed, but it is a good idea to identify a second (and perhaps even a third) candidate from among the qualifying candidates during your final feedback round. Attempting to do so later will be much less efficient, since people's memories of the interview will have faded. It also can clarify whether you should start lining up resumes in case your first-choice candidate does not accept-- the feedback may be that none of the other second-round candidates is quite enough of a fit if the first-choice one refuses.
Do not extend even a verbal offer until you have signoff from HR and/or your management chain! Common sense, but be sure to apply it. Your written offer should have a specific time limit on it, anywhere from a week to several weeks, depending on your situation. There are often good reasons why a candidate cannot make a choice immediately. Nevertheless, your organization needs to be protected from a situation where all the other qualifying candidates move on because your "best fit" takes far too long to turn you down.
Be sure that you've gotten all the requisite background information from HR before doing your final feedback round. It's incredibly discouraging to get through the process and find that your best candidate is ineligible because another department scored your last H-1 visa sponsorship for this year.
The end of the rainbow!
Really good candidates may have offers on the table already, so it's important for them to get yours as soon as possible. It's a good idea to make sure that a candidate gets an offer on a Friday rather than a Monday, even if you have to push HR to get it done. He or she will probably want to talk to their spouse, friends, colleagues about their prospects over the weekend.
If you are the hiring manager, you should extend the offer personally via telephone (subject to HR rules in your organization). Be cordial, and let the candidate know up front that you are not looking for an answer on the spot, you are merely delighted to be able to offer him or her the position. Indicate that you’d like to discuss it further in a day or so, asking if there is a specific date that they'd like you to call them. If they name a date too far in the future, negotiate! If the salary and/or benefits are flexible, also stress that you are available to discuss the offer in more detail if they have questions or concerns about it.
That's it. Keep your fingers crossed!
If you don't hear back from the candidate by the agreed-upon date, don't hesitate to call. If he or she does not return your calls, there's a good chance that you will need to contact other candidates. Be certain that you do not extend an offer to another candidate until the expiration of your first offer! If both candidates accept, you are in a sticky legal situation.
Hints, Tips, and Specifics
Use a well-organized process!
For yourself, make up a list of questions beforehand and use the same list for every candidate you are interviewing for this particular position. It will give you a much better set of points of comparison than if you "wing it" with each candidate.
Insist that other interviewers do a question list as well, and share them with each other. Don't wait until the feedback meeting to find out that several folks asked questions about the same area of expertise,
and no one asked about other issues, or that you all asked pretty much the same questions.
Bring your notes to the feedback meeting. A no-brainer, but you'd be surprised how many people come empty-handed and then can't remember when they're asked if Candidate A or Candidate B seemed to know more about some subject. Hint: take your notes on the cover page (schedule page) you got with the resume, and keep them stapled together.
Line up timeslots for consecutive interviewing with your team before the HR person calls the first candidate! People are hard to get reach sometimes-- your people and the prospective candidates. You don't want to lose someone good just because one of your key teammates is on vacation, or is swamped and can't meet with the candidate. Weekly group meetings are a great place for choosing timeslots, since conflicts can be worked right then and there. Your people do bring their calendars, day planners, or PDA's to your staff meeting, right?
If you are lucky enough to have a reliable shared calendar system that your team actually uses, you can schedule timeslots that way. It's poor form not to let folks know the days you are considering in advance, though-- not everyone puts their dentist appointments on the work calendar. Be sure to allot half again as much time as you think you will need, to allow for variations in the times that candidates are available to interview.
Decide in advance what sorts of questions will be first round and what sorts will be second round. This helps keep the process cleaner, and also allows you to tailor the second round questions as a group based on the qualifying candidates.
If you're recommending someone, be honest with yourself-- are they really qualified, or would you just like to be working with them (again)?
Some basics
The candidate should be able to handle the technical questions presented in the first round. He or she should have a firm grasp of whatever basics you have decided are essential for this position.
Make sure the candidate can draw & understand technical diagrams! They don't have to use VISIO, but make sure they can look at something on a whiteboard and understand it. Be prepared to discover that the diagram equivalent of linguistic drift has occurred within your group, and don't expect the candidate to know that a flat box always means a router and a tall box always means a server, etc. Just the basics.
If you're looking for a heavy scripter, at least ask to the candidate design a program right there in the office. Do it in pseudo-code, don't worry about syntax, but just do it.
Ask not what your sysadmin can do for you…
Make it clear that you are interested in the candidate's total contribution to the team, both technical and team fit/social. Yes, you want the skills, but let's face it, most people who are truly competent already can write their own tickets. It's up to you to show them why they want to work with you and your fellow interviewers. I'm not talking bribes or happy hour Fridays, I'm talking basic commitments to career growth.
Who goes to conferences? Who gets to take continuing education classes? Is there a book budget, formal or informal, with the position, and where do the books end up eventually? If the hours are routinely long, is there comp time? Finally, last but far from least, there's general experience-- it should be pretty clear in the interview process that you and the candidate will BOTH be able to learn a lot from working together. If not, what's the point?
Team fit: more than just hair color and Napster settings
The title of this section notwithstanding, it's worth mentioning that common sense, as well as a number of state and federal laws, should prevent you from judging people solely by their appearances. 'Nuff said!
Line up meetings before the interviews, meet and talk about exactly what you are looking for as a group-- you, your teammates, and your manager, or you and the team if you're the manger. Decide what is more important, existing knowledge or easy learning, which skillsets are crucial. Make explicit tradeoffs, since you can't have everything. Talk about what constitutes team fit for your workplace.
During the interview, if you are the manager, ask the candidate what kind of status and reporting practices they have used in the past, and about their preferences. If your group is a "weekly status meeting, plus drop a note in email to the group when you do something big" kind of place, then you are not going to be a great fit for someone used to getting a set of specs and coding in the dark for a month, or vice versa. Let them ask you the same-- a seasoned candidate usually will!
Be up front but not discouraging about any limitations of the job-- on-call pager, tight deadline coming up, etc. People nowadays will walk unashamedly after a few weeks of a bad job fit, so you want to prevent that if you can. Things like whether the position is included in the on-call rotation, and how often, should have been defined at the very beginning.
Don't scare folks away, but be up-front about it. Make it clear that what you are talking about is the truth, NOT the tip of some evil iceberg. If you can't do this well, have the hiring manager do it, since he/she is usually expected to be "the heavy" in the interview process anyway. Yes, I said the same thing near the beginning of this article. It's worth repeating!
Not "just the facts, ma'am"
When interviewing someone, make sure you ask a combination of detail questions and process questions. For some jobs, one is more important than the other, but generally you want both. Whichever they give you, accept it politely and encouragingly, and promptly ask for the other one.
Example Question: "I sit you in front of a web browser and when you try to load a page, you are getting a "host not found" error. Tell me the kinds of things you'd look for to find out why that was happening."
Sample process answer: I'd check to see if the machine was set up to resolve hostnames properly, or if its network connection was down.
Sample detail answer: I'd check the /etc/resolv.conf file to see if it was present. If it existed, I'd use nslookup to try some name resolution by hand.
The Interview, the Actual Interview
This is no time to neglect the basics of public speaking. As they say, "First I'll tell you what I'm going to tell you, then I'll actually tell it to you, then I'll tell you what I told you, and then I'll take questions." This is a good way to handle the interview process.
Who…
Tell the candidate who you are, including your relation to the position. Be very clear about your role. Are you a hiring manager? A potential co-worker in the same group, team, or department? Are you from another group, with whom the person would be cooperating closely? looking for team fit, the ever-popular "here to ask you a few questions", what?
How long will we be at this? Where will we be? "This conference room XYZ, folks will come to you, vs my office, then I'll take you to ABC's office." Who will the candidate see next? And so on. Knowing what to expect goes a long way toward relaxing the candidate.
…what, when…
Resist the temptation to only tell the him or her about the next hop in the chain. I've seen this done multiple times, and it's inexcusable. It generally happens in places that have had the experience of a candidate looking good on the resume, but not actually being as qualified as the resume implied. The firm cuts the candidate off after one or two people have done their interview sessions and there has been a decision that continuing would waste the company's time.
If you are doing first round screenings, you shouldn't schedule more than one or two people in the first place. For that matter, if you don't have a phone screen process that can keep this from happening, you are doing something wrong, and need to fix your process. It's hard enough for the candidate to be out there looking. He or she does not need to feel that a door slammed in their face, instead of having one closed with some basic respect. Word gets around.
…where…
Choose a space where you will not be interrupted. If your workplace does not usually schedule conference rooms, but instead does "first come, first served", you will probably want to post an abbreviated schedule on the door. This serves the dual purpose of reserving the room and letting people know how long you will be there. You don't need small meeting groups popping in every now and then to ask "will you be much longer?"
Try to get a space with a whiteboard or a blank flipchart pad (and markers!) for technical diagrams and off the cuff illustrated problems or war stories.
Consider environmental factors-- if you are doing morning interviews in the south-facing conference room, the one with the minimal air conditioning, you will probably roast your poor candidate in his or her suit, not to mention yourself. Will one of you be squinting at the other through the bright sun, or does the room have blinds or shades? Just common sense, but keeping it in mind is a good thing.
…and "how"
Relax the candidate a bit. This is especially important for technical positions. Many folks who are very competent are better at typing than talking, or don't deal with humans as well as with solving problems.
If you are the first interviewer, or someone in the middle of a long string of interviewers, be sure to offer the candidate some basic hospitality. Ask if he or she needs to take a quick break to go "down the hall". See if a drink would be welcome. Many people are nervous about asking, or may refuse if you are not also having something. If the office break room is nearby, both of you could duck out to snag a soda or coffee to bring back to the conference room.
Warn him or her about any "tricks" you do in advance, which makes it more understandable and more of a game than a challenge.
Example: "I just want to let you know that some of the questions I'll be asking you have one right answer, some have multiple right answers, and some are open problems in the field that may not have an answer at all. I want to know how your mind works as much as what things you already know, since a lot of this position involves dealing with things that nobody really has working yet!"
Take notes during the interview. Mention to the candidate that you do this for all candidates, so that he or she won't think you are only taking unfavorable notes. Good topics for notes are things that impress you positively, things that you have questions about, things that strike you as strongly negative, and things that you want to keep in mind during the feedback process.
Hint: Take notes on the back of the cover sheet of the candidate's resume so that you won't have to keep flipping over your notes to ask about things on the resume. You did bring the resume, right? And you did read it before the interview?
Make sure there's a "thank you"
Each interviewer should thank the candidate for his or her time, and find something on which to compliment them. It's just basic business courtesy, and we sysadmins as a profession often lag behind on this one. "Well, thanks, uh, I guess somebody will call you when we know something"-- c'mon, you can do a little better than that!
The last person to see the candidate on that day should hand them off to HR or the hiring manager for a goodbye, or should be someone polished enough to do a smooth goodbye. Let the candidate know that you appreciate their presence, that someone will be contacting them by such and such a date at the latest, and make sure that you have correct contact information.
Afterwards-- the feedback
Do an individual feedback session for each team member as well as a roundtable feedback session everyone who is part of the interview process. Your team, like people in general, will often be more candid in private, and may have opinions that they aren't comfortable sharing with the group.
…and the other feedback
Be sure that the candidate hears from someone in HR or from the hiring manager that same day or early the next day. If you are very organized, you could skip this step because you'd have told the candidate at the "goodbye" part of the interview that he or she would be hearing from you by a particular day. After all, the feedback roundtable would already be on your calendars, and the interview slots for second round as well. Since most of us are not this organized, it is a good idea to call the candidate and reiterate your thanks for their time and establish a time when he or she will be contacted with definite news about next steps (or the lack of them).
A few favorite questions
When comparing notes on interview questions, colleague shared this amusing tidbit: "At the end I usually like to ask if there is anything he/she would like to add which might influence my decision in any way. The most memorable response to date: "Well, I'm presently in the process of suing my last employer..."
Yow! Well, favorite interview questions are a whole article in and of themselves, but here are some which I believe should be included in the secondary rounds of interviewing, maybe even in the first rounds for certain sorts of positions.
"What's the thing you're proudest of that you've pulled off?"
I like to phrase this one roughly that way, as it elicits a different and usually more interesting type of response than the dry "what do you feel has been your greatest accomplishment". When did you beat the odds, climb the mountain, make the sun stop in the sky? Even if it wasn't something that looked like a big deal from the outside-- tell me about it! This is a really good way to find out more about the values and experience of the candidate in one big rambling package.
It's also a good way for candidates to be able to talk about things they might have done outside the context of work-- collaborated on an open source project, set up email for their highschool, pulled puppies out of a burning building. If someone talks about work-related stuff in response to this, and I feel that I have a good rapport with the candidate, I will usually ask if they'd share something outside the context of work in this area. I always assure them that it is highly optional, but most people get too few opportunities to share their triumphs.
"Tell me about a situation that you wish you'd handled differently, and why-- with 20-20 hindsight, what would you have done instead?"
Everybody has these! Everybody! I can tell you about some doozies, believe me. For those of us who started on SunOS, we can all remember the first time we deleted the ld.so libraries, usually late at night, and how we found our way back to civilization some millenia later. I want to know that the candidate is comfortable enough to tell me about a learning experience, and smart enough to have learned from one. You'd be surprised at the number of folks who will describe a problem and say the way they wish they'd handled it was not to do it in the first place. For most problems, that's not learning solutions, that's learning avoidance behavior.
"What's the worst technical situation you've ever seen someone else create, and how did it get that way?"
Rare indeed is the sysadmin or manager who has not seen something so hideous and crufty that it evoked a reaction of "must…fix…problem...". We've also stood by and watched helplessly as those outside our sphere of influence struggled with something we were not allowed to help fix, and felt that horrible empathy as defeat was once again snatched from the very jaws of victory. So, did we learn anything? War stories also build rapport-- don't be afraid to share one of yours, but perhaps it should be something from a previous job, and clearly labelled as such.
Last but not least…
Don't give up too soon!
Another mistake often made is to narrow the search too quickly. Obviously you shouldn't waste your people's time, and good candidates usually go quickly. Still, the "bird in the hand" syndrome means that most inexperienced hiring managers don't try to identify all qualifying candidates. Instead, we often see a rather futile cycle.
The first candidate that is fairly decent and has good team interaction is turned into the "best-fit candidate" by some sort of Procrustean revisionism on the job description or requirements page. A few months or weeks later, the disconnect between the original needs and the candidate becomes a problem for the team, the new employee, or both. In the worst-case scenario, the candidate search begins all over again. The easiest way to avoid this mistake is to keep doing first-round interviews even when you have promising candidates in the second-round stage.
Yes, I said candidadates above, since another mistake often made is to limit the number of people whom you advance to second-round. With today's abbreviated hiring cycles, often born of desperation, there can be an expectation that getting to a second round means the fix is in. Not by a long shot! Any truly qualified candidate who is a potential good match for the job should be advanced to the second round stage.
Do not progress serially, i.e. seeing if one candidate "passes" to second round with the team and only contacting other candidates if he or she does not. Second round should progress in much the same fashion as the first round, with all of the candidates interviewing within the same two or three days. If there are two candidates who are both sufficiently well-regarded that it seems difficult to choose between them, you may want to bring those two in for a 3rd round. Depending on your organization's growth rate, you may also want to see if you can offer a position to both of them!
Good luck!