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. :)<p><a href="http://sockpuppet.org/blog/2015/03/06/the-hiring-post/" rel="nofollow">http://sockpuppet.org/blog/2015/03/06/the-hiring-post/</a>
"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?"<p>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 <i>assessing</i> 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.
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.<p>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.<p>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.
"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."<p>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?
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".<p>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.
This was my thoughts on the matter: <a href="http://seshbot.com/blog/2014/01/24/the-best-way-for-programmers-to-interview-programmers/" rel="nofollow">http://seshbot.com/blog/2014/01/24/the-best-way-for-programm...</a><p>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!)<p>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.<p>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)
I also wrote a thing about coding interviews, from the employee side:<p><a href="http://www.developingandstuff.com/2015/05/why-i-dont-do-coding-tests.html" rel="nofollow">http://www.developingandstuff.com/2015/05/why-i-dont-do-codi...</a>
<i>"Second, what actually did they do on this project?"</i><p>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>I</i> did this", or "The team expected <i>me</i> to do such and such."<p>This is something a lot of potential hiring managers like to hear. If they have to ask what <i>you</i> did, many believe you're role or your work may not have been that important.
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.
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:<p><pre><code> Q: On a scale from 1 to 10 (1 being low) how do you rate yourself on "Programming Language Du Jour"?
</code></pre>
Then I can see if their self assessment is inline with mine. Which can help in reviewing the resume.<p>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.
> Leave the candidate with a positive impression of the company<p>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.
> if we make a bad hire, that can drag down the productivity of a team for years<p>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.
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.
Why not do 2 phone screens to filter out completely incompetent people and then let them choose:<p>- paid work for a week<p>- writing patch for a project or making simple tool(proxy of the job) and invite them to talk about it.
I don't really get it.<p>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.<p>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:<p>"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?"<p>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.<p>Much respect goes to tptacek that outlines a much better and enlightened alternative.
Here's how you hire a candidate, in two steps:<p>1) If they provide a github/bitbucket/sourceforge link, look at what's there. Skip step 2.<p>2) Literally anything else. It won't work anyway.