> Now if you send in a paper that has a radically new idea, there's no chance in hell it will get accepted, because it's going to get some junior reviewer who doesn't understand it. Or it’s going to get a senior reviewer who's trying to review too many papers and doesn't understand it first time round and assumes it must be nonsense. Anything that makes the brain hurt is not going to get accepted. And I think that's really bad.
-- Geoffrey Hinton
I've found that Hinton's experience with publishing holds doubly true for technical interviews, and am always surprised often people in tech refuse to question their own interview process rather than assume that everyone that doesn't pass it must be an idiot, independent of your prior expectations.
While it is very possible that someone who is a great writer on technical topics is not a great match for your team, I really don't believe that this person "knew crap" about programming. It is virtually impossible to write well about a subject you don't understand.
Again, it wouldn't surprised me at all that an expert on a topic might not be a good fit for your role, take Scott Meyers as an example. He's frequently admitted that he has little software engineering experience, and is not a software engineer. You should probably not hire Scott Meyers as a software dev. But if your conclusion after interviewing him was that he "knew crap about C++" I would read that as an implicit critique of your interview process, not Scott Meyers.
Based on my experience interviewing, the vast majority of data scientist interviewers would quickly write-off Hinton as someone who "knows crap" about data science because they very likely would not understand the answers that Hinton is giving.
Unfortunately, in tech hiring these days, true expertise is far more often then not a liability.
-- Geoffrey Hinton
I've found that Hinton's experience with publishing holds doubly true for technical interviews, and am always surprised often people in tech refuse to question their own interview process rather than assume that everyone that doesn't pass it must be an idiot, independent of your prior expectations.
While it is very possible that someone who is a great writer on technical topics is not a great match for your team, I really don't believe that this person "knew crap" about programming. It is virtually impossible to write well about a subject you don't understand.
Again, it wouldn't surprised me at all that an expert on a topic might not be a good fit for your role, take Scott Meyers as an example. He's frequently admitted that he has little software engineering experience, and is not a software engineer. You should probably not hire Scott Meyers as a software dev. But if your conclusion after interviewing him was that he "knew crap about C++" I would read that as an implicit critique of your interview process, not Scott Meyers.
Based on my experience interviewing, the vast majority of data scientist interviewers would quickly write-off Hinton as someone who "knows crap" about data science because they very likely would not understand the answers that Hinton is giving.
Unfortunately, in tech hiring these days, true expertise is far more often then not a liability.