Hacker News Reader

Comment by chadaustin | Hacker News Reader

This is something I always liked about the IMVU hiring process. I wish I understood all the ingredients of the recipe, but somehow we managed to hire a diverse engineering team. Creative folks who just got stuff done, people who could find bugs deep in third-party dependencies, people who could design and build high-performance technology at scale.

I no longer work at IMVU, but the lessons I'd take away are:

- Hire based on passion and innate problem solving ability, not which specific technologies they know. (Except when you need to bring in specific expertise.)

- Have a fuzzy hiring process where people don't necessarily need to quantify a candidate.

- Take risks on people. We've had candidates who were a "no" but one person stuck their neck out and said "You know, I saw something special that none of you did, and I'd like to take a chance." Many times the candidates ended up being amazing, and it took that one person to see it.

View on HN

> Take risks on people. We've had candidates who were a "no" but one person stuck their neck out and said "You know, I saw something special that none of you did, and I'd like to take a chance." Many times the candidates ended up being amazing, and it took that one person to see it.

But don't forget the inverse. We had a candidate come on board recently who passed the interview with flying colors... Except for 1 person who essentially said the same thing. "You know, I saw something horrible that none of you did, and I don't think we should take the chance." And here we are, with a bad hire in a company where letting people go in general is a non-starter (which is another problem onto itself).

I think you are assuming the problem is symmetrical but it isn't. The cost of a bad hire is higher than the cost of missing a good hire.

People say this all the time, but I've never seen any explanation for it besides the quite shallow "bad people make bad code which someone has to fix" .. well yeah, and good people make good code which offsets bad code, so .. why should the cost of a bad hire (who you can fire in the first few month without any problems thanks to probation periods) be higher than the cost of missing a good hire who can - potentially - work for many years for your company and produce good solutions for a long time?

Spot on. Bad hires fall into basically 3 categories:

1) A bit worse than average, maybe 10-20% worse than their coworkers. They still add plenty of value and with good management and time can be improved. Just not quite the "gem" hire.

2) Clearly unqualified/unsuitable for the role. Easy to spot and you can let them go with a couple of months serverence. Everyone is happy. Total cost maybe 3-4 months wages.

3) Qualified but toxic. Has negative value and can destroy a team. Problem is these people can get through tough interviews anyway. Having higher testing standards does nothing to stop these people.

On the other hand a good software engineer, working within a company and framework that supports them can easily add $1,000,000/year to the bottom line.

I think the worse that can happen is the 3rd options, although I agree that we have no information about "How much bad is hiring a bad engineer"

When I'm asked about how I'd hire I always look for adaptability, creativity, communication, taste. Unless our goal is to find something really skilled on alghorithims or a specific language, it's just ok if they are curious, passionate, and communicate.

That said, I still wonder why we put that much emphasis on the language or the algorithmic skills when what we really care about is culture, passion, and helpful communication.

Maybe it's just me but I feel like searching for a more human skillset seems worthwile in the long term

Many companies in the US routinely fire the bottom 5%. If a company needs to fire a bad hire quickly, what exactly is the problem?

Given the choice of getting either both an equivalent of John Carmack and a completely overconfident, unskilled CS dropout on my team or getting neither, I know which I'd prefer. A great hire is worth far more than the cost of accepting a bad hire.

Even in the case the bad hire were completely untrainable and never managed to get anything past a code review, paying two salaries for the output of one Carmack-like outlier is still a bargain.

> a bad hire in a company where letting people go in general is a non-starter

This is your chance to institute good on-the-job training facilities.

"Bad hire" is a "hire" who requires more training than others (in whatever area they may lack, including human interaction). If you can manage to provide that person with effective training that salvages their status, then you had effectively created a training program that everyone else in the company can now take advantage of.

If you can't, well, it will turn out that the company lacks a vision vis-a-vis training. That is what makes a "bad hire" an "omg unsalvageable bad hire, run for the hills!" (i.e. it's a mark against the company, ot against the hire.)

I used to think this - then I worked with a coworker who just couldn't get it. He'd ask the same question 5-10 times. When the candidate just doesn't care, no amount of training can make up for it.

Sometimes the best training is to fire them, and hope they realize the consequences of not caring.

#3 is the one where you'll find the gems and where most conventional hiring practices will miss out.

Taking risks on people is something that carries visible downside for the one advocating the risky step and that's why it happens very rarely.

Reply on news.ycombinator.com