Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interviewing candidates

ericlippert.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Interviewing candidates

#61

Post by warcode »

jkaptur wrote: post #2

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…

As an introvert I can tell you that most of the time anything in an interview will be flustering if unknown.

Tell them to pick a project or two and prepare to talk about it ahead of time of the interview.

Actually many of the issues I have with the current "standard" interviewing process is all about the fact that its a "school test" environment instead of a "prepare for a specific task" environment. The latter being what real work is actually about.

Re: Interviewing candidates

#62

Post by richmarr »

tptacek wrote: post #8
jkaptur wrote: post #6

Earlier quoted context omitted.

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 intervi…

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

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.

Re: Interviewing candidates

#63

Post by gjm11 »

tptacek wrote: post #3

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/

The following is utter pedantry, but probably thousands of people are going to read that page. "Consligeri" (a few paragraphs into section 2) is plural; you meant "consigliere".

Re: Interviewing candidates

#64

Post by douche »

lukasm wrote: post #20

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.

We did this for our most recent hire - gave them a short project to implement over a long weekend. I think we shot for a target of having it take the applicants at most four hours; I threw together the reference example in an hour or two. I think it was a success, and we'll probably use this method going forward. There's just no substitute for seeing actual code, and by extension, the way someone structures the problem in their mind. It also give you some easy jumping off points to discuss with the applicant - Can you explain why you used data structure X here instead of Y? Change this requirement, and how would you do this differently? etc.

Re: Interviewing candidates

#65

Post by raverbashing »

zerr wrote: post #56
ericlippert wrote: post #30

Earlier quoted context omitted.

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 o…

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.

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.

Re: Interviewing candidates

#66

Post by georgemcbay »

ericlippert wrote: post #24
nilkn wrote: post #11

Earlier quoted context omitted.

A very major difference that I noticed is that tptacek's process doesn't turn down a candidate if they don't have the requisite domain-specific knowledge; rather, they send them a bunch of learning resources and let the candidate resume the process at any future time. The OP's process would just reject the candidate, forget about them, and move on. tptacek's process is also going to work a lot better for candidates w…

These are good points. The number of candidates who have told me that they want a computer rather than a whiteboard is small but not zero. I do give the same few problems over and over again, and I do take extensive notes, but I am not keeping track of a specific set of metrics that I track across candidates. I have a pretty good sense of where the "middle of the pack" candidate is. The process could be more scientif…

I started my career being pretty terrible with interviews for reasons pretty well encapsulated in Thomas' article -- general nervousness, social anxiety, lack of confidence (in retrospect, I believe this was primarily an impostor syndrome issue).

I've gotten better at it with age, but the improvement in my interviewing skill is completely unrelated to my improvement in programming skill, though I believe both continue to improve still into my early 40s.

Speaking on behalf of younger me, and probably others like younger me:

Doing the work on a computer is scarcely better than coding on a whiteboard, and in some ways it is worse. It isn't my computer. It is set up all different, it would take me hours to set it up like mine, the keyboard is all weird, what the fuck is the ctrl key doing over there, fucking Lenovos, all of these are trivial differences in isolation but in aggregate they make the work seem just as foreign as doing it on a whiteboard especially because I already feel like I am "under the gun".

Also (and by far most importantly and relevant even if I had brought my own computer in): I'm being "watched". Even if you aren't actively watching me (or rather, younger me), I am effectively being watched if I'm sitting in some room at your company banging out code. I'm all up in my head about how this is taking too long, how long ago did I start, how long are they expecting this to take, etc, I never get anywhere even close to the "flow" that I commonly get into when I am doing real work, the whole experience is just completely unlike the experience I have when doing actual work and feels like torture.

And then lastly (drifting somewhat out of scope of both the original blogpostand Thomas' blogpost) another issue I've always had with these types of interviews is that I'm somewhat of a subconscious worker, in the sense that when I am presented with a thorny technical problem the way I often best deal with it is by not really thinking about it (consciously), but rather going for a walk, taking a nap or just otherwise zoning out and letting the solution sort of materialize out of my subconscious. This is obviously completely incompatible with any kind of traditional programming interview, where the interviewer is almost obsessively looking to "see the work" in how you're thinking about the problem and I can't just ask them to let me go take a walk for 15 minutes and get back to them with the solution they're looking for (generally - I'm sure some will respond saying they'd be okay with this, but practically speaking we all know it wouldn't fly in the vast majority of interviews). An extremely common occurrence for me back during the time when I did not interview very well is I'd be driving back from the interview and would just suddenly have completely fantastic answers for all of the questions that didn't go very well on-site, a technical interview version of l'esprit de l'escalier.

Having said all of this, I'm not one to suggest anyone who interviews in any specific way is objectively wrong (for their own needs). If whatever system you use generates enough hires to get the work done, then so be it; but I can really relate to a lot of the problems highlighted in Thomas' article, so at the very least I hope people interviewing with more traditional methods than he has been working towards realize they are certainly filtering out some really great hires (which is maybe okay for them, but like Thomas I believe ultimately bad for the industry if we continue with what we have now as the standard).

Re: Interviewing candidates

#67

Post by dagw »

civilian wrote: post #22
lukasm wrote: post #20

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.

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.

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.

Re: Interviewing candidates

#68

Post by dagw »

m3talridl3y wrote: post #48

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.

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

Re: Interviewing candidates

#69

Post by 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.

Re: Interviewing candidates

#70

Post by boothead »

georgemcbay wrote: post #66
ericlippert wrote: post #24

Earlier quoted context omitted.

These are good points. The number of candidates who have told me that they want a computer rather than a whiteboard is small but not zero. I do give the same few problems over and over again, and I do take extensive notes, but I am not keeping track of a specific set of metrics that I track across candidates. I have a pretty good sense of where the "middle of the pack" candidate is. The process could be more scientif…

I started my career being pretty terrible with interviews for reasons pretty well encapsulated in Thomas' article -- general nervousness, social anxiety, lack of confidence (in retrospect, I believe this was primarily an impostor syndrome issue). I've gotten better at it with age, but the improvement in my interviewing skill is completely unrelated to my improvement in programming skill, though I believe both continu…

I recently totally bombed a programming interview, and I always feel like I've done terribly, even if feedback afterwards is quite good.

I'd be interested in hearing how you improved your performance in interviews, if you wouldn't mind sharing?

Post reply on HN