Nearly every developer is a diamond in the rough in some way; rarely is a new employee a perfect fit for the job, even when their resume says so.  I think this happens for a few reasons:

1. Resumes (and sometimes even blaring overconfidence) exaggerate most candidates' skills.  Most often, it's because they knew how to pull every handle and turn every knob at their last job, so they must be an expert... when, in fact, they were just experts at their last job.
2. Your job opening is almost never the same as their last job.  Unless you're hiring laterally from another department or absconding an employee from a direct competitor (who has the same platform and build process as you), your job will have unique requirements and being productive in that job will require implicit knowledge of how your company or department operates.
3. "Perfect" is a subjective mix of wisdom, efficiency, insight, overall productivity, communication, and socialization.  It's impossible to be Perfect on Day One, if not Year One.

Recognizing this, I try to keep an open mind when hiring new staff (which I've been doing tirelessly for the past two months).  There are really only a few traits I key-in on:

1. Appropriate level of knowledge for the platform.  I've been hiring for a .NET developer with a modest SQL background.  I don't particularly care if their experience is in C# or VB[.NET], I just care that they've had solid experience with the framework itself, which is an immense geography of 2500+ classes and tens of thousands of functions, so in particular the parts that we use most (data and IO).  I check mostly for awareness and a keen sense of what's-what (like the difference between Inherits and Implements).
2. Good programming.  Beyond linecoding, being a good programmer means that you know how to back up, consider the bigger picture, and write what needs to be written (and nothing more).  God bless those uber-efficient linecoders who can churn spec into code for months on end, but you need three architects to keep them on track (which we don't have).  This one is harder to sniff out, but not impossible.
3. Raison d'être.  Some developers only write software to cash a paycheck. Ironically, most of them don't seem to realize that they're being outmoded by newer, faster, smarter developers who are eager for their paycheck.  Continuous improvement isn't just a corporate thing, it's a career thing.  I take it as a sign that anyone who hasn't flexed themselves in the past 3 years thinks they know all they need to know, and I don't hire those people.

All of this preamble was a build-up for my soapbox on Professional Development™.  It is far too easy for developers to stagnate, and they usually don't know they're a dinosaur until they're being "let go" in favor of newer/younger blood that has three times the depth in current technology and can't find a job.  Likewise, I'm there are many companies looking to expand their Lotus Notes & CORBA integration project from 1997 and want to see more "web 2.0" in it.  The reality is that those companies are mired in the 10-year-old mentality because they didn't help (or push) their developers into staying current.

At MLSPIN, I've been instituting the best policies I've ever learned working for various software companies, large and small, or heard of through online sources:

1. Conducive environment.  This is the hardest, since it takes a lot of money and there's only so much you can do with the facility.  My developers work in a bullpen (less than ideal), but have plenty of space and new ergonomic chairs.
2. Productive equipment.  Each developer has a real HP workstation, with a quad-Xeon processor (room for a second), 4GB of RAM, 15K rpm SAS drives in RAID 5, and an ATi FireGL video card (because they're better at 2D than nVidia).  Each also has two 20" flat-panel monitors and their choice of keyboard & mouse.  We run Visual Studio 2008, and each developer has a copy of Photoshop Elements and SnagIt.  I also have a 5-seat license of MSDN, so we can tinker when we're planning new stuff.
3. Progressive training.  In addition to the modern cachet of books, we provide $2500 in tuition/certification reimbursement, pay the certification exam fee for any passing score, and offer merit bonuses for accomplishing their certification goals.  I'm also committed to having two "superstar" training weeks each year.

The first training session this year was held in January and featured the inimitable Bill Vaughn.  Aside from being one of the founding fathers of ODBC and grandfather to ADO, Bill has the most comprehensive knowledge on programming against databases in Microsoft technology that I've ever even heard of.  Buy his books, they make you smarter.  In a week's time, Bill was able to convey as many nuances to the technology as I've learned in a decade of hands-on work, and I still learned new tricks.  He's very personable, doesn't believe in stupid questions, and knows how to mentor.  We liked him so much, we've now got him on retainer.

I still haven't decided who to have out for the August-ish session, so if you have any suggestions, drop me a line.

So, that's my pitch.  If you are a professional developer, do whatever you need to to stay current, and if your company doesn't support that, leave.  If you're a company who doesn't believe in training your resources, send me your developers' resumes.

-Matt