Ask HN: Advice for a first-time interviewer

Some favorite systems programming interview questions:<p>* Tell me about some routines you tend to take with you from project to project; what's in "libyou.so"? Crap devs won't have any.<p>* Your code crashes inside the allocator. Walk me through debugging it.<p>* Tell me about the most interesting problem you debugged without relying on the debugger or print statements.<p>A question I always ask in dev interviews that isn't as systemsy is, "your typical linked list code, does it embed the list pointer in the struct, or do you have a separate list node struct with a void* in it?"<p>I like the questions that have no direct right answers.<p>One question I think you should always ask in every dev interview: "I am going to describe project XXX; it's relatively small. Give me a complete, detailed estimate of how long it will take you to do XXX." I like this question because (1) it flags people who can't estimate properly, (2) it forces them to talk through an actual project and break down the steps, (3) it catches people who don't think about testing.

Ask yourself if you would be happy to mentor the new employee once they are hired. If you would not, don't recommend that they be hired, even if they are technically competent. Don't forget, saying "yes" to the hire means that you will be working with them. It's easy to over-abstract the challenge of finding a good candidate, and overlooking traits like whether they are easy to work with.

I wouldn't hang up too much on coding questions - just throw in plenty of technical questions and maybe get them to sketch out how they would solve one problem.<p>Don't deliberately try to wrong foot or otherwise trick them; pitch questions at roughly the experience level / difficulty of the job.<p>Write down plenty of questions so you dont run out.<p>Dont be "afraid" to ask for more detail. And similarly dont worry about having to provide pointers or prompts to get people started - just to keep the conversation going.

First I'd say that at a company level there should be an overall plan for the interview that you fit in to. Interviews work better if the hiring manager assigns specific areas to specific interviewers, otherwise you can all end up focusing on the same area and not getting a rounded view of the candidate. (e.g. Jim - you focus on his general software engineering skills, John - quiz him on C++, Kate - do a resume walk etc).<p>In the absence of a plan (or as part of one), a good approach is to pick one or more projects from the resume and drill down into the details. Find out specifically what the candidates contribution was, what was the high level architecture his code fit in to, how was his/her piece designed/structured/laid-out, what were his interfaces to other team members, what difficulties (technical or interpersonal) arose and how were they handled, etc.<p>Feel free to challenge them and push a bit - why did they make the design choices they did, what would have worked better etc.<p>I find this approach can give you a good sense of the candidates level of contribution, their understanding of the larger scope in which they were working, their ability to debate and defend their choices, and their ability to communicate with you.

The most important question you should ask yourself at the end of each interview is "Do I want this person on my team?" If you're not sure, the answer is no.<p>Aside from that, be wary of anyone who spends too much time talking up their accomplishments - I've often found that candidates who talk a lot falter when asked practical questions.<p>Also, make sure you leave time for the candidate to ask you questions. That portion of the interview can really reveal to both parties whether they would be a good fit.

Behavior-based interviewing takes the approach that what the candidate did in the past is a good predictor of what they will do in the future. The problem is that it's difficult to learn to do it on your own quickly: it really helps to take a class in interviewing.<p>Briefly: Ask questions like "have you ever had to do X?" "What problem did you encounter doing X?" "How did you solve it?" "What would you do in this (insert common job problem) situation?" "What were the people at your last job like?" "Did everyone go out for lunch, or eat at their desks?" "Which do you prefer?" "Why?" "What did you do for lunch yesterday?" Learn to <i>listen</i> (this is the really hard part) and respond to the answers and drill down from there. For example, for each answer he gives you, think of three questions to ask to fully plumb it out. The phrase "tell me more about that" will quickly become your friend when you can't think of anything else to say :-)<p>Like I said, it's hard to do this stuff on the fly. Training and practice helps :-)<p>Then there are all the other things like not asking illegal or biased questions (legality varies by state), etc. Businesses really need to do a better job of training their interviewers!

FWIW: I started interviewing people in college for non-technical position although a very stressful job (favorite interview question: 'We think this job requires a sense of humor, tell us a joke'). Off and on over the years I've interviewed others for different positions. Regarding technical vs non-technical, both are the same for me; if the person is good it will show in both areas while if they stink then it will show in one area or the other.<p>Behavioral interviewing as mentioned in a previous post is Situation-Action-Result = SAR. Haldane I believe was the originator (Career Satisfaction and Job Success) although it might be someone else. Easy type of question to 'game' as you can construct answers to the typical questions. "Describe a situation where you made a mistake and how you fixed it."<p>IMHO much better to ask open ended questions. "You come across a car wreck with a person trapped inside the vehicle, what do you do?" "A 34 kV breaker continues to trip, what do you do?" "You are asked to code a function to compute compound interest, describe your actions and the code?" The idea is to find out how the person thinks; not whether the answer is right or wrong.<p>I'm good at interviewing people but it has taken lots of practice. One job had me as the plant tour and lunch interviewer; I could tell about the interviewee's technical skill just by the the questions they asked during the tour and at lunch. You do not have to focus on specific technical questions to find out if the person is knowledgeable. If they will fit into the group and have good learning habits then they will learn what it takes to be successful at the company. Technology changes but the ability to think and learn does not.<p>Ask yourself: If I had a problem, would this individual be someone that I could ask to help me solve it?

You should be familiar with the role for which the candidate is being considered.<p>If you're not the hiring manager, find out what the hiring manager wants you to find out about the candidate during your interview with said candidate.<p>If you don't know how to implement the answer or it doesn't seem to relate to the role, there's a problem in the hiring process. ("good technical and cultural fit" is much too vague to be an answer.)<p>Unfortunately, you don't have enough time to figure out a solution. However, this won't be your last interview and you can get more of the answer while discussing the candidate with said hiring manager.

In 45 minutes there's not enough time to see how good the candidate is. Your goal should really be the opposite - to make sure the candidate is not obviously bad. I always come into the interview with a list of simple programming tasks, and have the person work through them until we're out of time. You can also get a 'cultural' feel for the person based on how they interact with you in the pursuit of completing the tasks.

It's not comprehensive but I like FizzBuzz.<p>--------------------- Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz". ---------------------<p>From <a href="http://www.codinghorror.com/blog/archives/000781.html" rel="nofollow">http://www.codinghorror.com/blog/archives/000781.html</a>

Have a range of questions prepared so you can fall back on easier questions (in case the candidate is drawing blanks or is having trouble getting past their nervousness/anxiety) or harder questions (in case they totally blow away your regular ones).