3 ms·
I would also add that (at least in heavily knowledge- and team-driven endeavors like software development) the right balance is that you should minimize bad hir
by joshyeager 13y ago
I would also add that (at least in heavily knowledge- and team-driven endeavors like software development) the right balance is that you should minimize bad hires as much as possible, even at the cost of missing out on many good people.
- semerda 13y agoHire fast, fire fast.
- marcosdumay 13y agoI'd completely side with the blog here, and arguee that hiring for experience time on a specific technology is a great way to increase the chance of a bad hire. Both you and raganwald are right, but the industry standard is a practice that looks like it was created to do exactly what it should avoid. No amount of generic complaining can offset that.
- raganwald 13y agoMy own experience with "X years of Foo" hiring is that for a time, I was quite knowledgable about Java and the JVM, having worked on some very successful Java development tooling. But all too often, I met with resistance when looking at Java opportunities because my résumé didn't have the right buzzword bingos for the gating process. I found it difficult to even get an interview with some companies! Thankfully, things ended up working out in my favour.
- raganwald 13y agoFor the sake of a constructive argument... If you woke up one day and decided to "hack" that problem by making it low-cost to do bad hires, what would you do? Would you run a company like open source, perhaps, with a lot of remote people? Would you pay feature and bug fix bounties instead of salaries? Would you change the way communication and knowledge is shared so that getting up to speed isn't a huge burden on the people who are productive? I think that the way most companies work, you're absolutely right that false positives are terrible. But that seems like a problem well worth tackling!