

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

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.<p>What advice do you have a for a first-time interviewer?<p>- 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?
======
tptacek
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.

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

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

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

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

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

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.

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.

Ask yourself: If I had a problem, would this individual be someone that I
could ask to help me solve it?

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

------
HeyLaughingBoy
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!

------
anamax
You should be familiar with the role for which the candidate is being
considered.

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.

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

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.

------
amdev
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>

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

------
mbrubeck
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).

