[benihana]

>forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world

You've never once explained your thought process to a coworker? Explained how you arrived at a conclusion? Tried to elucidate your reasoning on a piece of code to someone?

These are absolutely real world skills and they are absolutely applicable when working on an engineering team with other humans. I understand what you're getting at in your comment, but it really feels like you're throwing out the baby with the bathwater. Can interviews be improved? Absolutely. Does that mean that there is no value in these kinds of interviews? I certainly seem to glean some value out of them. Whether that is the right value is a hard question to answer.

But I want to address something. Your whole comment is about why these kinds of interviews are shit. But you offer no alternative methods, no ways to improve these kinds of interviews, and really no constructiveness. You seem so sure that interviewing this way is wrong, but you don't say what's right. I would love to hear some realistic ways to interview people that can help me find better candidates without rejecting people because they're bad under pressure.

[personZ]

Explaining your thought process to a coworker after you've written the code is ex post facto rationalization -- you are invariably leaving out many side-tracks, many missteps, and get to condense down a long process into a simple, seemingly obvious explanation. You already see the route, and now you're just describing it.

Trying to do the same while you're trying to solve the problem, with a judgmental crowd scoring your comments, however, is an absolutely and completely different matter. Even thinking about how I would narrate my thought process as writing this reply ("maybe I'll talk about how I'd narrate the writing of this reply") is confusing enough.

I don't disagree with the concept of technical interviews, especially given that there are countless people who hold none of the skills they claim they have mastered. A process I implemented requires developers to come in for a coding test, where they are equipped with a development machine with full internet connectivity and a full toolset, and given a problem within their skillset to solve, alone in a closed office and for as much times they need. After the test we do talk through their "thought process" and their implementation choices.

I know this offends some people, among whom I'm sure are the people who completely failed to demonstrate even a basic knowledge of skills they claimed an expert level of competency at.

[pekk]

As someone who is very annoyed about interview process in general, I'm not sure what you think offends some people about giving them a realistic environment and time to work. What is annoying is when a false equivalence is drawn between stress and difficulty on some ad hoc interviewing task and "even a basic knowledge of skills".

[personZ]

I'm speaking more to the viciously anti-technical-interview sentiment that is so commonly seen on technology sites. While there are a lot of shops that do the whole process in a ridiculous fashion, similarly there are a lot of frauds among us: we have experienced such a number of people who claimed skills that they didn't begin to have, even when warned well in advance that they were going to be tested, told how they would be tested, and given a full ability to leverage the internet. Whenever those interviews ended, awkwardly, I always imagine them heading to Reddit or wherever to tell everyone how technical interviews are so much bullshit, and can't people just hire them on their resume, etc.

[curun1r]

The problem with these questions is the time scale in which they expect the answers. When dealing with a difficult problem, most people don't immediately come up with the right answer and adding in the pressures of an interview only makes it worse. As a development manager, I always ensure that my direct reports know all about the issues they're going to be working on at least one week in advance. I've found that the solutions they come up with are markedly better when they've had a full week of thinking time prior to writing any code.

The alternative interview technique that I like to use when hiring engineers is to send them the questions I'm going to ask a few days before the interview. I ask difficult questions, but there's no surprise. I don't really care if they talk about them with other engineers beforehand...there will always be follow-up questions that I ask to get them to defend their solution that will uncover those that haven't understood the problem fully.

[vishnugupta]

Being a person requires time to clearly think about a problem and gather thoughts I couldn't up-vote this enough. I just can't solve a problem when I know that someone is evaluating me right there and then. The way I go about it is to keep thinking about it at the back of my mind while I commute, eat, sleep etc., and then once in a while write pseudo-code or gather data to verify if a solution I'm pursuing works.

I was asked to come up with a recursive-like solution for puzzle like problem. I just froze during the interview. Later on kept thinking about it for couple of days and sure enough I was able to come up with three different solutions that used various techniques such as memoization and I felt really good about it.

I guess what I'm trying to say is it's really counterproductive to evaluate someone's abilities by subjecting them to time pressure.

[MachineElf]

I really love the arguments in the category "You criticize 'X' but you offer no real alternative, solution, etc..." as if you can only criticize something if you have the alternative solution at hand. This is not one of those questions with an easy answer.

"Boy you sure criticize those Nazis a lot for genocide, but you offer no _real_ solution." "Dude... stop criticizing those banks for their greediness when you have no solution". I realize these are rather hyperbolic examples, but you see where I'm getting at.

As for the OP, this does seems like really cool stuff, even if I don't really agree with "the interview" method myself because I don't do too well at them. I mean sure, there should be some on the spot questions to get sort of an outlook feel on the candidate, but that really isn't sufficient.

Why not give the the candidate a real world problem - maybe even related to something your company is trying to solve - and a few days to come up with a solution. I don't care if they also do some copy/paste from SO and other sources on the internet. That's why the interwebz is there in the first place. What would be more important in my view, is how the candidate is able to integrate all the information he finds - be it on the internet, books or his own head - and converge to a solution. And even if he doesn't come up with a working solution, you as an interviewer can now infer a lot more useful pieces of information than with a basic interview. You can ask questions like: 'why did you choose that library over the other ones?', 'why that programming language over the others', 'how did you come across the code on Stack Overflow; is it correct?', 'why that database and not that other one?', 'why is your solution single threaded and event based, rather than multi-threaded?', 'how would you further optimize that piece of code?' and so on.

I think this kind of conversation is something much more likely to happen day to day between the candidate and his coworkers if he does get the job.