[Series] IT Jobs - Part 1: Do's and Don'ts

E

Eric Hansen

Guest
While I’ve been trying to stray away from doing “series” articles these days, this is one topic that is impossible to really do that with, but yet I feel is worth it to benefit everyone who reads this. This article will also be updated to reflect new posts made in this on-going experience, and will be linked at the beginning of each new article as well.

Why Write This

The IT field is booming, and has been for the past decade at least (depending on where you live). However, the skill sets needed to be in the field is both ever-changing and ever-stagnant, again...depending on where you live (plus the career path you choose).

When I first got into IT, I wanted to do PC repair. Then, I realized I disliked hardware...a lot. After that I rediscovered my passion for security. For the past 5 or 6 years I’ve been on the search for a security-focused position, while also seriously developing my programming craft as well. Now, I’m also writing articles for Linux.org.

This has really brought to my attention though that there is not a lot of unbiased resources for the IT world in terms of obtaining a job. While what I will discuss is not going to fit the mold for everyone, they should still be helpful in whatever field you choose.

The Do’s and Don'ts

This one is always tough to discuss, as its almost always unique to the situation. Throughout my many years of both good and bad interviews, I have discovered some trends that work better in my favor than others.

Do Not Worry - This really should go without saying from all the prep talks you get beforehand, but if you walk in thinking to yourself you’re making a new friend, and not overload yourself with all these other parts (its a job, you’ll get money, etc…), you’ll be a lot more calm.

To deal with this, I just keep talking to myself while going on the interview. Every time I think something akin to “I’ll be making $xx/hour!”, I start thinking about how I want to talk about why my programming skills are a fit for the company/position.

Do Prepare - Again, another one of those “go without saying” parts. Prepare for the position and the company. I had an opportunity with Snort a couple of years ago as a sysadmin-type role. From looking around the place, checking the website out and doing some research before hand, I knew what I was walking into. It made it easier to focus on what they wanted to know about me instead of wondering if the company was one I wanted to work for.

Do Not Oversell - People can and most likely will put you to the test if you seem too good to be true. I had an interview not too long ago with a company who was looking for everything I had. The programming, sysadmin and social aspects were spot on. The same day, they wanted me to send them code samples of my work. While for outside reasons I didn’t get the job, I impressed the manager enough for them to see what I was truly made of.

If you oversell yourself, you need to be able to back it up. But, if you oversell, it usually means you are trying to compensate for a shortcoming or be someone you aren’t. People can also tend to see right through that.

Do Keep Updated - This seems to be one of the biggest faults in a lot of people in IT. People will focus on one thing, and be great at it, but given the nature of IT it often means you’ll only be great at it for so long.

You need to keep up to date on the latest happenings, events, languages, etc… This isn’t to say you should dive into learning R immediately, but know that its out there for statistical programming.

I just started mobile app development, but mainly because I had no need for it at the time, plus it was a lot more difficult then than now.

Do Learn Programming - This is something you’ll have to do regardless of the position you go for it seems. Even Windows admins need to learn LDAP or batch programming.

Shell is usually a big beginner language to learn, while Python is also taking a strong lead in system management. Perl, while not as heavily used, is still viable to understand some of the deeper concepts like hashes, arrays, etc…

Do Not Stagnate - You don’t want to become complacent in your position, because that means that the company will be able to replace you for cheap. Prove you’re viable to the company by finding ways to improve metrics, make protocols easier/shorter, and become the go-to person.

Will this always be possible? Yes. Read tutorials, articles, blogs, learn new things, improve yourself and it will reflect in your career.

Even if you don’t have a job, become the go-to person for your friends. The experience that it will give you is invaluable.

Do Be Comfortable With Yourself - Oh you thought you were done with these? Yet another thing often overlooked, but completely versatile.

You don’t need to ooze out confidence, but you should be able to sit comfortably with someone and talk about how your newest project is awesome. That’s really all anything involving the job hunt is, is talking about how awesome you and whatever you’re doing is.

Do Always Ask - Always, always...ALWAYS ask questions. This cannot be stressed enough.

While it goes into a few of these categories, it also belongs in a category of its own. You need to always be hungry. Not only for a job or a new car, but also for learning. For knowing what’s out there.

Go to conferences and conventions. Ask questions and spark interest with others. You’ll never know what can happen.

If you don’t know something, ask. The chances of someone making fun of you instead of being helpful is slim...and, if that slim chance happens, you’re better off knowing not to deal with that person again.

Do Be Independent - A lot of people are looking for people who can do their job without being hand-held. From the moment you’re in the job market until you retire, you’re just a spoke in the wheel. If you can’t do your job on your own, they’ll find someone who can.

This isn’t to say you can’t ask questions. Most people would rather the job get done right the first time, than have to keep submitting bug reports, after all. But, know when to ask, and know when to look things up yourself.

Programming is big on this, especially with so many people doing it. There’s a lot of resources out there that can answer 99.9% of the questions you have. The Overflow network (Stack Overflow, Server Fault, etc…) sites are a gold mine of information for these things. Which will bring me to my last point of this…

Do Join Communities - Similar to always ask. Join communities, both online and physical. There’s a lot of sites out there, like the ones mentioned above. There’s also LinkedIn. Even websites like Reddit have communities for general programming, computer science, and specific languages. All of which are usually pretty helpful when things are asked as long as you follow the rules of their community.

Closing Remarks
As you can see there's really not a lot of "don'ts" in this list. That's the thing with IT, though. Its virtually arts and crafts of the 2000's. Especially with all the things people are doing in it (both good and bad), you never know what will happen.

Like I said this is going to be a series, and I’ll post the new articles at the top of this as well. But, I feel these are all good points to follow when getting into IT. While a lot of these have the intention for programming personally, I tried to use ones that were relevant for a lot of professions out there.

If you can think of any more though feel free to make a comment and let me know. I’ll add them to the list if they don’t fit anywhere else.
 

Attachments

  • slide.jpg
    slide.jpg
    58 KB · Views: 302,609


Learning programming definitely helps because it allows the IT Technician to better understand computers and the inner workings. The more complicated error messages would also have more meaning to the tech and the tech will be able to better grasp (understand) various concepts.

Obviously, programmers know programming, but they should learn more than one language and have a basic understanding of Assembly. "Why?" you may ask. If a programmer understands some assembly, then they will know that "while 1", "while 2", and "while True" are exactly the same (I will explain in a moment). Programmers will also have a better idea on how to program. Since compilation converts the code to Assembly and then machine-code, knowing how Assembly works allows the programmer to write more efficient code and know why certain code/algorithms fail.

NOTE: The code seen in this post is just pseudo-code. This means it is just an example that is not specifically using a correct form of syntax. Every programming language has a special way of making while loops and such.

Now, I will explain the while loops. This is important to know since many employers ask a question based on this when interviewing a programmer. "while 1", "while 2", and "while True" will execute forever, but an employer may ask "Which is faster?". The plain answer is "The performance is the same" (this answer is too plain for the interview, continue reading). This is true because compilers write never-ending while loops in Assembly using a special key-word. For example, "while True:" may be converted to Assembly as "forever" (this may not be a real Assembly command). So, the better answer (if not the best) is -

"There is no performance difference. This is due to the fact that while 1, while 2, and while True are all never-ending loops. The compiler will notice this and write such code in Assembly by using a single command that indicates the loop never ends. In other words, they exactly the same."
 
Interesting.

So far, I have an Associates in Cyber Security so I have similar interests toward Security or Pen-Testing. IT is such a broad field though that I'm not sure what my next step should be. I could work my ass off learning all about Security, or maybe it would be better to aim lower to working in a Datacenter since there aren't likely Entry Level Security or Pen-Testing jobs.

I have had a few interviews, but I haven't been hired. I really tend to think this is because I need to beef up my resume. I severely lack "Real World Experience" for one thing. I should really learn a language like Python. Also, I should get some Certs.

I have a study guide for Security+ so I may work on that next. Should I bother with Linux+? Or shift gears and aim for a Red Hat Certification?

After I gain more knowledge, I'm also thinking of forming an LLC. instead of waiting to get hired.
 
Interesting.

So far, I have an Associates in Cyber Security so I have similar interests toward Security or Pen-Testing. IT is such a broad field though that I'm not sure what my next step should be. I could work my ass off learning all about Security, or maybe it would be better to aim lower to working in a Datacenter since there aren't likely Entry Level Security or Pen-Testing jobs.

I have had a few interviews, but I haven't been hired. I really tend to think this is because I need to beef up my resume. I severely lack "Real World Experience" for one thing. I should really learn a language like Python. Also, I should get some Certs.

I have a study guide for Security+ so I may work on that next. Should I bother with Linux+? Or shift gears and aim for a Red Hat Certification?

After I gain more knowledge, I'm also thinking of forming an LLC. instead of waiting to get hired.

The Linux+ is a good certification to earn as I have done.

http://www.linux.org/threads/linux-reading-guide.6035/
 
Hi Eric & Devyn,
Thanks for the valuable post.
I am currently working as Desktop Support Engineer, but I have passion for Programming, Security & Linux.
Please advice me..
 
Hi Eric & Devyn,
Thanks for the valuable post.
I am currently working as Desktop Support Engineer, but I have passion for Programming, Security & Linux.
Please advice me..

This reading guide (http://www.linux.org/threads/reading-guides-indexes.6034/) may interest you.

You can help yourself and others a lot by making your own cheatsheets like this one that I made for the Python3 subprocess module (https://drive.google.com/file/d/0B-BP95n2EiaIREJVLTY5M2IxWUU/edit?usp=sharing).
 

Staff online


Top