Hacker News Reader

Comment by CoolGuySteve | Hacker News Reader

Where does this assumption come from that rejecting the majority of candidates leads to better results? At some point you're just cutting into the bone and rejecting candidates that are perfectly acceptable.

The more candidates you reject, the more time you waste and the more people come out of your interview with a negative experience of the company.

These costs can easily outweigh the cost of a bad hire. Nobody writing these blog-anecdotes even quantifies what that cost is.

At the end of the day, programming interviews seem more like hazing than anything. No other profession hires with a full day oral examination. It's fucking ridiculous.

View on HN

It depends on your definition of "perfectly acceptable." Almost every job in every industry with a hiring cycle rejects "a majority of candidates," especially when there's limited space.

> These costs can easily outweigh the cost of a bad hire.

How so? You're right that I've relied a good bit on the anecdotal, but aren't you doing so a bit here? Bad hires are ridiculously costly--especially on a small team--because they aren't just expensive. On a good team, almost every new hire lowers everyone else's productivity initially.

Hiring more people because of loss aversion also falls prey to the trap of "more people = more productive" that's been pretty thoroughly debunked in the software industry (http://a.co/3ierKnl)

> Hiring more people because of loss aversion also falls prey to the trap of "more people = more productive"

Although perhaps true, I don't really see how this is relevant to what CoolGuySteve said.

CoolGuySteve isn't recommending anything about the number of people that are hired for a particular role, or the rationale for picking that number. Rather, he's just observing something about the cost of being overly picky about the previously fixed number of people that are hired for a particular previously fixed set of openings.

I'll have to think some on this. I really was not trying to take the brutal "we only hire the best" nonsense that a lot of companies do.

You don't always have a fixed number of positions.

Often it's "we could really use more people, but only if they're better than [some level]".

> Bad hires are ridiculously costly

Here's a serious question. Please make an effort to think about it and come with an answer for your company: What is a "bad hire"?

Isn't my original blog post at least a little bit of evidence that I've put a good bit of time into thinking about that?

I mean, a "bad hire" with the consulting/open source shop where I did a lot of interviewing & hiring was something pretty specific. A bad hire where I am right now is something pretty specific.

Hum. Didn't read the usernames.

Too much theory and not enough actionable advice.

You know what. I'm just gonna talk candidates 30 minutes about them, us, me, the company (just talk, not any sort of test). Then I'll ask it to write a program to print number from 1 to 10 (that will be the test). And finally flip a coin before I take a decision (that's the randomness).

I'm pretty sure it follows none of the good practises or advise out there. Yet I'm confident that this is a process that has a low risk of accepting bad hires and a low risk of filtering good hires. =)

It's really really hard to come up with explicit actionable advice when a core part of your argument is that you need to do what is right for your team/company. To extend my TDD analogy, it would be like trying to write tests for someone else's codebase without any context.

If you want some specific feedback for your team, please reach out to me on Twitter. I'm always thrilled to talk to people about process and organizational development. I'd love to chat with you about actionable ideas for your specific need.

I agree to that. The hard part of hiring is that it is a lot of customization for the specific environment of a company.

Hence my message. Talking about his past and future career, mine and the company's plan is the best thing for me to do, because I'm pretty that the other interviewers have not talked much about that, if at all.

And I'm confident that the hardcore technical interviews have been done. They don't need me to make it harder, except for a few select senior candidates. A for loop in a few languages written on the resume is enough (and it's fun for candidates who have "assembly") :D

Someone who writes code bad enough that the maintenance costs of the code outweigh the cost of employing them to write it.

Of course this is often an organizational issue more than a hiring one, but we seem to have given up on fixing those.

There's also the cost of impact on a team, etc.

Shameless self-plug, though, for another post I wrote about organizational process: http://ramblinjan.com/development/2016/07/05/Going-Agile-Whe...

I definitely haven't given up on fixing those. I just, uh...I have a lot of feelings.

We suffered one, he was on a two man team. Reviewing his pull requests took at least a day, which were effectively rewrites by the more experienced dev.

We eventually had to let him go, but the technical debt remains. For example, tests that mock everything so that they didn't actually exercise any of the code!

Other professions hire based on pedigree and looking+sounding the part. I personally prefer a hard skills test.

But of course I would, the latter scenario favored me much more than the former when I was not-yet done with college, and also when I was looking for my second job in a new city.

There's always some complaint in these kinds of threads about whiteboard coding. I love whiteboard coding! I did it a fair bit outside of interviews, just to collaborate with coworkers, in my first and second jobs (but not recently). I did it in Google interviews. (No, they didn't ask any puzzlers about manhole covers or blenders.) It was fun, I'd do it anytime.

How much whiteboard coding do you do once you are hired? I'm not talking design but actually writing a sort algo with all the curlies in the right place, on a whitebaord?

Not much, maybe once a month. One thing I vaguely recall is the sequence and error handling of some service caching, writing to a database, and putting a message on a queue. Obviously it wasn't about "curlies in the right place". And as mentioned, it wasn't recently, it was about 3 years ago now - the most recent team I work with is very small and half remote.

I still think there are things that are good to be able to do, even if you don't use them regularly. As a bad metaphor, swimmers do some dry-land training...

Do interviewers actually really care about the curlies being in the right place? I've never interviewed in the US, but certainly every interview I've had in Europe that required whiteboard coding only required essentially pseudo-code that looked more or less like the target language.

I don't understand why everyone is ridiculously tough on interviews but wimps with firing.

Just do a 1 year probation, and payout a couple of months severance with an NDA/non-disparagement clause. If the guy sucks, send him off.

When I read these threads I'm always blown away by the time wasted on the hunger games hiring process. One guy on another thread was talking about 5 interviews with homework. What a waste of time.

It costs a company a lot more to hire someone and then fire them, than it does to never hire them at all. Especially if you give them a few months' severance. That's the most generous probation program I've ever heard of.

Only if you demonstrate that this torturous process produces better candidates.

How many FTEs worth of time is spent on interview hunger games?

It's not just those costs. The real cost is the phenomenal candidate you do miss. If engineering talent follows a power distribution, as I believe it does, then a single mistaken "no hire" can mean more productivity than the all the rest of your engineering hiring for the quarter.

Perhaps this is why Ben Horrowitz made such a strong case that for key roles you should, "Hire on strength, not on a lack of weaknesses."

A phenomenal candidate can leave pretty easily, too.

But when I'm taking about not being afraid to make a "no hire" call, I'm not talking about the incredibly strong candidates. They tend to shine pretty well if you don't have a hiring process that is difficult for the sake of being difficult (e.g. brain teasers and whiteboarding). When I talk about not being afraid to dismiss someone, I'm talking about the (perhaps admirable) human urge to give an underwhelming candidate another shot.

>No other profession hires with a full day oral examination

When I was looking into pharmaceutical jobs, before I got into the tech industry, many of my inteeviews were all day affairs. Sometimes 5 or so interviewers would all come into one room and start bombarding you with questions, putting your answers down, play good cop bad cop, etc.

Reply on news.ycombinator.com