Slashdot recently linked to an article titled Is There Really an IT Labor Shortage? which argues that the alleged IT labor shortage is merely an argument of convenience for various companies. The article also questions whether the skills shortage is really just that or a result of unrealistic hiring practices.
While I cannot disagree with some of the reasoning behind the argument of hiring practices, I’d like to propose another angle on the ‘labor shortage’ theory–too much ‘book knowledge’ and not enough critical thinking among IT job candidates.
My company has recently been looking for qualified support personnel. The typical support engineer we hire has 7 to 10 years of industry experience in UNIX/Linux, Windows, Networking, SAN, or combinations thereof. These are high level positions for high level people. Granted, the ’support’ portion tends to scare away a good number of people from the outset.
I tend to be involved in either the first level (phone screen) or second level (1st face to face) interviews. Not only do most of the candidates not have strong enough technical skills, but of those that do, or appear to (according to their resume), all are lacking one critical skill–troubleshooting. Troubleshooting, or more simply put, thinking for oneself, is a very basic and critical skill that seems to be lacking in the majority of candidates I speak with.
I don’t expect every candidate to know the answer to every technical question that I ask. However, I do expect that they will able to admit that they don’t know, and tell me how to go about looking for the right answer, and how to attempt to break an unknown problem down to a more basic level by asking the right questions. Problem definition is a critical part of troubleshooting and something that our organization tries to instill into our engineers.
For example, with one recent batch of phone screens, I provided a simple scenario, warning beforehand that there was no single correct answer. The question was as follows:
“If you received a [call | email | trouble ticket] from a customer who reports that users of his Oracle database on Linux are reporting slowness, how would you go about troubleshooting this issue?”
Not a single candidate was able to provide a set of problem definition steps to my satisfaction. Most attempted to solve the problem right off the bat by spouting off possible solutions to an unknown problem. (I’d check the server’s disk space! I’d look at subnet masks!, etc.). I was hoping to hear logical questions to try to narrow down the problem, such as “Is the problem new? Does it only occur at certain times of the day? Are all users affected? Are all queries affected? Were any changes made recently?, Define slowness, How are you measuring slowness?, etc.”
Where does this lack of critical thinking come from? I’m not entirely sure, but I think part of the blame can be laid at the feet of the myriad industry certification programs. The bulk of the certification program keywords that you see tossed around only push people to know what is on the test. No attention is given to troubleshooting, to trying to solve problems in a methodical fashion. Not all certifications are like this–the CCIE and RHCE are two that I can think of off the top of my head that are lab-based, rather than ‘multiple-guess’.
I don’t know what the solution to this whole problem may be. It almost seems like a self-perpetuating problem. Companies put out ads for IT people with certifications X, Y, and Z, except those certification programs are not producing qualified candidates. I for one would like to see a end to employment ads requiring a candidate with a bunch of 3 and 4 letter acronyms after their name.