The (expanded) Practical Checklist For Getting a Job (in IT)

Over on Dev.to, “JavaScript Joe” (that’s his name, I swear) posted a nice little piece on a few quick things you can do to get a job. You can find it here: https://dev.to/jsjoeio/the-practical-checklist-for-getting-a-job-150n and it’s worth a read.

My reason for writing here is that J-Joe is writing from the perspective of a programmer/coder/dev, and framed his examples with that audience in mind. The problem I perceive is that his examples were un-necessarily dev-specific, and non-dev readers may dismiss or skip his advice because of it.

With just a little tweaking, I’d like to re-frame his thoughts so that people from ALL walks of IT life can realize just how useful his advice is, and take it to heart, and (hopefully) find a job faster and easier because of it.

Get Real Experience

JavaJoe describes the problem clearly. Job postings ask for an entry level person with pre-existing experience. Oxymoron much?

And the advice also holds true for most IT disciplines.

• Look for internships.
• Try to get contract work where the bar is lower.
• Reach out to local companies where you can leverage the ‘hometown’ connection.
• open source is NOT just for devs. hardware and applications need testers. UX teams need fresh sets of eyes, including eyes from people not jaded by the last 16 versions of the tool.

To that advice I’d add:

• Find user groups and meetups (online or IRL) with the express intent of getting involved with people who are trying to get into the same area you are. Maybe you can’t start a project on your own, but you can contribute to a team. Who cares if you “finish” that project. The point is to share ideas, gain visibility, and use the experience as a talking point on your resume.
• Find a mentor. Someone who is already working in the discipline you want. Ask them if they know of any opportunities you can “tag along” on.

Network

There is literally nothing wrong with what J-Joe said here, nor anything that doesn’t apply to sysadmins, network engineers, infosec pros, or monitoring specialists (yes, that’s a thing!) as much as it does to developers. While “give a talk” can seem daunting on many levels, the point is to get to know people in the sub-specialty you want to be part of. You will hear about opportunities (for work, volunteer, or just conversation), about trends, and more.

I also appreciate that there’s a recognition that not all of us are go-out-and-meet-people extroverts. An online meetup can be just as valuable. You know yourself and what you need and what you can tolerate.

Share What You Learn

You may think “wait, I’m at the start of MY career, what would *I* have to teach anyone?”

In a word, TONNES! The fact is that, if you are very new, you have likely just gone through some challenging mental gymnastics to grasp those early concepts. Share those (through a blog post, a twitter meetup, or in person) because I promise you someone else is going through that now too.

If you’ve been doing this for just a little while, then you may have progressed from absolute newbie to “ok, now I see how this works”. You are probably also experiencing moments of “If only someone had told me THAT in the beginning, I wouldn’t have struggled.”

THAT. Talk about THAT THING. Give the “if only I had known” talk. Because nobody else did, or else you wouldn’t be having this thought. This is an enormously valuable lesson you can teach. Don’t miss your chance.

And, of course, if you have been training for a while, and are ready to make the leap to the workplace, you can offer that entire journey’s worth of wisdom. “you are probably thinking _____ right now. Here’s what you have to look forward to.” Again, you are the best person to offer those insights, and they are both unique to your experience and deeply valuable to everyone who comes after you.

To that point, I’d also like to emphasize that there are network, sysadmin, cloud, infosec, monitoring, etc forums, websites, and hashtags that line up with #100DaysOfCode, #CodeNewbies, #GirlsWhoCode, etc. I promise you there is a place where your voice and story will matter, will be heard, and will make a difference.

Build Projects

Again, it sounds all so dev-y, right? Start a Github repo? How does that work for storage engineers? The key lies in Java Joe’s comment:

Build 1 project that solves an everyday problem for you

Yes, he meant write some code. But you know what? That is just as easily a network device config. Or a Powershell script that automates a repetitive action. Or documenting the upgrade process on the storage array controller so that you can do it the right way, the same way, every time.

Eye On The Prize

Remember the point is ALL of this advice (mine and Java Joe’s) is NOT to fix some previously-unsolvable problem, or to save the world, or to cure cancer.

The point is to demonstrate to potential employers that you are:

• enthusiastic about this area of IT
• willing to think both deeply and creatively about both the weird edge cases AND the day-to-day experience of working in this sub-discipline
• committed to learning and growing and expanding your range of knowledge, even if that pushes you out of your comfort zone.

In a nutshell, you are pointing to each of these activities NOT as a way of saying “by this you can see that I can fix all your problems”, but rather as a way of saying “by this you can see that I’m someone who may lack years of experience, but who is the kind of person you want on your team to grow into the role.”

I hope this helps.

[Photo by Green Chameleon on Unsplash]