Orthogonal to the app being a cool way to do interviews, am I the only one perplexed by the example this person chose to highlight problems with coding interviews?
If I understand correctly, they hired someone who seemed to have a good grasp of algorithms but when it came time to code, took forever to write code and took forever to type something out?
Isn't that the exact thing that code interviews are good for? Finding out if someone can write legible, working code quickly?
Code interviews are terrible for finding out if someone can do deep thinking on a very difficult problem over a long period of time, but the exact problem scenario this hire had should have been caught.
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 keep someone similar to the 'candidate' referenced from slipping through.
I'd also argue that bootstrapping a project is very different than managing a great code base. I'd be very skeptical of the idea that evaluating someone's toy project tells you how well they'll do in a massive code base.
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.
>I was suggesting good engineers may be being filtered due to duress in the interview being caused by poor tooling.
Ah, well said, and I agree. If I don't have Vim keys I'm about 5x slower, so I can imagine how someone used to a certain setup is equally handicapped in an artificially constrained interview process.
If I understand correctly, they hired someone who seemed to have a good grasp of algorithms but when it came time to code, took forever to write code and took forever to type something out?
Isn't that the exact thing that code interviews are good for? Finding out if someone can write legible, working code quickly?
Code interviews are terrible for finding out if someone can do deep thinking on a very difficult problem over a long period of time, but the exact problem scenario this hire had should have been caught.
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 keep someone similar to the 'candidate' referenced from slipping through.
I'd also argue that bootstrapping a project is very different than managing a great code base. I'd be very skeptical of the idea that evaluating someone's toy project tells you how well they'll do in a massive code base.