[ng12]

And it's the totally right thing to do. Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Programming interviews aren't perfect, but the reality is there aren't better alternatives.

[danieltillett]

Bad hires are not disastrous unless new people are put in charge of critical projects. I continue to take chances on people who might not workout - sure I fire a lot (never fun), but I have also found amazing people that are overlooked by everyone else.

[vonmoltke]

> Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming.

Citation needed. I frequently see the dangers of false positives exaggerated and the costs of false negatives downplayed.

[ng12]

Aside from the monetary cost of hiring them, you're making the team less productive. Time is spent training, on-boarding, doing their code-reviews, and after all that it takes at least a few months of settling in to see how they actually perform. Tthere's also the opportunity cost -- whatever project you had hoped they could tackle is now months behind and at best all you have is some slapshod code you'll need to rewrite anyways.

Of course there are gradients to bad hires, but the really bad ones are a terrible experience for everyone involved.

[kafkaesq]

After all that it takes at least a few months of settling in to see how they actually perform.

It does? I find incompetent people are generally easy to spot. As in, almost instantaneously (or at most, within a few hours). It's almost as if they want to show you how incompetent they are.

But the "long-term" bad kind? Generally that's not incompetence, per se, but personality issues ("I only wanna do it this way", "I don't want to learn / won't work with people who use X or even don't look down on it like I do", "I just don't give a fuck this company or any of youse", etc). Which by nature are of course much more difficult to spot.

And which are a completely different (orthogonal) set of issues than those addressed... "this idiot didn't immediately see the dynamic programming approach which I knew about already because, of course, I picked the problem. Even when I stared at him impatiently and distracted him with hints" style of filtering which seems to be the goal of the modern hiring process.

[candiodari]

Have you ever been at a big company where you found more than one or two exceptions to "I just don't give a fuck this company or any of youse", and which one, because I'd love to submit my resume there.

Issue with interviewers is that they invariably think themselves smarter than they are. For instance, just because something has a linear programming solution doesn't mean it doesn't just have a closed form solution too (most software engineers that have interviewed me would say "closed what ?", I feel). I've found, often, on interviews that you have to lower yourself to the interviewers' level to pass. Even when the problem is not so much that the interviewer doesn't know the stuff at all, the problem may be that they don't know it well enough to have a thorough understanding of the problem without preparation (and they never prepare), so they simply can't deal with other approaches. Or they provide a "warmup" question that is ridiculously hard or easy, and don't deal well with the fact that you approach it very different from what they expect for the real question.

Very few engineers, even at companies that claim to be different like Google or Microsoft, truly have a mathematical background in algorithms. This does not seem to stop them from often smugly pointing out the "right" solution from a blogpost that happens to be flat-out wrong, ill-specified and handwavy, to a Math PhD. Putting any math on the whiteboard in such situations is a bad idea. Even just pointing out the flaws in their assumptions ... Constructing a proof that it's equivalent to a well-known problem with lower complexity than their optimal solution does not often end well, as they neither can nor want to understand actual algorithm theory. They don't know the assumptions they use, and never once have I known one to question if the assumptions apply to the posed problem.

[kafkaesq]

This confirms with a lot of my observation, also. For example, the modern interview process has tricked interviewers into believing that (armed with the right set of questions and/or hoops to be jumped through), they can "size up" the candidate. When at very best, all you can "measure" is the intersection of your backgrounds.

And about preparation -- it's not so much that they ask pretentiously hard questions sometimes. It's that their own level of preparation, correctness of execution and general forethought will only very seldom even roughly match what they expect the candidate to deliver. As in, they screw up all the time -- everything from picking the problem to stating the problem to stating true expectations (these are basically almost never stated) -- to simply listening to another person's perspective on it... to just watching the clock and their body language and tact in general. Yet candidates are almost always expected to deliver near-flawlessly.

As to big companies: I've found the solid majority to be quite considerate about others as human beings, generally (abstract questions about their company's impact on society or the environment aside). But as a general rule, the larger the company, the more the "not giving a fuck about this company" measure approaches 1 - uniformly and geometrically.

[Apocryphon]

Why shouldn't companies invest in training? What's with offloading job training to universities and to the applicants themselves? Yes, HN is a startup-focused site, -'d startups have limited resources. But large tech companies, or at least IBM, had historically trained engineers, at least in the 70s and earlier.

[munchbunny]

It's not that companies shouldn't invest in training, it's that bad hires will cost you more in training among other things and have little to show for it.

I would sooner invest in training somebody from the ground up, even straight out of college, if I knew that they had the humility to listen and apply their learnings to their job. It'll cost me team resources and it'll take time to get them to where I need them, but as long as I can find junior level work for them to cut their teeth on, I will take them over someone who doesn't learn any day.

The problem is that training is expensive, so I need to filter for people who will give me good ROI on training. I'm not afraid they'll leave. People who feel that they are learning a lot generally won't leave their job unless you're doing something shitty to them.

Which brings us to the common debate about how big the talent pool really is. On one extreme, you have the argument that competence is really rare and the applicant pool mostly sucks. On another extreme the applicant pool would be huge if companies would be willing to train employees. In my experience it's somewhere in the middle: there are a lot of okay people who can do certain jobs to a certain level, but most of them have an immediately visible growth ceiling because they are not as adaptable or reliable as they need to be, and as a manager it's very hard to give such a person more challenging projects to grow into.

Some of this is a managerial problem. Some managers are better at developing talent than others. Some managers are better fits for certain employees.

However, there are also employees that are just not reliable, or culturally toxic, or unable to deliver the level of results you expect for how much you're paying them. You pay the cost for such employees in taxes on team morale, project cohesion, and predictability of execution, all of them leading to projects weirdly taking far longer than they should and ending up far more complex than they needed to be.

So making a bad hire costs you much more than just the money you paid him/her. However, it's not clear that you have more to lose on a bad hire than you have to gain on a good one. That's how I ended up on the "fire fast" approach, but that had its own pros and cons.

[wyclif]

When I've asked this question in the past, the most common reason I've heard is that there's a fear, because of the prevalence of other companies poaching engineers, that money and time spent on training will benefit the company that manages to hire away the trainee (and sometimes a direct competitor).

[serge2k]

Do you have any actual numbers? Links to studies?

The rhetoric is that a bad hire is pretty much the worst thing ever, and it's used to justify absurd interview practices.

[ng12]

https://business.stackoverflow.com/blog/how-hiring-has-an-ef...

Several citations in there, but it seems like a common sense thing to me. Why interview at all if you're so willing to take on the risk of a bad hire? Just take them out for lunch and ask them how they like coding.

It's also bad for recruiting purposes. If I have an easy interview I'll be reasonably assured that my future coworkers went through that same process -- what metric do I have to assume they're going to be good engineers to work with?

[danieltillett]

Ask how many people have been fired. I like to think the people I have are all very good because I fire all the bad ones. Much better to weed out because of on the job performance than select on the basis of some poor proxy for on the job performance.

[shados]

really the only part that makes bad hires so bad is the impossibility to get them fired at most companies. Even if you hire someone and realize you've made a grave mistake thats obvious to everyone, some stupid moral value or company culture thing will force people to put up with it for 6 months, then have them be on probation for 6 months, then do an evaluation for 3 months, and by the time you finished the process to fire them, they quit first anyway.

That happened at multiple companies I worked at, both small and large, and it just makes me terrified to hire wrong.

If you're in an environment where you hire fast, but punt fast, you can give more people chances to prove themselves. Honestly, it would help with diversity, too. If people are as good as they claim, they don't have to worry about a thing.

[vonmoltke]

> really the only part that makes bad hires so bad is the impossibility to get them fired at most companies. Even if you hire someone and realize you've made a grave mistake thats obvious to everyone, some stupid moral value or company culture thing will force people to put up with it for 6 months, then have them be on probation for 6 months, then do an evaluation for 3 months, and by the time you finished the process to fire them, they quit first anyway.

That's a completely self-imposed cost. A company with a process like that has no business whining about the cost of bad hires.

[shados]

Legal issues aside (and those are real), there's the morality aspect to it.

Most companies I've worked for had people who thought firing someone was immoral unless they did something criminal. Essentially, its the company's fault for messing up in the hire process, and the employee should not have to suffer the consequences. So the employee stays in anything but the most extreme case.

Freagin sucks.

[jimmywanger]

> That's a completely self-imposed cost. A company with a process like that has no business whining about the cost of bad hires.

That's the consequence of deep pockets, unfortunately. If you're a young startup without much in the way of assets you certain can hire quickly and fire quickly. You don't have any asserts to sue for.

However, if you're a Google or Facebook, suddenly the stakes rise. They can always find a way to make the firing seem unjustified if they're fired on short notice, from ethnicity, gender, "culture fit" (I didn't want to go out for drinks with them), or age.

And it only has to work once for the disgruntled employee, and then they don't have to work for a while. And you better believe that a lawyer will take the chance to sue a large tech company on a contingency basis.

[ThrustVectoring]

It's a mixed bag. Not hiring good engineers will, ceteris paribus, give bad engineers more chances to luck through your interview process.

IMO, the key thing is that interviews are designed to give political cover for the interviewers to make the hire. If and when bad hires happen, the interviewer can say that their process was technically challenging, even if it did end up rejecting someone like Brendan Eich and passing someone who put 200 hours into Cracking the Coding Interview.

[eschutte2]

I disagree with this. You can get rid of bad hires easily. A single great engineer can transform your entire business.