Live data from Hacker News

Interviewing candidates

ericlippert.com

11–20 of 85 posts

Re: Interviewing candidates

#11
post #6
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/

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 who aren't comfortable in high-stress whiteboard coding situations. The OP's process is designed around the assumption that the candidate can be made comfortable; tptacek's process is designed around the assumption that some candidates can't be made comfortable, but you shouldn't reject them (and in fact you may desperately want to hire them if you could find out how good they are), so you need to find another way.

Although the OP's article states that he is prepared to offer a computer for anyone who prefers it, how many candidates are confident enough to tell an interviewer that they don't want to do whiteboard coding? My experience is that candidates tend to be incredibly submissive during interviews so they're not going to speak up about something like that.

Based on the OP's article, I didn't get the sense that they have a rigorous rubric or that they meticulously record objective data points for every candidate to establish a reliable dataset over time.

All that said, I do feel that the OP's example question is pretty good (for that domain of expertise, at least) and better than what I typically see in these sorts of articles.

Re: Interviewing candidates

#12

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 learn more? Knowing that, the only possible individuals who would think about rating themselves a 10 are:

1) The language designers themselves. (Possibly not even - see the comment below about Bjarne Stroustrup)

2) Those that think they know the language so well that they would rate themselves a 10.

You're probably not interviewing people from group (1). (Or if you were, you wouldn't ask them this question as it would reflect more on yourself than the candidate) So, if someone rates themselves a 10, you can probably assume they are in group (2) or have otherwise misunderstood the question. I don't know for sure, but I feel there are better ways to rate a candidate other than asking them a question, that, if they answer "10" on, means they aren't suitable and are likely overrating themselves.

So where does that leave us? Most people who are comfortable with the language are likely to rate themselves a 6, 7 or 8, being conservative and not wanting to expose themselves to a tricky follow-up question should they self-rate too highly. Again - this seems to be leading toward gotchas, and seems adversarial.

If you're going to ask for the self-rating, at least limit it to something less fine-grained: Beginner, Novice, Expert/experienced/whatever, so you have an idea for the candidate's comfort level with a particular language. A 1-10 rating is way too granular (what's the difference between 3 and 4?).

But really, I think asking the candidate to rate themselves is really just a spin on the "What's your greatest weakness?" question - it's asking the interviewee to do the interviewer's job.

Re: Interviewing candidates

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

Re: Interviewing candidates

#14

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…

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

Re: Interviewing candidates

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

Re: Interviewing candidates

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

Re: Interviewing candidates

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

Re: Interviewing candidates

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

Re: Interviewing candidates

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

You could say that about almost any kind of knowledge-based evaluation.

If I ask somebody ten factual questions and they know the answers to five of them, how should I interpret that? Sure, it would be easy for me to just fill in those particular gaps in their knowledge. But assuming my questions were well-chosen, it's reasonable for me to expect that they'll continue to hit similar gaps in the future, about 50% of the time.

That's not to say that a good interview consists of drilling someone on facts; more often, they come up implicitly in the context of solving a problem. And as an interviewer, I'll look much more favorably on a candidate who recognizes what they don't know, because I give them the benefit of the doubt and assume that in a real-world situation, they would be able to do the necessary research. But even so, if there are basic things they don't understand, it's a red flag because it tells me they're encountering these concepts for the first time.

Re: Interviewing candidates

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

Post reply on HN