What is your take on qualifications [certifications] over experience? I’ve talked with some hiring managers and about 50% say experience is better when it comes to applying for new jobs. I know my 15+ years experience can take me so far, but I’m looking to improve my standing and employable.
So, from the spelling I’m guessing we’re in different countries, and that does make a difference. Your local intel might be better for you than mine. But I recently (back in March-April 2018) had reason to do some fairly extensive research into this, and I’ll just share what I learned.
Very few organizations formally track the technology skill levels of their technologists, and very few organizations formally track even the skills and skill levels their job roles require. What they tend to track are the soft skills a role requires – “must have good team leading skills,” “must have good written communication skills,” etc. The actual question of, “do you have the technical chops to hold down this role” comes down to the hiring manager, and it tends to be a very subjective, ad-hoc analysis.
Many organizations apply a number of “gates” in their job postings. These are intended to just be easy-to-check filters. The theory is that, “anyone who’d be legitimately qualified will already have met these, so we’ll use them to weed out the chaff.” This is where your standard requirements for a four-year degree come from, along with Acronym Soup like “must have MCSE/CCNE/WTF.” That theory isn’t a great one, it turns out, but it’s got so much “gut instinct appeal” that companies just won’t stop doing it. I once had a friend who was declined for even an over-the-phone job interview, because he didn’t have the WXYZ certification in the job posting. Thing is, he wasn’t allowed to have that certification, because he presently worked for the vendor itself inside the team that developed the product covered by the certification. So. The theory breaks down a lot.
Next up, you’ve got anything involving code. Code-centric certifications have never taken off, in the 20+ years I’ve been in this business, because of a key fact: coders can take code with them. Code itself acts as a portfolio. You can show someone at least chunks of your code; you don’t need some “trusted third party” to certify you because you can show your work. Infrastructure people, on the other hand, can’t exactly carry around the last network they built, and so certifications have rather flourished in the infrastructure world.
What most people don’t realize is that most infrastructure certifications only seek to validate that you are minimally qualified for whatever role they’re certifying. So an MCSA seeks to certify that you are minimally qualified to administer whatever the MCSA is about. Minimally, not expertly. An MCSA is not an expert; they’re quite literally the bare minimum that 80% of employers could scrape by with. That’s certainly an argument for the acronym being a job posting filter, and it’s an argument for taking the damn tests – if you’re any good, passing the tests shouldn’t be that burdensome.
Experience is always better. Full-stop. The fact that you have done something means your brain has the synaptic networks to repeat what you have done. But where IT people tend to suck, in my experience, is in communicating their experience in a concise way. Resumes are a stack of acronyms and product names, not outcomes that they have created. And think about the “hard things” in your environment that you’ve done – it’s almost always troubleshooting and fixing, not building net-new. So a resume that just says “Windows Server 2016” on it doesn’t tell me, as a hiring manager, jack-shit about your troubleshooting or fixing skills.
So I would put most of my effort into better communicating the outcomes you can create. See, I learned that early-on. When I was an aircraft mechanic apprentice, some of the older mechanics explained that, in the government, job postings always includes KSAs – Knowledge, Skills, and Abilities. They said, “every time you do any job task for the first time,” write it down, and the date, in a journal. Then you’ll be able to fill out the KSA sections of the job posting easily. So I’ve always been in a habit of writing down key job tasks I’ve learned to do, and when I learned to do them. Boom, instant resume. And yes, that gets to be a big list. So how would you handle that as an IT problem solver? Maybe your resume has the highlights, and refers people to a website you built, with a searchable database of tasks you’ve performed. Boom, online job-task-journal, ready to go for any job-hunting needs, as well as a portfolio item of how you can build out a meaningful piece of infrastructure.