Jason (article writer) here on my normal ycombinator account. > but the exact problem scenario this hire had should have been caught. I think if people weren'

Jason (article writer) here on my normal ycombinator account. > 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.