4 ms·

People always say this, but is it true? It’s easy to fire someone. It’s really hard to find someone who can ship (something you won’t get from a whiteboarding c

People always say this, but is it true? It’s easy to fire someone. It’s really hard to find someone who can ship (something you won’t get from a whiteboarding challenge).

etse 8y ago
Seems costly to fire, not just because of HR and management process overhead. People are trying to build successful teams, and regular firings distract from goals, ruin morale, and create an unsafe environment.
- vonmoltke 8y ago
  Regular firings imply a pretty bad hiring process. There's a spectrum between "regularly fire bad hires" and "regularly reject good hires". Also, what evidence is there that these high-false-negative practices are actually reducing false positives by a significant degree? In these kind of threads I read the same arguments and assertions, with the same lack of evidence, as I hear from people trying to defend airport security theater. I should start calling these practices "interview theater".
rockinghigh 8y ago
Engineers who don’t perform well for extended periods of time tend to drain resources from the rest of the team. They require active management; laborious code reviews, they also introduce more bugs and contribute to less robust designs. As for firing, it is a painful process for a manager as it comes with a variety of liabilities and HR involvement.
theptip 8y ago
> is it true? In my experience (hired 10 engineers), yes. It's technically easy to fire people, but it's emotionally draining on the team and on the manager in particular. Every time you fire someone, the team's morale takes a hit, and if you were firing people often, folks would begin to feel insecure and you'd struggle to keep good engineers. Smart, good people want to work with other smart, good people. If you're constantly bringing in bad hires (even if you later fire them) then your good engineers will get fed up and leave. The net value of a bad hire can easily be negative, if you consider the high onboarding costs to get a new engineer ramped up and trained. (Of course, the very best engineers basically sit down and start coding as well as your existing good engineers, but these true outliers are by definition uncommon). Not to mention the cost of the bugs and rework that bad hires produce. If you use a recruiter, you're typically paying a large fee that you can get refunded after N months (details vary, 3 seems common), so you'd have to be making your assessment in the first N months; that's a lot better than trying to make an opinion on the first day, so if all of the above wasn't true, in the abstract, it would be great to be able to hire aggressively and fire likewise. However, good engineers balk at the concept of a "trial hire"; understandably, as personally I'd refuse to work somewhere that didn't have conviction that they wanted to keep me. I imagine the relative significance of these points varies between companies and stages; all of these points are from early-stage (<25 person company) startup life; YMMV. > (something you won’t get from a whiteboarding challenge). I agree with this point, though I think it's orthogonal to the question of false positive vs. false negative cost optimization.

People always say this, but is it true? It’s easy to fire someone. It’s really hard to find someone who can ship (something you won’t get from a whiteboarding challenge).

etse 8y ago

Seems costly to fire, not just because of HR and management process overhead. People are trying to build successful teams, and regular firings distract from goals, ruin morale, and create an unsafe environment.

vonmoltke 8y ago
Regular firings imply a pretty bad hiring process. There's a spectrum between "regularly fire bad hires" and "regularly reject good hires". Also, what evidence is there that these high-false-negative practices are actually reducing false positives by a significant degree? In these kind of threads I read the same arguments and assertions, with the same lack of evidence, as I hear from people trying to defend airport security theater. I should start calling these practices "interview theater".

rockinghigh 8y ago

Engineers who don’t perform well for extended periods of time tend to drain resources from the rest of the team. They require active management; laborious code reviews, they also introduce more bugs and contribute to less robust designs. As for firing, it is a painful process for a manager as it comes with a variety of liabilities and HR involvement.

theptip 8y ago

> is it true? In my experience (hired 10 engineers), yes. It's technically easy to fire people, but it's emotionally draining on the team and on the manager in particular. Every time you fire someone, the team's morale takes a hit, and if you were firing people often, folks would begin to feel insecure and you'd struggle to keep good engineers. Smart, good people want to work with other smart, good people. If you're constantly bringing in bad hires (even if you later fire them) then your good engineers will get fed up and leave. The net value of a bad hire can easily be negative, if you consider the high onboarding costs to get a new engineer ramped up and trained. (Of course, the very best engineers basically sit down and start coding as well as your existing good engineers, but these true outliers are by definition uncommon). Not to mention the cost of the bugs and rework that bad hires produce. If you use a recruiter, you're typically paying a large fee that you can get refunded after N months (details vary, 3 seems common), so you'd have to be making your assessment in the first N months; that's a lot better than trying to make an opinion on the first day, so if all of the above wasn't true, in the abstract, it would be great to be able to hire aggressively and fire likewise. However, good engineers balk at the concept of a "trial hire"; understandably, as personally I'd refuse to work somewhere that didn't have conviction that they wanted to keep me. I imagine the relative significance of these points varies between companies and stages; all of these points are from early-stage (<25 person company) startup life; YMMV. > (something you won’t get from a whiteboarding challenge). I agree with this point, though I think it's orthogonal to the question of false positive vs. false negative cost optimization.