3 ms·
One thing I've been wondering for a long time when I see the quasi-sado-masochist relationship between engineers and hiring processes is: are bad hires that 1)
by dudul 8y ago
One thing I've been wondering for a long time when I see the quasi-sado-masochist relationship between engineers and hiring processes is: are bad hires that 1) costly, 2) frequent ?
In my 12+ years career, I've worked with so-so engineers, but never truly bad ones that would ruin a project. And even the ones that weren't great, what damages did they really cause? I've seen many more companies failing because of a bad product, bad sales strategies, bad market fit, bad business model than engineering teams using the wrong programming language, or not building microservices the right way.
I find this constant obsession around identifying "rockstars", avoiding "bad" engineers at all cost to be truly unhealthy.
- gregcrv 8y agoYes, and these people: "bad product, bad sales strategies, bad market fit, bad business model" never get "tested" on anything during job interviews.
- mratzloff 8y agoI strongly agree. A good engineer can compensate for bad product management and occasionally bad leadership, but can't do much about all the other things you listed. There's no way to guarantee a successful engineering hire, but organizations try to because their culture is so blameful or fearful of conflict that all the incentives are misaligned. I believe most organizations copy the Google, Facebook, etc. hiring processes with the goal of adopting an "industry standard process" because they don't know how to conduct an interview process that's tailored to their own organization, and they don't want to think too deeply about it. Having a coherent interview process means dealing with your organizational baggage: understanding it and either resolving it or crafting the interview process to select for people who can integrate well with it. Usually it's the latter, since most of the issues start at the top. Google, Facebook, etc. have spent a lot of time and money crafting a good interview process for their organizations: specifically what they value and don't value (even if the individual interviewers aren't always fully aware of what the organization is selecting for). They can also support a lot of false negatives. But the copycats don't have those same needs or candidate pool, so it always comes across as a bit disconnected to me.
- rightbyte 8y agoLet's define "bad" as the second worst to forth worst engineer in your class of 30 engineering students that made it through. I would say bad engineers tend to know they are bad and either tend to go into managing, coordination roles or grab a subset of tasks they get good at, like being the only one on the company working with eg. a specific third party system and doing support and integration for that. Bad engineers that have worked with the same system for three years are way better with it than super-engineers that have never touched it for at-least a couple of months. As you said, I have never really had problems with bad engineers messing things up. EDIT: Reluctance to hire engineers and saving pennies for a dollar on the other hand have messed up some projects.
- webmaven 8y ago> Bad engineers that have worked with the same system for three years are way better with it than super-engineers that have never touched it for at-least a couple of months. It's when that bad engineer starts protecting "their" turf at the expense of the rest of the org in order to provide themselves with job security that things start to really go south.
- rightbyte 8y agoYe, but not really a big problem where I live where it's a lifo que for firing people. On stack ranking US corps on the other side the Atlantic I imagine it's another story ...
- eshch 8y agoit's very easy to realize how it can damage or ruin a project. it reveals once you need to implement a big feature to address some new business needs that can be critical for the company to survive. you have large code base and you should not break something. the clock is ticking, the rivals don't sleep, the market doesn't wait. or you can just waste all the time firefighting with consequences of bad software. it's not the only factor, but it can matter. the majority of companies i worked suffer from this. what really mitigates the problem is that competitors have the same problem on average.