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 
Related posts:
- Diving into the talent pools Even in this down economy, finding technical talent can be...
- Communicating Across the Techno Gap You have probably heard people talking about “dotted lines” in...
- Tale of two developers Angie Byron, has wonderful post on approaches to contributing to...
- Network-Centric Web Services Jon Stahl wrote an excellent post recommending the construction of...
- Migration tools are marketing, not technical, tools Jeff Potts, in his blog ECM Architect makes an excellent...
I saw a blog post the other day (can’t find it right now), where someone was discussing this practice of googeling on people. One point that blog raised was that some people use an alias when they are “interacting in the open” .. for various reasons.
I think the better approach would be to clearly state what kind of resume’s you are looking for. Something like “we expect that the candidate can answer tricky technical questions on every technology listed in his resume”.
Or “we will search on the web for contributions/achievements of all our candidates”.
regards,
Lukas
Great comment Lukas, lots of developers use aliases or handles. Over time you get to know who is who but sometimes you need to spend a lot on the list or attend a conferences. Wouldn’t it be a great idea if developers added their aliases to their resume? However, I could see people having split personalities. A n00b alias for dumb questions and a l33t alias for technologies that they really know.
Adding aliases to your resume is actually a pretty cool idea. I also like the idea of getting your comments pulled to your own website (saves the trouble of googling). Comments tell a lot about a person.
But beware that googling a person during an application process is actually considered a violation of person’s privacy in some countries. For example in Finland there has been a vivid discussion about the issue. Some people interpret the law so that employeers shouldn’t google applicants, which is kinda strange.