[bhangi]

I would say that a technical interview consisting of coding questions that test data structures and algorithms is about as standard as you can get. True that some interviewers will turn this into a hazing ritual, but hopefully there's some feedback mechanism by which that behavior can be discouraged -- a few ideas would be to have shadow interviewers or allowing candidates to submit feedback about the interview content and process etc.

IMHO, the ideal technical interview would be one where the interviewer is able to dig in deep into the candidate's experience and able to ask intelligent questions that reveal the candidate's technical depth. But this requires very strong interviewing skills as well as an appropriate technical background on part of the interviewer -- this will not scale.

The "audition project" is a non-starter for the reasons you mentioned and as you correctly point out, we have no evidence that it works in the large.

So back we are to the flawed coding interview. Like some wag said about democracy: it's a shitty system, but there's nothing better.

[tptacek]

I didn't say "standard", I said "standardized".

A standardized interview process is one where every candidate receives (roughly) the same set of questions, so that the company can look over the last 18 months of interviews, compare every candidate regardless of who gave the interview, and make observations across candidates.

A rigorous interview (for lack of a better term) is one where questions have either correct answers or quantifiable answers. "Best algorithmic approach" to a problem is usually not a rigorous question (unless the problem domain is very well defined and very well studied). But "number of valid algorithmic approaches offered" is, as would be "validated time complexity of best offered approach".

The idea that a tech interview should be digging deep into a candidate's background to assess their experience and derive intelligent questions that reveal depth is, I believe, the pervasive myth underlying all bad technical hiring. The people who conduct technical interviews are developers, not trained psychologists. Developers have a pronounced tendency to overestimate their own confidence in things like interviews. For lack of a more eloquent way to put this: developers suck at interviewing.

There's no better way I know of to interview devs than to have devs do interviews, because it takes a trained developer brain to accurately classify answers to useful tech questions (ie, "is this unexpected response incorrect, or is it a correct response that uses a more clever approach than the one we expected, or is it a correct response phrased in different terminology than we're used to", &c). You have to have devs doing interviews.

So the next best thing is to stop pretending that devs are capable of doing something that they're mostly not capable of doing. To me, that says "take a couple weeks to come up with a standardized interview that every developer will give".† Watch the responses to those interviews. Look at who those interviews select; if those people seem to be working out, stick with it, else adjust.

† One indicator I'm playing with: if anyone on your team looks forward to doing interviews, you're doing something wrong; for the interviewer, the process should be mostly very boring.