Hacker News Reader

Comment by ramblinjan | Hacker News Reader

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)

View on HN

> 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!

Reply on news.ycombinator.com