Hacker News Reader

Comment by jjav | Hacker News Reader

> What would you propose as an alternative?

Easy. Just talk to people as would-be peers. They want to find a role they can succeed in. You want to find someone who can succeed in the role.

I interview by just talking about their past projects (based on resume). You can't fake your way through a friendly technical dialogue if you haven't done it. (Pre-requisite: the interviewer must be technically competent. This is where many companies miss. Algorithm puzzles won't make up for it.)

Also it is important to describe the role and expectations in detail. Nobody (really: nobody) wants to get hired in a role just to be let go in six months. There is no need for elaborate whiteboard algorithm dances which discriminate against everyone who doesn't have the time to memorize every possible question. Just be up front about the requirements and let the candidate decide if it's a match. They know themselves better than you ever will.

View on HN

This would be my way of interviewing, at least for anyone who's not a junior.

What troubles me is that people will say this allows all your biases to run wild, but my feeling most of the time is that these biases will find a way to express themselves unless you remove humans from the hiring process entirely.

Especially when the company says they aren't necessarily looking for the most bit perfect compilable code or even that you output the optimal algo on first try. Rather they want to see how you think through problems. Well now you're back at a subjective assessment again which inherently can have hidden biases.

After failing several of these "let's see how you think" technical interviews, I've come to the conclusion that the way I think is deeply and fundamentally flawed.

> I interview by just talking about their past projects (based on resume). You can't fake your way through a friendly technical dialogue if you haven't done it. (Pre-requisite: the interviewer must be technically competent. This is where many companies miss. Algorithm puzzles won't make up for it.)

I absolutely disagree with this.

I've interviewed people who seemed incredibly impressive, both in terms of showing me actual past projects, and in their explanations of them. I've then gone on to give them simple programming exercies, the kind that people with far less experience take, and they've gotten nowhere on them.

I'm talking a two hour, "here's a computer, here's internet access, here's a setup environment, code this simple thing, which you could probably copy-paste from Stack Overflow / documentation". And they couldn't do it.

And what's worse - I'm pretty sure I could fake my way through most technical dialogues. I mean, not literally everything, but I could probably fake my way through interviews about most technical topics, and given a bit of preparation time, fake my way through most things. I mean, I could probably get caught out if someone was seriously trying to do it - but to the depth that most interviewers get, I can pass as experienced on most things.

This is what we do where I am now and it’s worked well.

You can’t pre-correct for some things, but you can for others.

Having someone speak in detail about their experience isn’t easily faked.

Having someone speak about their experience in brief and then giving them a “skill-testing question” as if they won the lottery can be gamed.

Reply on news.ycombinator.com