Live data from Hacker News

Ask HN: Advice for a first-time interviewer

news.ycombinator.com

1–10 of 13 posts

Ask HN: Advice for a first-time interviewer

#1
Tomorrow I'm scheduled to interview someone for a developer job. I'm a programmer working on GPU computing and the candidate would fill a similar role. Being a recent graduate, though, this is my very first time sitting on the other side of the table. In 45 minutes I'm supposed to judge whether the person is a good technical and cultural fit for my company but I'm not sure how to accomplish this.

What advice do you have a for a first-time interviewer?

- Can you suggest any good systems-programming (rather than algorithmic) problem solving questions? - What is an appropriate balance between talking about prior experience and working on problems? - Any obvious first-timer pitfalls I should actively avoid?

Re: Ask HN: Advice for a first-time interviewer

#3
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.

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.

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.

Re: Ask HN: Advice for a first-time interviewer

#4
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.

Don't deliberately try to wrong foot or otherwise trick them; pitch questions at roughly the experience level / difficulty of the job.

Write down plenty of questions so you dont run out.

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.

Re: Ask HN: Advice for a first-time interviewer

#5
Some favorite systems programming interview questions:

* 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.

* Your code crashes inside the allocator. Walk me through debugging it.

* Tell me about the most interesting problem you debugged without relying on the debugger or print statements.

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?"

I like the questions that have no direct right answers.

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.

Re: Ask HN: Advice for a first-time interviewer

#6
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.

Re: Ask HN: Advice for a first-time interviewer

#7
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.

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 listen (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 :-)

Like I said, it's hard to do this stuff on the fly. Training and practice helps :-)

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!

Re: Ask HN: Advice for a first-time interviewer

#8
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.

Re: Ask HN: Advice for a first-time interviewer

#9
It's not comprehensive but I like FizzBuzz.

--------------------- 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". ---------------------

From http://www.codinghorror.com/blog/archives/000781.html

Re: Ask HN: Advice for a first-time interviewer

#10
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).

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.

Feel free to challenge them and push a bit - why did they make the design choices they did, what would have worked better etc.

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.

Post reply on HN