[ambition]

"Gets-things-done" people prepare for technical interviews, such that they don't flub simple questions. The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers.

"Interview for Smart and Gets Things Done" is an accurate explanatory abstraction over what good interviewers do, but it's not prescriptive enough to tell people what questions to ask and how to judge the results.

[timr]

"'Gets-things-done' people prepare for technical interviews, such that they don't flub simple questions."

So, let's be clear: you're admitting that you're screening for a trait that you assume is correlated with the trait that you actually want. I don't grant the assumption, but it should at least be explicitly stated.

"The danger for the employer is that lots of Computer Science PhDs end up not writing much code during their research, and may not be a good fit at many tech employers."

How many computer science PhDs have you hired, let alone interviewed? I'd wager that it's not enough for you to be able to make this judgment with any confidence. And even if you're right, how does asking questions about linked-list reversal address the question of the tendency of a person to do practical work? Aside from tech interviews, I've never once in my life had to write a linked-list reversing routine.

Look, I'm not saying "don't ask coding questions" -- I'm saying that we need to start being reasonable. Don't assume that a candidate is a no-hire simply because that they haven't pre-memorized the algorithms for the questions that you're asking. It's ridiculous that we're screening people based on the number of silly tricks that they can memorize from interview question websites.

[ambition]

I think by and large we agree: It's wrong to expect memorized answers or to ask questions that are so narrow that they only test whether a candidate spent time studying. I'd even go so far as to say that algorithmic questions are probably not good indicators for skill at many kinds of work we would call "programming"---i.e. Programming skill is more heterogeneous than many interviewers admit. We shouldn't expect a jQuery wiz to nail low-level data structure questions, and we shouldn't expect a bit-twiddling video codec developer to really grok method chaining in 30 minutes.

The trouble with "Be reasonable" is that's it's the advice equivalent of a tautology. Of course we should be reasonable when interviewing. But I don't think there's widespread agreement about how to operationalize that. I'd be curious for more detail about how you would do it---you seem to have strong, well-informed feelings on this issue.

To my knowledge, there's basically no publicly-available research on tech interview factors and how they correlate with on-the-job performance. The good big employers do this research internally and keep it to themselves. The rest of us are stuck with assumptions, intuitions, logic and argument. So unfortunately I don't think we'll be able to get the debate into the realm of interpreting real data anytime soon.

[timr]

"The trouble with "Be reasonable" is that's it's the advice equivalent of a tautology. Of course we should be reasonable when interviewing. But I don't think there's widespread agreement about how to operationalize that. I'd be curious for more detail about how you would do it---you seem to have strong, well-informed feelings on this issue."

I think my primary argument is that it's basically impossible to assess "intelligence" at a 30-minute white-board session. There are too many other factors: thinking style, nerves, fear of speaking, etc. But most interviewers will flip the idiot bit if you don't answer their pet algorithm question quickly enough; it can be very difficult to come back from that kind of deficit.

It's usually pretty easy to tell if someone can't code -- you give them a straightforward problem (no "aha" moment required), and make them write the code. If you're really worried about it, give them a phone-screen problem that requires coding, then make them write a variant of the solution during the interview.

For "intelligence" testing, I like to give design problems, since they're far more representative of what will happen on the job. For these, I usually reach back into the grab-bag of recently-solved problems, and ask them to sketch out a solution, then iterate. If their solution is better than my own, that's a win. If it's the same, that's good too. If they just can't come up with something reasonable...well, we have a problem.

But note what you don't see here: there are no situations where I ask a question that requires a moment of algorithmic brilliance. That's just too random. Google can get away with that kind of stuff, because they get thousands of resumes a day, and can't possibly hire every good engineer that applies. For the rest of us, we have to be a bit more intelligent.

[riferguson]

If the job involves writing code, you're going to be asked to write code in the interview.

The "reverse-a-linked-list" question is an attempt at "minimal coding question that anyone should be able to do in 15 minutes at a whiteboard". It's an indicator, a mark of the ability to think on your feet and understand the basics -- think of it as the "pons asinorum" of programming. (cf http://en.wikipedia.org/wiki/Pons_asinorum)

If you're going to demand argument-from-authority, I've probably interviewed more than 200 PhD's for various positions over the last 30 years, and a statistically significant number of them were unable to pass a basic set of tests that history has shown to indicate the ability to function in an industrial-style software development environment.

Industry demands a different skill set than research; not better, not worse, just different.

[timr]

I wasn't demanding an argument from authority; I was trying to point out that your argument is just an opinion -- you're already arguing from authority.

" I've probably interviewed more than 200 PhD's for various positions over the last 30 years, and a statistically significant number of them were unable to pass a basic set of tests that history has shown to indicate the ability to function in an industrial-style software development environment."

What you're saying is that a "significant" number of PhDs (from a small sample that you have interviewed), have not passed the tests that you put in front of them. That's a long way from the argument that PhDs tend not to thrive in industry.

Ignoring the fact that you're begging the question (are your tests any good?), I would wager that a "significant number" of interviewees with any degree would fail your tests. The question is, do PhDs fail at a higher or lower rate? I very seriously doubt you have enough data to substantiate your claims about the industry-worthiness of people with doctoral degrees.