3 ms·

If you take 10 people, they will give you 20 kinds of interviews they prefer. You can't make a perfect kind of interview. I can already see people bitching abo

If you take 10 people, they will give you 20 kinds of interviews they prefer. You can't make a perfect kind of interview. I can already see people bitching about your proposal: - it's too long - coding along with another engineer is unrealistic - it's close to impossible to scale this out to a number of interviewers as there are no strict scoring guidelines - it's too different from what other companies do - it's trying to outsource some of the problems your company has - it's too technology specific - candidates who know the domain will have an advantage - candidates who know your tools will have an advantage I'm not saying these are sensible arguments, but you will hear them against all and any kind of interview you can come up with.

hnfong 3y ago
"The ideal candidate is somebody deeply familiar with the tech stack we are currently using, preferably having spent at least 6 months working on our code base." Seriously though, the performance of an interviewee in such conditions are mostly a function of how well the interviewer can "onboard" the interviewee within 4 hours, or how much the interviewer is willing to actively guide the interviewee to the solution (as opposed to letting them figure it out). Even with a single interviewer this easily introduces bias. I've interviewed many many people over the years, and sometimes I wonder whether I'm giving slightly more hints or less hints based on how subjectively I "like" the candidate. I mean, I try hard to be fair, but I don't follow a strict script, and the variability occasionally makes me doubt myself. For such open ended tasks as 4 hours of essentially pair programming, I don't know how any interviewer could be objective and fair. Especially presuming that you wouldn't be re-using the same task once it's actually been solved/fixed... (otherwise that's just another artificial problem)

hnfong 3y ago

"The ideal candidate is somebody deeply familiar with the tech stack we are currently using, preferably having spent at least 6 months working on our code base." Seriously though, the performance of an interviewee in such conditions are mostly a function of how well the interviewer can "onboard" the interviewee within 4 hours, or how much the interviewer is willing to actively guide the interviewee to the solution (as opposed to letting them figure it out). Even with a single interviewer this easily introduces bias. I've interviewed many many people over the years, and sometimes I wonder whether I'm giving slightly more hints or less hints based on how subjectively I "like" the candidate. I mean, I try hard to be fair, but I don't follow a strict script, and the variability occasionally makes me doubt myself. For such open ended tasks as 4 hours of essentially pair programming, I don't know how any interviewer could be objective and fair. Especially presuming that you wouldn't be re-using the same task once it's actually been solved/fixed... (otherwise that's just another artificial problem)