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.
