
Interviewing candidates - daigoba66
http://ericlippert.com/2015/06/08/interviewing-candidates/
======
tptacek
I feel like this is how everyone thinks they interview candidates, and that it
doesn't really work. I wrote about this at length, specifically so I wouldn't
write the same long HN comment every time this comes up. :)

[http://sockpuppet.org/blog/2015/03/06/the-hiring-
post/](http://sockpuppet.org/blog/2015/03/06/the-hiring-post/)

~~~
jkaptur
I appreciate that you're tired of writing the same comment over and over, but
I'd really appreciate your going into some depth about what "this" is that
you're referring to and how it contrasts with your approach. It seems like the
original article describes a very scripted, standardized interview that tries
hard to put the candidate at ease. If you were to condense your article into a
sort-of "Joel test" for interviews, I imagine that this process would score
reasonably well.

~~~
tptacek
It's based on the assumption that it's reasonably possible to put a candidate
so at ease that they can solve interesting programming problems in front of an
interviewer. But in-person interviews are inherently hostile, if for no other
reason that they're timed and adversarial. It's better that we jettison the
entire notion that they can be a venue for demonstrating programming ability.

I'm not opposed to interviews. I just think you need to factor out the
programming from them.

~~~
richmarr
Huge fan of that hiring post, by the way.

I'm currently working with a roomful of cognitive scientists on ways to unpick
some of the bias from recruitment. Be good to have a chat at some point if
you're interested.

~~~
tptacek
I'm easy to get ahold of. :)

------
gfodor
"How are things going?" is actually a terrible question to ask someone in an
interview, if that's literally how you ask it. It is saying to them, in so
many words, "tell me how you think you are doing, performance-wise, so far?"

Horrible, and about the direct opposite of a question that will put someone at
ease. Questions that will put someone at ease are ones that have nothing that
can be construed as something you are _assessing_ their answers to, like
asking them about their visit to the area or if they enjoyed lunch or
something like that. Break the ice, tell them about what you work on, see if
they need a break, and then start digging into stuff. I also like to tell the
person up-front what we'll be covering in the interview so there are no
surprises. Walking in the door and asking them a question they could interpret
to mean to reflect on their interactions with the previous interviewers makes
me cringe.

~~~
ericlippert
Well as I said in the article, the intention of the question is emphatically
not a "gotcha" about how they are actually doing. It's intended to find out if
there are any problems that need addressing.

~~~
gfodor
Yeah it's a tough one I think to ask well -- maybe you've got the tone and
wording down in a way that candidates won't misinterpret, but I've avoided
that type of question because I'm not able to do so.

------
jkaptur
This is almost exactly the template that I apply to my own interviewing.
However, I switched away from asking about a project on the candidate's resume
because I found that that question - specifically meant to put people at ease
- did not in fact put them at ease.

Instead, I found that people became surprisingly flustered - including one who
said that "like a lot of things on there, it sounds cooler than it is" and
went on to question his own commitment to the field. I asked about the project
because it sounded awesome, and, when I pressed him to please tell me about
his role, it was awesome.

I think that many people are not prepared to discuss every item on their
resume. I don't think that's great, but I don't want to base a large amount of
my decision on that fact. This question threw them off for the rest of the
interview, so I've stopped asking it.

~~~
eli
Some people -- i.e. introverts -- are uncomfortable talking about themselves
and their strengths and accomplishments. Unfortunately that's kinda the point
of the interview. Not sure there's much you can do about that besides (as you
suggest) pressing them to answer questions and cutting them some slack for not
being super forthcoming.

------
RogerL
"Red flags often surface at this point. I’ve had candidates with PhDs in
computer science, for instance, who did not know that on a 64 bit
architecture, pointers are 64 bits wide."

Because learning 64-bit architecture is impossible for somebody that have
proven that they can learn a field, perform research, and successfully write
and defend a dissertation? '32 < 64' is beyond them?

~~~
ericlippert
No, because we are _actually building telescopes here_ , and astronomy PhDs
apply, and when they are not actually clear on the difference between a
reflector and refractor telescope you realize, hey, this person is going to
need to learn so much about the very basics of the field that they're applying
for that it's not going to be a good fit.

I've had candidates with PhDs in computer science who thought that pointers on
64 bit operating systems were two bytes wide. Do they believe that there are
only 16000 possible allocations before the allocator fails? Not likely,
because that's ridiculous. So how could they have that belief? because they
understand so little about pointers that they don't understand the
_implications_ of their false beliefs.

I need someone who is going to command the salary that a PhD-level candidate
will demand to be able to hit the ground running.

~~~
zerr
Different perspective: I believe for most CS persons this would be a 5-minute-
difference... i.e. it would take 5 mins for them to understand/research 64 bit
OS pointers size. So basically you're penalizing potential good candidates for
just 5 minutes of their life.

~~~
raverbashing
Yes, it may be only 5 min.

But it tells _a lot_ about the amount of "just 5 min" things they don't know.

I was asked once what load average knows (and I didn't know it). Because my
background wasn't in sysadmin.

The fact that you know one fact or doesn't is immaterial, but it's a good
proxy.

Your hiring decision should not be based on only that, of course, but let's
say it's a pixel in a picture.

------
Bartweiss
It had never occurred to me until I read this, but I have a sudden urge to ask
my interviewers simple coding questions like "reverse a linked list".

In most cases it would be a silly waste of time, but it would also have saved
me from one or two truly horrific jobs with skill-free managers.

------
cechner
This was my thoughts on the matter: [http://seshbot.com/blog/2014/01/24/the-
best-way-for-programm...](http://seshbot.com/blog/2014/01/24/the-best-way-for-
programmers-to-interview-programmers/)

summary: ask the open ended question ‘what was the most recent interesting
project in which you were heavily involved?’ and then focus most of your
technical questions on the system the then describe. If a programmer can’t
talk throughly about a topic which they chose themselves and are purportedly
very interested, they probably aren’t right for the job (at whatever company
I’m working for anyway!)

The benefits are that you wont be randomly hitting a gap in their knowledge,
you get a better idea of what they feel are their greatest strengths, and
because you can raise your expectations about the quality of their answer you
can probe very deeply and find out how good they are at communicating, and
whether they are actually blagging.

The problems you can encounter are: they might end up running the interview if
you aren't careful; you must be very engaged and perhaps talk about things you
aren't that knowledgable yourself, and it is harder to compare one candidate
with another (which is VERY important at large companies where you must
justify your decisions to HR)

------
mparramont
I also wrote a thing about coding interviews, from the employee side:

[http://www.developingandstuff.com/2015/05/why-i-dont-do-
codi...](http://www.developingandstuff.com/2015/05/why-i-dont-do-coding-
tests.html)

------
at-fates-hands
_" Second, what actually did they do on this project?"_

A lot of developers I know when in interviews say, "Well, the "team" did this
and "we" did that. You always want to use singular personal pronouns such as,
" _I_ did this", or "The team expected _me_ to do such and such."

This is something a lot of potential hiring managers like to hear. If they
have to ask what _you_ did, many believe you're role or your work may not have
been that important.

~~~
reagency
Yes, parsing "I/we" is a great way to filter out collaborative team players
and hire antisocial narcissists.

Is that what you want, though?

~~~
ryandrake
I don't care as much about what the rest of the team did, because I'm not
interviewing them. I'm more interested in what you, the interviewee,
personally did to help the team achieve success.

------
ksk
I agree with what was said in the article. I'd say one half of programming in
general is objective in the sense that either the program works or doesn't.
The other half is completely opinion based - be it a design philosophy,
choosing algorithms, future proofing APIs, hardening code against malicious
actors, etc. This half is very fuzzy because there are no right/wrong answers
as it goes more towards taste. IMHO you should try to evaluate the following -
"What has the candidate done that makes their opinion worth something". If you
can't come up with a very strong reason to give any kind of weight to their
opinion, then I'd say do not hire them.

------
doragcoder
I feel like I follow this template as well. Except, I like to add a small self
assessment at the beginning of the interview. Like:

    
    
          Q: On a scale from 1 to 10 (1 being low) how do you rate yourself on "Programming Language Du Jour"?
    

Then I can see if their self assessment is inline with mine. Which can help in
reviewing the resume.

I also like to ask for them to choose a project in the past to talk about,
because then it's easy to see what they are passionate about. Or easily tell
if they are choosing to talk about something because they think, you think,
it's cool.

~~~
EliRivers
I was asked by a hip, happening, popular web-app related startup to rate
myself in C++.

I pointed out that Bjarne Stroustrup rated himself 7 out of 10 once. I wasn't
as good as him, and I wasn't nearly as good as him, which left me the field of
5 and below.

I can guarantee that some ham-fisted chancer who'd flicked through the "Teach
Yourself C++" chapter summaries put himself down as an 8, though.

~~~
stygiansonic
Agreed - the answer to this question is really the result of how much one
_thinks_ one knows. Because a little knowledge can result in false confidence,
those that rate highly will fall into two categories: Those that actually
know, and those that don't.

If the interviewer can distinguish between these two categories, then what
value does the question add? If the interviewer cannot and is relying on the
answer to this question (even partially), then it's an example of relying on a
false signal.

Whenever I'm asked this question, I always respond with the following
questions:

1) What does a "10" mean?

2) What does a "1" mean?

3) What's the difference between 5, 6 and 7?

4) (Optional, this could easily come across as being snarky) What's the range
of levels in your team/org/dept for this metric?

~~~
reagency
You are absolutely right, but your behavior would offend the kind of person
who thought it was a good question in the first place.

------
therobot24
> Leave the candidate with a positive impression of the company

I feel like I haven't experienced this enough in interviews. Mostly I assumed
that if I'm applying then interviewer already thinks that I have a good view
of the company (or otherwise I wouldn't want to work there right?), but it
would be nice to get a better outlook of the company. Maybe I'm just asking
the wrong questions.

------
dbenhur
> if we make a bad hire, that can drag down the productivity of a team for
> years

This is the essential cowardice of employers. Interviews are insufficient
contexts to judge if someone can help move your business forward. Screen the
incompetent, but just hire people and don't be afraid to let them move on if
they don't work out after 2/=4/6 months.

------
ausjke
Love this, very useful for me, especially the gradually elevated technical
interview steps/details, though it's less meaningful for junior engineers, who
normally can't think that deep yet be it at interview or on the job.

------
lukasm
Why not do 2 phone screens to filter out completely incompetent people and
then let them choose:

\- paid work for a week

\- writing patch for a project or making simple tool(proxy of the job) and
invite them to talk about it.

~~~
civilian
Because candidates have lives outside of code. They probably already have a
job, so taking a week off for "vacation" which will actually be a "paid
interview" sounds like a crummy deal. Writing a patch-- similarly, it's eating
into their own time. You're going to lower your hire rate from that.

~~~
dagw
If they can take half a day or a day out of their life to show up for an
interview then certainly they can take the same time out of their life to
write some code instead.

------
dvt
I don't really get it.

This is sounds like a very pretty typical software engineer interview process.
The fact that these kinds of interviews suck, don't produce good hires, and
yield a ridiculous amount of false negatives has been beaten to death.

Unless you're Google (or Facebook), you are not getting thousands of
applications a day. You don't need to emulate their hiring process. They do it
for a reason (practicality) whereas it seems others do it out of pure
snobbery. Whiteboard coding is worthless (barring simple fizzbuzz tests which
can be done over the phone anyway). I mean how pompous does this shit sound:

"All candidates eventually figure out that they will need to add an auxiliary
data structure that maintains a map from a 32 bit integer to a 64 bit pointer,
because of the aforementioned ten pound sack. Do they know that there are off-
the-shelf map classes? If not, do they have confidence that they could write
one?"

Eric Lippert is originally from Microsoft though, so I guess that shouldn't
surprise me. After all, they're the ones that started asking "Why is a manhole
cover round?" in software engineering interviews.

Much respect goes to tptacek that outlines a much better and enlightened
alternative.

~~~
ericlippert
Well, my intention was not to sound pompous, but writing is hard, you know?
Thanks for your cogent critique of my tone.

~~~
ximeng
Regardless of whether you or tptacek has the better method for hiring coders,
I have much more problem with dvt's tone in his post than yours in the
article. Hope this kind of response won't discourage you from posting more, as
I've had a lot of value from your writing in the past and found this article
interesting as well.

~~~
AtmaScout
I second this. I've read a lot of your writings and have even watched your
episode of 'Checking in with Erik Meijer', both of are very informative.
Thanks for writing this article.

------
m3talridl3y
Here's how you hire a candidate, in two steps:

1) If they provide a github/bitbucket/sourceforge link, look at what's there.
Skip step 2.

2) Literally anything else. It won't work anyway.

~~~
dagw
Assuming you just need a candidate to do grunt level coding.

