> but the exact problem scenario this hire had should have been caught.

I think if people weren't taking courses specifically training for engineering interviews, and common interview challenges, maybe this wouldn't be a problem. The truth is gamified programming challenges (commonly used for interviews) do not have a strong relationship to actual day to day programming skills, like reading code, understanding documentation, and doing research.

I suppose I'm just reiterating your point, but I'm not sure why you come to a different conclusion regarding the person I hired being slow reading our code, doing research, and setting up basic tooling being something such an interview process would weed out.

It didn't, and hasn't like I said, any more than a coin flip, in my personal (anecdotal of course) experience.

> I'm not sure how having them write/debug some slightly more complex code in IDEA vs an online Vim approximation is going to suddenly catch people like this?

It won't, if that's all I was suggesting.

I was suggesting good engineers may be being filtered due to duress in the interview being caused by poor tooling.

The real focus was having them do a small semi-real project of some kind, and then having a solid engineer pair-program with them.

This has proven to be a successful strategy for us.