[gonepostal]

Is it just me or is ignoring the interview process in favour of the firing process as poor as the opposite? The best method is to weight them about equal.

Have a rigorous interview process where you try to hire only the best fit. If the new employee is a failure, have the ability to admit you made a mistake a correct it. Best of both worlds.

Firing a new hire is not a cheap process and it does affect your reputation/company morale.

[jacquesm]

Absolutely true. I'm really surprised at the attitude of the article, it almost seems as though firing is seen as a replacement for a good interview process, and to shore up a lack of authority by instilling fear or showing 'guts'.

[pw0ncakes]

I think you need both. You need to detect, and rectify, problems as soon as they occur. It's much better to catch potentially badly-fit employees (which doesn't mean they're necessarily bad, but just not right for the position you're trying to fill) in the interview process. However, there are subtle problems (people who can't handle large projects, or who don't document code, or who interview well but are actually unethical) that can't be caught in the interview process at all.

This is oddly similar to the compile/run time distinction in bugs. You want to push as many of your bugs to compile time as possible (not-so-subtle plug for static typing) but it's impossible to have catch all of them in compilation; such is the nature of bugs. Similarly, you want to catch as many problems as possible in the interview process, but can't get all of them.