Effective developers know how to search the net

Back in the old days, handbooks were the most important source of information for software developers. With your operating system you would get a massive amount of documentation that was meant to be comprehensive for every imaginable application to be. 

Things have changed slowly but surely. Today, an application developer not able to find online information about problems or errors encountered is in the way of productivity. He or she will be looking desperately for the explanation of an obscure API call or error message in old manuals when the solution could be found in seconds when using search engines. This is because error messages may be obscure to the single developer, but the net is so huge that somebody probably has stumbled upon it (and possibly found a good solution). Also, the paradoxon of manuals applies: The most difficult problems never appear in them, because they were simply not foreseeable to the API or system creator to be documented.

With the ever evolving APIs of today's libraries and operating systems, it is simply not economical to depend on printed documentation when things go bad. There are some examples of very good official documentation. The Java documentation is usually excellent, for example. Many parts of the MSDN are clear and precise, and tackle real world problems. But especially in open source land, documentation is usually done "in code" (cough) or very scarce and outdated. The quality of Linux man pages varies wildly. 

When an error message "libXYZ: error 59, dropped packets" pops up, it is the best way to simply dump the error message verbatim into a search engine. Usually, a lot of hits will show up. Many may just be desperate postings in online forums, but one out of ten may have received the appropriate answer. Problem solved. Good manuals may assist, yes (although don't forget the saying: you can't grep a dead tree). Reading bad manuals as well as communicating with support hotlines would be much more time-consuming and should just be a way of last resort.

I think it would be useful to not only ask for development qualifications in job interviews for software developers, but also let them find out the problem for a particularly weird error message. Just ask what their approach would be. If you have developers who can't solve problems with search engines, your competitor might have them, and thus have a much better productivity.