I'm talking specifically about the "tasks risks in hiring but fire fast" strategy above. If your strategy is to hire without due diligence because you'll just fire later, that's extremely inconsiderate and also demoralizing.
Yes, sometimes you will need to fire people. But the strategy should be to hire the right people in the first place.
I think of it more as a continuum that either full due diligence or hire most anyone who seems decent.
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 :)
The only thing that makes this hard, is when you spend a month looking for a viable candidate, and need work done, and have to pick someone... The person isn't your ideal choice, but the best of those available. It'll work out, or it won't.
In general, I tend to prefer people who are able/motivated to learn, as opposed to X years of experience in keyword Y.
One of the few times I've outright quit a job without another on the table was because of conflict with a "jerk" (overt arrogance irks me) that had too much political clout in the company to overcome. Of course broken process in a larger company is almost as irritating.
There are few things more demoralizing for a team than keeping jerks around.
Unfortunately, jerks are an overrepresented demographic in programming.