Having been part of the work force for a long time now, I have also interviewed with a number of companies. Sometimes I have completely ignored what were, in hindsight, relatively obvious red flags, while at oher times identifying such red flags has helped me avoid jobs that wouldn’t have been a good fit for me. Here, then, is an overview of some of these:
I am sure that I am not alone in making an effort to keep abreast of what jobs are being posted within what can largely be termed my field, and am struck by the paradox represented by requiring relevant experience for most jobs, even entry-level positions. For example, I have seen my share of highly educated people cycle through a support department on their way to the jobs they’ve educated themselves towards – usually software development – in an effort to gain “relevant experience”.
In the IT world, there are a lot of different paths to take. Mine, though conventional enough in its beginnings, is increasingly becoming unconventional. I believe this is a good and important thing. Here, then, is my approach to my own career.
An age old adage tells us that when one door closes, another opens. This feels particularly apt to me these days. As we approach christmas and New Year’s eve of…
Having worked on-site support for most of my career, I’ve seen a lot of things that can bug you. There are a few things we can do to make it a little more survivable, such as:
I try to keep out of trouble at work as much as possible, for many reasons, but mainly because I prefer being praised to being yelled at. There is a very simple way to achieve this; simply make your promises rarely and in such a fashion that you have leeway if something should go wrong, and then follow up on it.
I don’t mean to say that you should be ambiguous, but rather that you should promise to deliver so that you have more than enough time on your hands. If you’ve got a task on hand that should take three days, promise to have it done within five.
After promising to deliver in five, do the job, double check everything, then deliver in four. By taking the extra day, you can take your time to perform quality assurance, in turn lowering the chance of problems afterwards.
The mantra is known as Tom Peters‘ Formula for Success: Underpromise and overdeliver.
Most techs will agree, that even though it is stressful and at times annoying, high-intensity periods are to be preferred to low-intensity periods. There is a simple reason for this; when there is a lot going on, you simply can’t afford to procrastinate, and so you’re forced to do your work as efficiently as possible.
On the other hand, low-intensity periods, such as when everyone takes their summer vacation, while pleasant, can mean that you get much less done than you would in high-intensity periods, because you can procrastinate.
Even in slow periods, though, you can get a lot of things done. However, it demands that you exert some discipline, and set goals. In my experience, slow days are great to do those tedious tasks that you don’t have to do, but which makes things easier all over, such as documenting a solution, or troubleshooting that problem that’s been on your back burner for the last three months.
It is also a good time to talk to your clients. If you use these times to do a walk-around of the client’s offices, and talk to them individually, you’ll be able to catch the little things that most users simply contend with, which will in turn buy you good will for some later time, when you might want to have said goodwill intact.
By working pro-actively like that, you can also stop potential problems before they become problems. The risk, is of course that you suddenly get a lot to do, but at least then you don’t sit around twiddling your thumbs eh?