Archive for August, 2012

Some things corporate recruiters need to know…

Wednesday, August 29th, 2012

This morning, I got an email from an internal corporate recruiter by the name of Natalia Delape at Peoplefluent. It was sent to me through LinkedIn. This isn’t that unusual, I get anywhere from two to five inquiries about open positions a month, and I’m usually willing to simply reply with a polite “No, thanks, I’m happy where I am.” and move on. Truth is, I am quite happy in my current position – it’s a great company and I feel like I’m having a significant positive impact on the company.

This one, I wasn’t willing to be so polite. Why not, you ask? Well, the email sent to me was a form email, with absolutely no individual, specific, personal information in it – it might as well have been from a Nigerian 409 scam artist as from an actual company. Second, the job description had absolutely zero relevance to my skillset, as would have been self-evident had Mz Delape bothered to read the job description and the first line of the summary of my LinkedIn profile. So she basically wasted my rather valuable time by making me do research on the position that she should have before contacting me.

I wonder how Peoplefluent can be such an excellent staffing firm if their own internal recruiters are so bad at their jobs? I mean, Peoplefluent claims right on their website that they were named a “Market Leader” for “Recruitment” – yet their own internal recruiters are the next best thing to small shell scripts?

Mz Delape was evidently a bit miffed at my response, telling me she did not appreciate my tone, and that she was “just doing [her] job.” Well, Mz Delape, I really don’t give a rat’s ass that you didn’t like my tone. Number one, you clearly weren’t doing your job, or you wouldn’t have contacted me about a position that I don’t even begin to have the skillset for. Number two, I don’t appreciate you wasting my valuable time because of your refusal to do even a basic skim of my profile before clicking your cut-n-paste message on it’s way to me.

Thankfully, not all recruiters are quite so bad at their jobs. I was placed in my current position by TekSystems, and before they even submitted me to any positions they took the time to get to know me, and more importantly, get to know my skillset and what I wanted out of my next position. It took about 6 months and eight on-site interviews before I got an offer, but of those 8 on-site interviews, there was only one company I was unsure of going to work for. Yes, it takes a bit longer to get a job, and it takes a bit more work on the recruiter’s side, but trust me, the karma you build up by actually doing your job well is worth it. Plus, the IT community is smaller than most recruiters might think, and we all talk to each other. It might not be a 1960’s sorority house gossip line, but when a bad recruiter hits one area sysadmin, pretty soon the entire RTP community will know to avoid that person or company, and your emails will get killboxed, so you won’t be able to find any qualified staff.

Peoplefluent, if you waste my valuable time like this again, rest assured I will send you a bill for recruitment services, since your internal staff is totally unable to perform their duties adequately.

Information Overload

Tuesday, August 14th, 2012

Anyone who has been in IT for more than 2 days knows that systems monitoring is important. Heck, I’m willing to bet you know it’s important even if you’ve only been in the field for 2 hours. If a system goes down, you need find out about sooner than the customer, because when the customer finds out, you want to be able to say “Yes, we’re addressing the situation now.” Especially if the customer is your boss.

There is, however, a trap you can all too easily fall into – monitoring too much. Or at least, giving your sysadmins too much information from the monitoring system. Some of this is inevitable, especially when first setting up a new monitoring system. Some of it is politically driven, and you will get alerts for log messages that really don’t mean diddly in the grand scheme of things, because auditors want to see green lights turn yellow when someone mis-types a password. Much as it pains me to admit, these are some things that you just need to learn to live with.

What you should be careful to avoid at all costs is alerting people when things are working. Especially sysadmins. Quite often, the sysadmins don’t care – at all – if things are working as expected. A typical response: “So what? I’ve got these three fires to put out, five systems to build, four developer questions, and eight help desk escalations to deal with. Could you please go away and let me do my work?”

Okay, so obviously nobody will come up to you and congratulate you when your systems are working – your boss might show his/her appreciation somehow, but that will be at a group lunch or during a staff meeting or something where you’re already blocked off from doing useful work. So what’s the concern here? Email. Automated script email output. When you put a monitoring script in place, do not, for the love of the little people, let it send email to the entire world when it finishes running and all it’s checks have been passed. Have it sit there silently and quietly. Only when it notices a failure should it make it’s presence known. If it talks too much, your sysadmins will start to ignore it – just like the little boy who cried wolf. Then when there is a problem, that signal gets lost in the noise of the chattering script.

Programming Woes

Monday, August 6th, 2012

In my career as a sysadmin, I have admittedly written less documentation than I perhaps should have. Some of this was because I felt like the people who would be using the programs / scripts I was writing should know enough to not need documentation, but some fraction of it was just outright laziness. I admit that.

When I did write documentation, though, I made damn sure it was accurate. Right now, I’m starting work on a new project using TurboGears2 on RHEL 6, and the upstream TG2 documentation seems quite thorough – but is horribly inaccurate in some rather annoying ways. I am admittedly not using the most recent version, since I wanted to use the version packages with RHEL – but even looking at the documentation for 2.0, it is inaccurate for what is actually available. The first error was in how the upstream docs told me to start a new project – the TG2 documentation for version 2.0 tells me to “paster quickstart” but the actual software (version 2.0.3) makes me run “paster create”. I had to figure this out looking at the error message I got in my shell when I ran “paster quickstart”. I’m not sure whether to blame upstream for bad documentation (quite possible) or Red Hat for dorking around with the package (also quite possible), but the end result in either case is a bad experience and a low opinion (so far) of TurboGears2 on RHEL.