Having been employed at startups and fast growing companies, I have seen my share of technical résumés and my conclusion is that the technical résumé is nothing more than a misleading garble of acronym soup. They are totally worthless. Developers list every technology they have ever heard of regardless of whether they understood the technology or are current on it. Many developers work on large systems and have very little understanding of the technology beyond a narrow little slice that they were responsible for. Don't even get my started on certifications. In fact, my experience is that the more certifications, the less competent the developer. The technical résumé is the equivalent of search engine optimization circa 1999 - load your résumé with keywords, post it on Monster, and wait for the hits.
The truth is that a developer is not good just because she knows a certain syntax or has worked with a product. What makes a good developer is how she thinks and how she works on a team. Good developers are interested in the underlying design and function of the technology and are diligent about following best practices - not because they are told to but because they understand the value behind them. Even when they are heads down, they are aware of what other people are working on. They anticipate interdependence and communicate. Good developers make other people on the team better.
Luckily, with the advent of social networking and Google, the era of the technical résumé is about to end - certainly for senior technical people and upcoming tech rock stars. The reason is that these people who are smart and love their field do not just code anonymously in their cube. They interact out in the open and with some good Google searching, you can follow their tracks. This is certainly the case for open source developers but it also holds true with developers that specialize in proprietary applications as well.
If you are evaluating a technical candidate, don't spend too much time on the résumé. Start by Googling their name. There you will find posts to mailing lists and forums, chats on IRC, a blog, comments on other people's blogs, entries in bug tracking systems, even user group presentations that the candidate did. Ideally, you see the candidate answering a question or putting forth a well supported opinion. If he is asking a question, you can learn a lot from the quality of the information and the tone in the question. See my post on how to post on an open source mailing list for what makes a good question. Plus, a simple search may turn up any strange affiliations or interests that you might want to know about. For a proprietary product, you can do a lot by searching on the support extranet which may contain a forum or other community content space.
LinkedIn and other social networking sites are a great resource. The candidate might have received recommendations from people he has worked with. You might even know someone in common. If you do, start talking to people and find out what they thought about working with the candidate.
If you are on the other side of the equation and you are a technologist that wants to optimize his employment opportunities, stop getting certifications. Get out there and engage. Rather than get an MCSD, show what you know by writing something helpful on a MSDN Forum. Make more of an effort to understand the other components of the project you are working on. Sit in on someone else's code review. Actively read blogs (comment too). Participate in an open source project. If you are not interested enough to make this commitment, you can still have a comfortable career as a technologist but you will not go far. You will probably wind up being a PM ;)