fedward, tumbling

And Furthermore, Comma

One of the problems I have in looking for technology jobs is that I don’t actually care for or about technology in any traditional sense. I might not be a fan of a particular platform (or, well, several) but I also don’t go evangelizing for the platforms I develop with the most (use Perl;).  I’m also perfectly happy to drop skills and let them bounce around on the floor when they’re no longer useful to me (e.g. just about anything to do with Windows), knowing that if I have to deal with them I can just go pick them right up again.

My motto for jobs has long been, “anything you can fake for two weeks you can do professionally.” With a lot of this stuff I’ve had so much exposure to it that even if it’s not something I’ve recently been paid to do, I know enough of the fundamentals that I can pick up the details pretty quickly. I might be a bit too honest about this, actually, since if people are looking for somebody with experience with, say, Solaris, I’ll mention that my experience dates back to the Solaris 7/8 days and that as a Linux user I’ll find myself trying to remember command line options for non-GNU tools.  But I did build Solaris machines, and I compiled GCC on them because the standard compiler sucked, and and and. I did all that crap before, and I could do it again if I had to.  But I’m also not going to lie to somebody and say that I’ve run Solaris 10 or Windows Advanced Server 2008 or whatever, because I’d be caught in that lie. I can pick up the skills again pretty quickly, and I’m happier telling the truth and relying on my ability to learn or relearn on the fly.

But when you’ve been doing this for long enough — especially if you actually think about the work you’re doing — you become less mired in the technology and more interested in the problem and the technique of solving it. Except for the issues I’d have getting back up to speed on Java, if somebody desperately wanted to pay me to write in it I’d sit down with a decent book and IDE and get over it.  I’m more interested in delving into the business issue that has presented the software problem, so that the solution actually aids or fixes the business process. This is less about code than it is about understanding the real problem, and this is a hard skill to get across in an interview.

So what happens is that I’ll get into an interview and they’ll start trying to nail me down on specific buzzwords, and all I can do at that point is push back.  I’ve forgotten more skills than the average new hire has learned in the first place, because I’ve learned to optimize my memory for the tasks at hand.  I know that for certain tasks I’m going to be getting out an O’Reilly or The Book of Postfix or trolling the web for compiler options, because it doesn’t pay to commit that stuff to long-term memory. Maybe that places me behind the single-task guy who commits it all to memory, but I like to think it makes me a more rounded candidate and employee.

But I also often get a repeated question along the line of, “but what do you do?” Some recruiters and hiring managers can’t make sense of a resume that illustrates a willingness to forget how to do something. That’s not familiar to people, even though I’ve found it to be common among experienced programmers. If a skill isn’t immediately useful, keeping it on the stack doesn’t make much sense. To use a software analogy, a skill is like a module: load it in, use it, and let the garbage collector get rid of it when it’s not being used anymore.

What do I do? I use technology to solve problems. What technology? Well, that depends on the problem. What do I prefer? Whatever works under the given constraints. Is this too slippery an answer? It’s the truth. That’s the best answer I can give.

Thanks But No Thanks

The economy still sucks, and my consulting business has been way, way off, so I’ve been applying for jobs. This is hard because the set of skills I have is sort of sprawling and outside the scope of most corporate jobs (in that world you’re either a developer or an administrator, not an unholy mix of both with some business planning thrown in for good measure).  I do get called for phone interviews and I’ve had a few on-site interviews as well, but I haven’t yet gotten an offer.

One particular company took almost two months to go from receiving my application to interviewing me and finally rejecting me with a brief email:

While your qualifications are impressive, unfortunately we are not able to offer jobs to all the excellent and qualified people who have applied at this time due to the very high number of candidates.

OK then.  At least they bothered to send an email, which was nice.  But then, three weeks after sending me that email, they reposted the ad.

I’m OK with not being selected, but I am a bit confused. One of the tasks they URGENTLY* NEEDED TO DO was to migrate their company email off of sendmail and onto something easier and better to deal with going forward. I’ve done exactly that. Twice. In the interview I even talked about the tools and approaches that have made the process work.

* Well, not so urgent that they didn’t take two months to reject somebody like me. But they said it was urgent and they were sweating a little while they talked about it.

So while I’m OK with not getting hired, I’m in a bit of an information vacuum as to why. The way I see it, the rejection probably falls into one of two general categories:

1. Personality.  Geeks are all prickly, so I could easily understand somebody not thinking a particular person would fit in, except for the fact that IT departments are almost all misfits anyway, so I can’t really see how my personality would be any worse than anybody else’s. But maybe it is.
2. Experience.  And this is actually a two-parter: either I’m so experienced I’d be too expensive (possible), or I’m more experienced than the guy who’d be my boss — or at least I have so much experience that he’d be uncomfortable with me under him.

What I don’t understand is how they would choose not to hire anybody — leaving their urgent problem undone for that much longer — rather than pay the extra salary I’d cost.  It’s hard to be sure, but I have a suspicion that I was actually rejected based on both halves of the second point.  The guy who interviewed me on-site clearly had a lot of knowledge and had done the right things setting up their server room, but I think I made him uncomfortable.  It’s hard to attach a price to inaction, but I do wonder if that cost is less or more than a month of my salary would have been.

But that’s a business planning question, and outside the scope of the job anyway.