| > I didn't say it did. But just because something happens in a university doesn't make it the optimal way to conduct an interview. I honestly think you're sort of dodging the question here, maybe not intentionally. > I'm at a loss as to why it's not good enough for software. Probably because you can say anything you want to impress people, which means that as an interviewer you can't really trust anything they say and must probe them very deeply about any work they've claimed to have done. At that point it's already a sort of technical interview. We actually use a mix of this. We don't require a formal presentation but one of the interviews involves having the candidate discuss past work in detail. We definitely would not feel comfortable eliminating coding interviews on the basis of that one interview alone. In the past, we've hired some people on the basis of things like this, ignoring poor results on the technical screen, and those have been our worst hires. > No one is going to take a surgeon with 10 years of experience and force him to do an operation for an interview. Well, a surgeon's literal every move is being observed during every single operation. And to get to that point, the surgeon was basically subjected to excruciatingly rigorous daily oral examinations for 5-7 years during residency. > they're predictive power is terrible. Honestly, we haven't had many issues with it, so I don't know that I could agree it's terrible. Actually, and I'm not exaggerating here, every single one of our worst hires has come from giving somebody the benefit of the doubt when they didn't do well in the technical interviews. --- At the end of the day, I agree with you wholeheartedly that we need to find a way to improve the interview process. I just don't think the current process is that terrible, especially when you get away from large, lumbering places like Google and look at smaller, more forward-thinking companies. Google has absolutely zero ability to adjust to specific candidates. I understand your frustration with being experienced and still being subjected to technical interviews on BFS or whatever. It's annoying and sometimes even insulting, and in the worst case it demands that you go spend an inordinate amount of free time brushing up on interview material that never actually shows up in the real world. So I'm very much with you on the inadequacies of the current procedure; I just don't think it needs a drastic alteration. I think replacing whiteboards with actual computers, algorithmic brainteasers with real-world problems, and extreme timeboxes with more open-ended formats are the main changes that are needed. Just let someone sit at a computer and write a program to do something fairly common. And don't stare them down while they do it. I really, honestly do not think this is that unfair or crazy. It seems a lot simpler than and just as effective as doing a pair programming event where you have to make sure that both people have not seen the particular task before, which basically means the interview will have to be completely customized for each candidate. And that's not necessarily a good thing -- it means it's pretty hard now to compare two different candidates. |
If it works for you, then it works for you.
The one thing I know for sure is that peer reviewed studies over the last 50 years show that work sample tests are the absolute most predictive tests you can perform.
If what you're doing is as close to a real work sample as you can reasonably get, then you're probably doing better than 95% of companies. And from your description of your process it sounds like you are.
>It seems a lot simpler than and just as effective as doing a pair programming event where you have to make sure that both people have not seen the particular task before, which basically means the interview will have to be completely customized for each candidate.
The pair programming isn't necessarily essential in my opinion. The essential part is eliminating the artificial adversarial and timeboxed nature of the traditional whiteboard interview.
>it means it's pretty hard now to compare two different candidates.
That's actually a pretty key insight. The practice that many companies have of allowing interviewing engineers to use any problems they want is completely opposed to this.