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".

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.

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

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 bad employees come in and slaughter morale, stirring up conflicts between all other employees, and causing a wave of staff attrition. Twice.

> And poor candidates tend to be poor due to cultural and subject matter issues more than basic technical chops.

I wish this were true, but the amount of seemingly experienced/employable people I've interviewed in the tech industry who don't understand basic concepts related to their areas of experience/expertise is astounding. As an example I recently interviewed a person to join our operations team managing our VMware stack, who had worked at VMware as an engineer of all places, but could not tell me the difference between paravirtualization and full virtualization or the difference between a virtual machine and a container.

More than anything, it seems many people in the tech industry these days lack understanding of the fundamentals. It's great that you've written a RoR app that makes use of APIs, but if you don't know how HTTP works at least at a high level, how can you troubleshoot that API if you encounter an issue? How can you make intelligent decisions about building out the datastore for your system if you don't understand the CAP Theorem, the trade-offs associated with various data storage engines, and the relation between available memory and available IOPS capability and the TPS capabilities of your datastore.

People seem to have forgotten the mantra "learn to walk before you run" and have gone straight from being dudebros in high school to being full stack engineers or ops engineers without any time spent actually learning how a computer works. Many of the candidates that we end up interviewing have at least 10 years of experience, and still many fail to understand fundamentals.

"When hiring, you are not really concerned about letting a good candidate go. There will always be others."

... but STEM shortage! ;)

This REALLY gets into my nerves

Interview like candidates are a dime a dozen, then come whine about not being able to find good candidates

> There will always be others. It is far more dangerous to let a poor candidate in.

Lots of people say that. Are you sure? Obviously, if one treats people as "resources", and don't let them shine, that's almost true. But I've seen a few times already a single person completely transform the place they work at, sometimes even when not given a chance.

> I'm not making any hiring decisions at this point... So I'm not judging people's skill levels yet -- I'm looking for something in their history that tells me they are bringing more to the table than knowing how to code.

And what that one thing will be that's not a skill? If you (that looks at lots of CVs) don't have any preconceived notion of what you want, how do you expect the people that has this feature will include it on their CV?

It is far more dangerous to let a poor candidate in

Only if you're hesitant to fire poor performers, or your organization or legal environment make it difficult to fire them.