That should be an impetus to improve your hiring process, assuming it isn't a rare occurence.

> They probably had a job before they accepted your offer. Now they're unemployed and it's your fault.

It is not entirely your fault, unless you didn't effectively articulate what the job was. Otherwise, they took a job they knew was over their head.

> Firing people frequently is also expensive and it's demoralizing for the team.

See point #1. Firing people frequently is a sign your interview process is broken.

It's mostly your fault. You know what the job is and what your expectations will be far better than the candidate. You should be hiring only when you are confident that they will be able to do the job.

> See point #1. Firing people frequently is a sign your interview process is broken.

Yes, that's exactly my point. "Fire fast" as a strategy should not replace "hire well". Your hiring process is entirely messed up if your strategy is "tasks risks in hiring but fire fast".

Sure, if you made a bad hiring decision, you may need to fire someone. But your hiring process should in general be filtering out poor candidates.

Businesses either bias their individual hiring process towards false negatives or false positives, but no one has apparently figured out how to find the balance.

Firing people frequently after a short term of employment is a sign that the hiring process (interviewing is part of that, but perhaps not the problem part) is broken.

Firing people frequently but long after they were hired may be a sign of hiring process problems, but is more likely a sign of post-hiring working environment problems.

(Well, actually, in both cases those assume that the firing decisions are, themselves, justified in the individual cases; obviously, either of the above could be a sign that the firing decision process is broken, instead of some other process.)

I think it largely depends on how do you fire people.

If you just decide 'fuck it, he's out' than yeah, that's awful. But if you give a chance to correct the issues, and actually give the chance rather than imposing some impossible requirements with your mind already set, that's different. Sometimes you just need a little push.

>>> Firing people frequently is also expensive and it's demoralizing for the team

Not sure about the expensive bit (it's better to fire sooner than later if you're going to fire anyway), but also concerned about the morale. Unless that's a very rare occurrence for quite obvious reasons, it will no doubt demoralize the team.

There are few things more demoralizing for a team than keeping jerks around.

Unfortunately, jerks are an overrepresented demographic in programming.

Yes, sometimes you will need to fire people. But the strategy should be to hire the right people in the first place.

I agree that the latter version is wrong, but there is room to adjust how much you work on predicting future performance. How much of a jerk people are is one of the harder things to predict in interviews.

I get the feeling we're both speaking with previous unfortunate experiences in mind :)

In general, I tend to prefer people who are able/motivated to learn, as opposed to X years of experience in keyword Y.