kai_mactane

I keep hearing about developers who, when interviewing for potential jobs, consider coding tests to be “a waste of time”, “insulting”, or “beneath me”. The logic seems to be: Once you’ve risen to the level of Senior Developer (or some similar title), people should realize that yes, you really do know how to write simple pieces of code. You can write functions that sum all elements in an array, or reverse a string, or whatever.

I’m not bothered by them. I’m far too aware of the great number of coders that, to put it bluntly, simply can’t code. It doesn’t matter to me whether they’ve risen to their level of incompetence, or they’ve been in sky-high architect territory for too long and gotten rusty at function-level coding, or they’re simply lying on their résumé and they were never able to so much as solve a FizzBuzz problem. The fact is, they keep winding up in interviews, and it’s (part of) the interviewer’s job to weed them out. As quickly as possible, to avoid wasting any more time than necessary.

Back when I was in my first tech job, as a Linux sysadmin, I was one of the people interviewing potential candidates. I decided it would be nice to set them at ease by starting off with a few easy, “warmup” questions. So I’d start off with things like, “What is a runlevel in Unix? What are the most commonly-used runlevels, and what do they do?” Or, “What port does HTTP use by default? How about SMTP?”

I was astounded to find that there were applicants who couldn’t answer these questions.

Not in the sense of, “I’m sorry, but I’d have to look that up” (though even that would be a little odd; these are things any Unix sysadmin should have engraved on their consciousness). No, this was in the sense of “A runlevel? Ummm… I think I’ve heard that term, but I don’t know those kinds of details.”

My only real quarrel with FizzBuzz is that, at this point, any developer worth their salt is familiar with it. And tired of it. It’d be nice to have a few slightly new and different tests of completely basic competence… but you know what? Any test that is so basic would have to be just as boring. That’s okay.

These tests are essentially saying, “Prove that you’re not lying on your résumé.” And while I may know perfectly well that I’m not lying, how is a total stranger to know that about me? I’m not bothered by the “trust, but verify” stance of modern interviewers, because there are so many people who do lie on their résumés (and fail at simple, FizzBuzz-style tests) that it would be lunacy to blindly believe applicants any more.

(What that says about our society is a topic for another post… a post on another blog. It’s outside Coyote Tracks‘ scope.)

Originally published at Coyote Tracks. You can comment here or there.

If you haven’t been getting as much email as usual this past week, the culprit may be SpamAssassin. It turns out that SpamAssassin 3.2.5 (the current version, released in June of 2008) has a Year 2010 Bug.

The problem lies in the core configuration file 72_active.cf, which contains a wide variety of “currently active” rules. On line 543, it says:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

For those who don’t read regular expressions, this rule will match any Date: header that contains a string like 201x, 202x, 203x, etc., where “x” could be replaced by any digit. So, back in 2008, this rule would catch email that claimed to hail from the year 2010 or later. (Well, up to 2099.)

Starting on the morning of last Friday, this rule started triggering on pretty much all mail that hadn’t been delayed, thus adding 3.384 points to every piece of incoming email. Naturally, this could easily push mail over the threshold from “not spam” into “spam” when it doesn’t belong there.

If you’ve been expecting some mail that hasn’t arrived, and your mail host uses SpamAssassin, you might want to check your spam folder.

According to a note on the SpamAssassin project’s main page, you can easily correct this problem in either of two ways:

1. If your system is configured to use sa-update, run it now.
2. Remove the FH_DATE_PAST_20XX rule altogether by putting “score FH_DATE_PAST_20XX 0″ at the end of your local.cf file.

Alternatively, if you’re the mail administrator, and you don’t mind setting up a Year 2020 Bug for yourself, you could always change the part that says Date =~ /20[1-9][0-9]/ so that it says Date =~ /20[2-9][0-9]/ instead. After all, stuff that claims to be from years in the future (or past) is likely to be something you don’t feel like reading. But if you do this, I strongly urge you to find some way to send yourself an alert around December of 2019, warning yourself that you need to fix that problem. (And that may be easier said than done.)

Originally published at Coyote Tracks. You can comment here or there.