There have been references here to programming tests that are used to hire programmers. Even Joel has written about such tests. While that makes a lot of sense for new or intermediate developers, is it appropriate when looking to hire an experienced developer? Is this expected by such developers or would this process chase them away?
The market for programmers is what you can consider a market for lemons:
In short, a lot of people run around claiming to be programmers, but the knack for producing code (much less good, working code) is relatively rare in the population.
Testing is a dual edged sword. But is probably necessary unless the person comes in the door with proof (social or otherwise) that they can contribute working code and designs. Unless the hiring party knows as much as a suitable programmer-candidate, you can never be quite sure that your questions are adequate to determine their ability level.
Having sat on both sides of the interview desk I can assure you that it is exceptionally easy to snow someone with your "abilities" in a conversation.
Here is the downside of any kind of testing. The best developers and most senior ones will often be exceptionally turned off by the requirement to perform a test or an online skill assessment. Many won't consider it "fun".
One strong recommendation. If you DO implement a formal test, use someone else's or buy a test or use an online testing service. Do NOT attempt to write your own test. Virtually every "self created in house" test I have ever seen has been a terrible indicator of abilities.
You absolutely need some kind of objective "vetting" process in place. Here are my recommendations.
If you have a network and you find a developer via recommendation from someone that you trust, then you should not need to test them, depending upon their pedigree of projects. (see next paragraph)
If you have a candidate in hand via a placed ad or other general response, then they are an unknown, so they may need to be tested. If the candidate has a body of relevant work that they can refer to, and they can refer to clients for whom they did the work, then you should weight that heavily, and if the work is highly relevant, you should not need to test them.
(As a senior developer, the greatest turn-off for me in interviewing has been the client or recruiting agency to whom I would provide a list of relevant projects, recommendations, and past clients, and they insist on a test anyway. )
Lastly, you need a probationary period as a failsafe. Maybe consider something called a "contract to hire" arrangement. You hire the person as a contractor and either convert them to a full time employee after the end of a probationary period, or you release them.
In my opinion you should test each and every developer.
If you don't do, how do you know that he is an experienced developer? Do you judge based on the resume and his answers to somewhat unrelated questions?
The company I used to work for did not test some of the developers. They eventually ended up firing most of them four to five months into the job. That was when they realised, that at least parts of the resume was made up or their 'experience' was more likely a 'I watched the real developers do the things and fetched the coffee' type.
As for your concerns of annoying the prospective employee, I personally would not mind such a test, as long as it goes beyond the trivial or repeating buzzwords ("What technologies are you familiar with?" and the expected answer being something like "XML, C#, SOAP, REST, BDSM...").
In fact, I went to an interview for an internship at the development department of a very famous automobile manufacturer. The question that was most programming-related was "Which Design Patterns do you know? Please only state names, don't explain any." I turned down the offer after that interview.
So I think that developers will see those tests as fun - don't worry about it and do it.
As a senior developer I get anxious if a prospective employer doesn't test me, unless they know me or have personal recommendations. I've seen what happens when people talk themselves into positions, and I wouldn't want to work in such an environment. Since I believe I'm competent I feel secure in these tests.
I would also recommend against third-party testing. Their tests tend to be inane. Back-and-forth with a competent interviewer, including light coding, leaves me with a good feeling.
I believe that It is essential to test developers first before hiring. This will help you prevent hiring a person who does not know the job, which will also save you time and money when hiring. The best way to test developers is to start from the most basic tasks when screening so that It can give you an idea if the applicants are capable to do the more advance work.