Hacker News Reader

Comment by joker3 | Hacker News Reader

There's a problem here. The only thing that Triplebyte can claim based on their data is that easier programming questions are more predictive of performance among candidates who received an offer. Since candidates who get offers are (in theory) different from candidates who don't get offers, we can't necessarily generalize from one population to the other.

There's also a question about how to mix question difficulty. Should you ask nothing but easy questions, or is it good to throw in a harder question or two to see how the candidate reacts to something they can't answer? I can see a good interviewer getting a lot of signal out of that, but in the hands of a bad interviewer it would not work well.

View on HN

You touch on a very important part of this equation: there are good interviewers and bad interviewers.

A good interviewer, in my opinion and experience, will try to get to know the person first. They'll put the candidate at ease. They want to try as much as possible to be talking to the person they're possibly going to be working with, not the anxious candidate that just walked into the room.

i am interviewing this week. at the end of the interview i ask the candidates how they felt about the interview process. i was mostly interested in finding out how they felt about having to do live code challenges while i observe them. (i let them "play" elevatorsaga.com for an hour and then implement a small project of their choice from freecodecamp)

yesterdays candidate told me he felt very relaxed, much different from all the other interviews he was doing.

and yes, figuring out if i want to work with this person is my primary goal.

Yep. Lot's of "data analysis" without even defining what would be a "false positive" (someone who did well in an interview, got an offer but turned out to be a bad hire? how is TB exposed to that critical data exactly?)

It wasn't clear at all in the article what it even meant when it referred to "final outcome".

IIRC, TripleByte only gets their finders fee once (if) the candidate makes it through 3 months of employment.

(Of course, you can argue that 3 months of employment isn't enough - but it's a lot more performance data than a bunch of interviews gives.)

If a "bad hire" means fired before 3 months...

Then I really have to question exactly how they did this analysis. I can't imagine most companies would have the same objective function.

i wonder about the definition of "easy" vs. "hard" questions. it seems to me that this is problematic. i mean, is there a well accepted mapping of all computer science related questions to a numerical difficulty rank?

i mean what if we did that for math? some people would be good at geometry questions, others at algebra, others at topology, real analysis, etc.

what if some great geometer interviews with a fanatical algebraist and then fails to make the cut? this candidate is a great geometer! were the questions "too hard"?

Reply on news.ycombinator.com