Hacker News Reader

Comment by vonmoltke | Hacker News Reader

> When hiring, you are not really concerned about letting a good candidate go.

With that attitude, I hope you aren't complaining about how hard it is to find talent.

> It is far more dangerous to let a poor candidate in.

This gets parroted a lot around here, but with no supporting evidence other than highly improbable hypotheticals or black swan events. On the other hand, I know plenty of companies that have had to deal with poor candidates, from a Fortune 500 with 70000+ worldwide employees down to a small 12-person shop, and none have suffered serious consequences from these poor choices. Considering the lack of hard evidence supporting your statement, I believe these companies I am familiar with are the typical case and not "lucky".

View on HN

Here are some of the problems I had with previous employees that tighter hiring filters would have prevented. Now that my mindset is "don't hire the wrong person" instead of "hire someone", I don't have these problems.

- Developer who only worked when being directly monitored. Every feature he worked on was seriously late.

- Sysadmin who had good technical skills but was scared to give anyone bad news until it was so bad the project was in serious danger.

- Developer who stayed stuck at the same junior skill level for four years because he never learned from his mistakes.

- Manager who was too timid to hold his directs accountable, which both decreased team performance and demoralized the team members who cared about their jobs.

I was able to help two of them grow out of these problems, but it took a lot of work. I failed with the other two and fired them, but only after they had caused a lot of damage to productivity and morale.

I've seen many negative consequences from poor software engineers being brought into companies first hand.

I saw a junior engineer try to add a patchwork of libraries just because he was not confident in his ability to do something correctly, leading to a lot of maintenance overhead that grew very quickly.

Many of the previous frontend engineers got fired from my current company because they did not produce at all - a direct result is a polluted codebase that needs to be scrapped asap because it has led directly to poor perception of product. It also is extremely difficult to iterate upon.

One company I was at had some very terrible legacy code from full stack engineers. The person who wrote the code was fired as well, but not before leaving damage that persisted for years - some triply JSON.stringified JS object, along with some other extra parentheses, was stored right into the database as a string! This meant every time the data had to be fetched, it had to be parsed by the server to fill certain other data, but the core answer object was still sent as it was due to the difficulty associated with sending a parsed form (the backend was Java), which meant that the frontend also had to parse it! Thankfully we were able to silo the damage to an easy to adapt modular service, but it was the cause of much sadness, especially when it was a core piece of data for our product.

First off, thanks for providing some concrete examples.

That said, those all fundamentally sound like process problems to me. They would not have been allowed to happen at either of the companies I have worked for or any of the companies I have worked with, at least not to a degree that they would harm products. Sure, we have shit code down in the bowels of our libraries, and some of it was put there by people who didn't know what they were doing. I would not characterize any of it as serious problems, though. Those tend to either not live long or not make it into the codebase in the first place.

I understand there is a tradeoff here, and that "process" is a dirty word to many people. A little process can go a long way, though. It can make problems like those you describe minor or non-existent. To me this seems like a small price to pay for opening up your hiring process and dealing with the poor choices.

On a slight tangent and speaking of costs, I get the impression that many people discount the cost of a false negative. You are trying to hire people for a reason. Your company is incurring costs from not having this person, be it the lost revenue from expanding or the actual costs of working your current engineers harder to meet deadlines. That needs to enter into the equation, along with the costs of false positives and the costs of mitigating same.

Even though process is intended to mitigate the damage an individual can cause, in practice it's hard to have a good process without good people. Everywhere I've felt that a poor hire had serious negative effects on a company, those employees were also obstacles to bringing in a better process.

I agree with you that the cost of a false negative must be considered. The kind of bad hire I'm thinking of here is a net negative producer that actively costs the company money (or even causes good employees to leave), even after they're gone (if you can manage to get rid of them).

I agree that good process is of vital importance. At one of the aforementioned companies, there was little process. At another, they appeared to have near mastered it (some issues, but overall exhibited excellent leadership & management). At one, the process is seriously broken.

I am starting to feel that if there is some bad code that does some longer term damage, the managers are at fault.

>I saw a junior engineer try to add a patchwork of libraries just because he was not confident in his ability to do something correctly, leading to a lot of maintenance overhead that grew very quickly.

That's why they're called junior and they get paid less. They're meant to be supervised to some extent. If the problem is only caught long after the damage is done then the issues run deeper than the capacities of a single junior engineer. Junior is just a nice way of saying inexperienced. Experienced != good, but inexperienced almost always means some degree of bad.

Why did the damage persist for years? Seems like that problem could be fixed fairly quickly.

It is too bad when someone writes less than optimal code, but on the other hand, did the software work? Did it make the company money? If so then it was a success, regardless of how bad the code looks. Often times in business you have to hack together something that works now, and worry about re-writing it later. It's easy with the benefit of hindsight to look back and say how things should've been done differently.

I've seen bad employees come in and slaughter morale, stirring up conflicts between all other employees, and causing a wave of staff attrition. Twice.

Reply on news.ycombinator.com