Ovid has a really good post on how to advertise for programmers, especially senior programmers. Here are a few extra points worth considering:
Hire Craftsmen, not Replaceable Cogs
The most important thing to remember when hiring a "top programmer" is that your goal is to bring a craftsman onto your staff, not a warm body that has a modicum of experience with a list of skills a mile long. A truly top programmer will have some exposure to most of the tools and technologies in common use, or will understand the fundementals behind those tools, or can ramp up by googling the relevant details for 10 minutes or so. Worst case, that programmer will spend a morning flipping through a couple of books to pick up the important parts, and refer back to the documentation as necessary.
Note that I said a "top programmer", not just "programmer" or "junior programmer". These labels don't have any intrinsic value, but the distinctions are rather important. A "top programmer" will see a new problem as a variation of a known problem while a run-of-the-mill "programmer" will see a new problem as genuinely new, and need to solve it from scratch from first principles. A "top programmer" may need to skim through a few pages of docs about some new tool to pick up the important bits, while a "junior programmer", lacking any deep background in the craft, can read docs from start to finish over and over without fully understanding them.
Show me the diffs
Ovid says, Don't list every damned skill that all of your developers have. I'll go further: when advertising an open position, highlight the parts that are most descriptive of the job. For example, when dealing with web-based development, you can assume that things like CGI, HTTP, HTML, XHTML, XML, CSS, templating, some database work, authentication and even a bit of JavaScript can be taken as given. In a web development context, the primary skill is going to be data munging, so generating output formats like RSS, Atom and occasionally images is just another case of data munging.
If, on the other hand, you are developing some kind of aggregation system, and you're looking for people who have a deep understanding of the corner cases of the various RSS formats, you need to do more than list just "RSS" as a requirement. Similarly, if your environment is high volume, involves big data high throughput, integrates deeply with mod_perl or needs to support a wide range of customer platforms, highlight those details.
Use Honey, not Methyl Mercaptan
A good developer can spot a bad ad in about one sniff. Listing a litany of minor skills an applicant must have mastered is one of many bad smells.
There are a lot of ways an ad can tell a potential applicant "this job sucks", so many that I don't think it's very useful to highlight them all. Better to write an ad that is good rather than one that avoids all known forms of badness. This may result in an ad that generates a lot of responses. Getting lots of responses is a good thing. If you're looking for the top 1% of programmers, better to get 300 responses and interview 3 candidates than put out a bad ad that gets 30 responses, all duds.
Yes, the added volume of responses can be a problem. Get over it. As an old manager of mine said, this is a good problem to have. Remember, you're looking for a rare programmer, so be prepared to cast a wide net.
May I ask what the problem with hiring a Cog is? If you have anything to say, say it!
