>Why does your ability to handle that situation differ so greatly depending on whether it's an academic or professional setting?
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 don't really advocate that.
That goes a long way towards alleviating the problems that most people have with this type of interview.
> For his current job, he had to give a presentation to the entire interviewing team about his technical work at previous internships.
Talking about past experiences is completely different from solving problems under pressure. Almost all professions require this, and I'm at a loss as to why it's not good enough for software.
>There were some occasions when I even needed to deliver a 45 minute highly technical presentation to the class and that doubled as an exam.
Again not really the same thing at all. Delivering a prepared presentation is an entirely different issue. And if public speaking like this is required for the job, I see no problem in including it in an interview.
> by the nature of the profession, you'll be in front of the court eventually.
Yes, you said it, that kind of thing is an essential part of the job for lawyers, not so much for software engineers.
>plus they are observed extremely rigorously during labs and clinical work.
Yes this is true, but this happens when they are just starting out. No one is going to take a surgeon with 10 years of experience and force him to do an operation for an interview.
>It's not that regular of an occurrence, but it would be a sort of big deal if you were totally unable to act in that sort of situation. There would be a limit in what sorts of projects you would be given.
Again, I have never once encountered a situation where I had 15 minutes to solve a complex problem that had never seen before.
>Are you suggesting that you can perform well when you have someone helping you, but you can't when you don't? Or is it just an issue of social anxiety?
I'm not suggesting that. I do fine in technical interviews the same as I did extremely well on exams in school. However, even though I often made the highest grade on an exam, I hated every minute of it, and I feel the same way about technical interviews.
Here's the bottom line. I do fine in technical interviews, but they cause me more stress than they're worth to me. You may be fine with this kind of interview, but from the comments on hacker news a very large percentage of software developers are not. Many people hate them, and their predictive value is dubious.
The interview format I outlined is objectively more similar to the day to day work of an average developer. Studies have show that work sample tests are the best way to judge a potential employee. Why not strive for a better interview process?
It really comes down to this. If you can eliminate a section of the interview that many people dislike, which isn't critical to the performance of the job, and it will increase the tests predictive value, why wouldn't you do it? Do you want to hire people who are good at interviews or do you want to hire people who are good employees? If company A depends on an interview process for which 50% of otherwise qualified interviews will perform well on, and company B has an interview process for which 60% of otherwise qualified candidates will perform well on, which company will perform better in the long run?
Current technical interviewing techniques are demonstrably terrible. Their predictive power is terrible. The only argument is whether there is a better way to do it. I think there is.