Testing your techies
A couple of interesting posts here and here about hiring techies in libraries. As I have ideas about 644 swirling around in the back of my head, those posts settled nicely into a slot in my slate of class-opener “practical sociology of IT in libraries” sessions. It’s certainly an important question.
I do want to call attention to a couple of things. First, that tests like this may exclude some candidates you might not want to. If you’ve got candidates beating down your door, exclusion is one thing. If not, it may be something else. I don’t have a cell phone. I’ve never texted. What bearing this has on my ability to run an IR I must say I don’t know. To be sure, one might not hire me as a public-services techie without at least a strong hint that tying in to Cell Phone Cultcha might be a good thing… but the lesson here is to keep your tests focused on what you expect your new techie to accomplish.
(I do take such hints. Let’s all recall that I learned to drive so I could visit state university campuses. I’ve even driven to campuses since!)
Also, let’s not forget transferable skills. I think it’s dead stupid to give any techie a code test in a specific programming language. Programming skills transfer from language to language. If they absolutely must hit the ground running (especially with no previous code to work from), then okay, I can see the point, I guess. Otherwise? Forget about it. Ask architecture questions, ask problem-solving questions, ask troubleshooting questions, ask them to write pseudocode, let them write in the language of their choice—but don’t ask for code in a specific language. Stupid.
(Let us remember that HTML and CSS are not programming languages, okay? It’s absolutely appropriate to test a putative web designer for these.)
Some techies are probably bristling at this point… but honestly, I’m not. I was recommended to consult on a DSpace-related project for a library consortium, and frankly, I was not what they needed. They needed a programmer, and I am not one. Yet I was apparently recommended on the strength of my knowledge of DSpace internals. I told them I wasn’t a programmer, but either that didn’t register or they didn’t realize where UI fiddling (which I can do) shades into Real DSpace Hacking (which I can’t).
Guys, the DSpace UI I know quite a bit about, because UI design crossed with web design is kind of my thing. I know something about how the DSpace database is put together, because I go in and fiddle with stuff (don’t tell my sysadmin this! he must never know). DSpace building and configuration I know less and less about every day because it’s not my problem these days. The rest of DSpace’s innards I have only a vague architectural sense of, and the current state of the DSpace technical documentation is so sad that I can’t easily find things out using my ’leet RTFM-fu. Let the record show that henceforth, please!
I haven’t heard from the consortium in a while, and I don’t expect to. I’m honestly not even planning to bill them; I don’t bilk libraries, it’s bad business. I couldn’t help them, I didn’t do anything for them I wouldn’t do for free for a colleague, end of story—I’m dumb, but I’m honest. But if they’d had a better way to articulate and test for the skills they were really looking for, neither of us would have wasted time on the other.
So the idea of testing has merit, if pursued with due caution. You’d ask a potential cataloguer about tricky MARC situations, wouldn’t you? This is no different.