Hacker News new | past | comments | ask | show | jobs | submit login

It is rather unfortunate how little correlation most tech interviews have with their respective jobs. It's largely a lose-lose situation for everyone. Developers who could easily build great systems but aren't experts in graph theory get passed over while brilliant mathematicians who can't necessarily code get hired. Result? Companies simultaneously having to fire employees while facing a supposed talent crunch. Given that this hurts everyone, how did we even get into this situation?

Probably because the only person who doesn't lose from this is the interviewer: they get to have fun. Honestly, when you spend all day buried in code, it's fun to play with puzzles for a change.

Perhaps it's time we started optimizing interviews for hiring success rather than interviewer happiness.

Okay, but any specific suggestions on how to do that?

Start with a simple interview which simply checks that the person (a) has a brain; (b) is somebody you're comfortable working with.

Then do a short-term contracting gig (maybe just 1 day). If it works well, hire them.

Edit: clarify length which even the best people could do.

Generally speaking, high quality people won't take a short-term contracting gig. They are probably working elsewhere and don't need that level of uncertainty; they're looking for something better, not just anything.

Best people I know don't even give or take interviews.

They generally have a long history of awesome projects they have worked on, and they've built years of reputation through working on such projects.

And they just don't pick up any other project in any other company. They are pretty much clear about the best kind of problems they want to work on, and they don't wish to waste their time other than that.

Every time a company boasts about having a process to hire only 'A' candidates I chuckle. The 'A' or even 'B' candidates aren't even up for hire. The interview process begins with 'C' people.

Generally speaking, most programming position don't need to be filled by high quality people. There are lots of smart, reasonably competent programmers out there, but who don't have years of experience on their CV, whom are eager to learn and would happily take a day or two off for a chance to work at an interesting company.

Truly high quality people are generally known by their reputation and are headhunted rather than expected to answer job ads.

I'd hope that by that point I'd have sold them on my company enough that they really thought it was better.

Also, I don't think it needs to be a long gig. Maybe even just a day, which isn't much longer than the gauntlet of technical interviews some companies will put you through. Even that short period should be enough to see if someone works well.

Doing a day's contracting elsewhere would violate my current employment contract. (And I think strict adherence to the letter of the rules will be reasonably common among good developers)

Better might imply more freedom or flexibility, which short-term gigs could offer.

Sounds good except for every job opening, I get 40 resumes, interview 15 people and of those 5 look reasonable. Which of those 5 do I give the short term contract gig to? So you're back to the same problem.

> Which of those 5 do I give the short term contract gig to? So you're back to the same problem.

Ideally, all of them. It's not hard to find a couple one-off tasks that you'd like to see done in a day. Or could could proceed sequentially until you find one whose work you like.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact