1. Not asking the candidate to do some code.
Really, they’re going to be programmers, there’s no better way to show their ability than… to show their ability.

2. Only ask specific technical/non technical questions.
Agreed, any good interview questionnaire will have a fair combination of specific questions and general questions.

The latter two I’d simply rephrase,

3. Plainly believe what the candidate says during an interview.
While you don’t want to automatically assume the candidate is telling the truth, you do them a disservice to assume they’re lying, simply take what they say with a grain of salt. This works both directions, someones the candidate says things they don’t mean, and sometimes they incorrectly state things they do.

4. Hire a programmer just because the estimated time for the selection process is over.
This is much much less a strict rule, and based more on the business needs. If your hiring for a big contract that has a very specific start date, hire A body to fill the spot, while you continue to hire for more, but if your hiring for an internal product with a flexible timeline, by all means hold off until you get the right candidate, its all relative. Basically wait as long as your project requirements allow you to.