A couple of times in my career, I’ve been on the non-scary side of the recruitment interview table attempting to fill junior network engineer vacancies. Both times, I insisted that the panel ask at least one or two questions which would try to determine how the applicant would go about troubleshooting a problem. Give them a basic topology, describe the problem, and ask them to outline what steps they would take. Personally, I would have liked to have put the person in front of a simulator or a small network and have them show me, but unfortunately we couldn’t go that far.
Frankly, I was appalled at the responses I would get. One applicant, seriously, suggested that the first step – the first step – in my troubleshooting scenario would be to replace the router in the topology. This is worse that the Cisco TAC reflexively suggesting that you should upgrade your stable, secure IOS before digging any further. It was also telling that this person had a CCNA and was working towards a CCNP, and allegedly had networking experience.
I have found that troubleshooting is a skill that comes with experience, but it also helps if you begin with an ability to think critically and logically. Local knowledge is important as well, especially in short-cutting a troubleshooting process, but I have seen people who lack the basic skills fall into the trap of “I’ve seen this before – it was X then, so it must be X now” and then totally fall apart when it is revealed that the symptoms are the same, but the cause is different. If you come into a situation cold, but have good first-principles skills, that beats local knowledge every time.
So why do we see such poor troubleshooting skills in applicants, even ones who might have some certifications behind them? Part of it is that a freshly minted CCNA may have come straight from a training academy, and have no practical experience. But I think a big contributor is a change in the nature of entry-level ICT positions which many of us older hands may have come through which gave us the troubleshooting experience we now rely on. When I first started in IT (yes, here comes the “when I was a boy” speech), the entry-level positions were in desktop support. My first job in IT was looking after Windows 3.1 PCs. When a PC went wrong, we had to look for corrupt DLLs, run disk repair utilities or troubleshoot faulty hardware. A new application was loaded by feeding in floppy disk after floppy disk, but before you did that, you had to check that the machine was up to spec and that the new application wasn’t going to screw up you existing setup. In other words, you needed to actually apply troubleshooting daily in even this entry-level position. Guys a generation before me cut their teeth in the POTS voice world, where troubleshooting and fault-finding was their bread and butter.
Compare this with my experience of desktop support in my organization now. I had a malfunctioning laptop – corrupt DLLs. I could tell, because there were messages telling me about it in the event viewer. As I was heading to a remote site and didn’t have time to look at it myself, I grabbed my second laptop and raised a case with the desktop services people. Their answer – yes something is wrong, we’ll format the drive and re-image it with the SOE. That was their first response. Another machine of mine had a faulty wireless connection. My desktop support people did not even come to look at my PC. I was told to note the service tag number and log a fault with the manufacturer’s field service.
Now, you may argue – and I agree – that things are a bit different these days. We have imaging tools and fast data transfer. Having SOEs aids in efficiency. Operating systems and apps are multi-gig bloated things and are ever more complex. Outsourcing hardware maintenance is cost-effective, and we don’t need to carry parts inventory and so on. I get it. But the problem is that these entry-level people never have interaction with the equipment beyond the most superficial. They are reduced to monitor-swappers, as I like to say. And this means they never develop the skills needed to progress in an IT career. Seventeen years ago, I was in a desktop support team of three. We were all aged around 20 and new to the IT field. I was into networks, so I became a network engineer. Of my other two colleagues, one became a system administrator, and now is a storage engineer, and the other progressed through systems administration and into management. The skills we learned held us in good stead to keep learning and move up.
The sad part is that management is reluctant to address this at the entry-level. Training is non-existent for the staff. I am all for people who are self-starters and undertake to improve their skills themselves, but management needs to play a role. After the third incident in a month where I was informed that “nobody on Building Y can access the network”, and I arrived on site to find two or three desktop support staff milling about complaining about the network to the clients, where the problem turned out to be that the DHCP server in that department was down, I asked the management if they could do something. Their response was that if I wanted to do some training for their staff, then that would be fine.
So I went back to my office, drew up this flowchart and pinned twenty copies to their door.
Momentary frustration, and a little condescending, albeit not beginning with “is it plugged in?” The issue impacted me in day-to-day operations. However, I fear that those staff may sit across from an interviewer in years to come, and be turned away because their skills were not allowed to develop. If the job doesn’t inherently develop those skills, then management needs to help, or the staff themselves need to take the initiative.