Live data from Hacker News

Interviewing candidates

ericlippert.com

21–30 of 85 posts

Re: Interviewing candidates

#21

Earlier quoted context omitted.

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.

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…

I would welcome the challenge in what rating is what. Because I know they are highly subjective. This is not an adversarial question, it's mainly used as an indicator to gauge where to direct the interview.

I like to interview people across a range of subjects (as I have not had the chance to hire a pure specialist). So knowing what they feel confident in answering will help me tailor the questions to what their perceived strengths are.

So I think it gives me a feel of your confidence level in a language. If you flipped through a "Teach yourself C++ in 24 hours" book once, then rate yourself a 10 on a scale from one to 10. Then not answering basic C++ questions will raise red flags.

If they answer a "1" on something. (And I re-assure them that answering 1 is perfectly ok). Then I can feel a lot more comfortable giving them more hints, or a lot more supporting detail in a question that they have indicated they are not very strong in.

Re: Interviewing candidates

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

Re: Interviewing candidates

#24
post #11
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…

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 scientific, yes.

Re: Interviewing candidates

#25
post #18

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

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.

Re: Interviewing candidates

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

Re: Interviewing candidates

#27

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…

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.

Re: Interviewing candidates

#28
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…

Do you worry that your brain is really, really good at reassuring you that you're making careful decisions? Mine is, and it makes me worry. I tried to design a process with that in mind.

Re: Interviewing candidates

#29
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?

Ah, but the company builds static analysis tools. Dinging someone for not knowing the minutia of languages makes a lot more sense when the minutia of languages is your business.

Re: Interviewing candidates

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

Post reply on HN