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

51–60 of 85 posts

Re: Interviewing candidates

#51

Post by dang »

smil wrote: post #43
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…

You seem very entitled.

> You seem very entitled.

Personal attacks are not allowed on Hacker News.

Re: Interviewing candidates

#52

Post by [deleted] »

eli wrote: post #13
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…

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.

[deleted]

Re: Interviewing candidates

#53

Post by mediocrejoker »

bzz01 wrote: post #15
RogerL wrote: post #10

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

I guess author assumes that if you don't know basic things like that, it is questionable that your degree is a proof that you "can learn a field etc." Not sure that I agree on the choice of this specific "red flag"; on the other hand, having PhD in CS is a red-ish flag to me per se.

"... on the other hand, having PhD in CS is a red-ish flag to me per se. "

I would be interested in hearing your reasons for that.

Re: Interviewing candidates

#54

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

Re: Interviewing candidates

#55

Post by bzz01 »

mediocrejoker wrote: post #53
bzz01 wrote: post #15

Earlier quoted context omitted.

I guess author assumes that if you don't know basic things like that, it is questionable that your degree is a proof that you "can learn a field etc." Not sure that I agree on the choice of this specific "red flag"; on the other hand, having PhD in CS is a red-ish flag to me per se.

"... on the other hand, having PhD in CS is a red-ish flag to me per se. " I would be interested in hearing your reasons for that.

So of course I'm generalizing, not everyone is like that, not everyone's CS degree is like that, etc. etc. Also, more true for recent grads.

But in my experience people with advanced "pure CS" degrees seem to be focused on the process not the result. I mean, they went to CS because they like to tinker with type systems, elegant algebraic concepts, nice abstract problems -- and not just as a hobby, they like it so much so they commited several years of their lifes to do that. Not that this is bad area of research, but generally when you look for a software engineer you look for someone not only smart but also pragmatic, who can get stuff done in a simple and efficient way, and this is kind of the opposite.

Of all PhDs, in my experience people who have degrees in areas that use programming as a tool not the goal in it self, e.g. physicis/EE, make the best software engineers.

Re: Interviewing candidates

#56

Post by zerr »

ericlippert wrote: post #30
RogerL wrote: post #10

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

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.

Re: Interviewing candidates

#57

Post by cpitman »

ericlippert wrote: post #27
stygiansonic wrote: post #12

Earlier quoted context omitted.

Talking about a project seems fine to me. But the self-assessment on a scale of 1-10 just seems like a quick way out for the interviewer and can only serve to find fault with the candidate and to me, doesn't seem like it provides much information. For example, what does 10 mean? Does that mean that they have mastered the language (and all of its minute details, implementation, etc.) and would find it impossible to le…

The solution to this problem is to follow up the question with "oh, so you're an eight, great, what is something that a seven would have difficulty with?" Make them calibrate the scale for you.

Or flip it around, and ask them what they are going to do in order to get to 9. It shows how self aware they are of their own knowledge gaps and also calibrates the scale.

On the off chance they say 10, well, they better know just about everything.

Re: Interviewing candidates

#58

Post by vacri »

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.

Different perspective: I'd prefer to hire the astronomy PhD who knows the basics of the craft over one who doesn't. Reflecting vs refracting is pretty simple - astronomy doesn't really interest me and I'm aware of the differences. It's fundamental to the optics, and understanding the differences helps understanding why real data looks different depending on method of acquisition. Why not penalise the person that doesn't know the basics? You wouldn't forgive a carpenter for not knowing the difference between a hand saw and a table saw, yet they both cut wood and the difference takes all of a few seconds to learn.

For example: I'm a midrange DevOps/Sysadmin/Whatever-it-is-these-days. I will likely never be a senior. The (real) seniors are the folks who go home and mess with hardware and pull new toys apart to see what chips they were made with and so forth. I like to go home and play games. I do my job competently, but I don't have the underlying knowledge that those guys do. If I was up against one of those in a job application, then you'd be crazy to hire me at the same salary as a senior - there'd have to be a pretty big black mark against the senior, like being completely unpersonable or abusive or somesuch. Or the role used some of the other things I'm decent at. Perhaps a colloquial way to put it is that I live these things, but the seniors live and breathe them :)

Re: Interviewing candidates

#59

Post by ximeng »

ericlippert wrote: post #26
dvt wrote: post #17

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 (practical…

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

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.

Re: Interviewing candidates

#60

Post by cechner »

This was my thoughts on the matter: http://seshbot.com/blog/2014/01/24/the-best-way-for-programm...

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)

Post reply on HN