Writing

Feed Software, technology, sysadmin war stories, and more.

Sunday, November 4, 2012

Passing the test and failing the interview

I've had some thoughts about how to hire good people for a programming position. Some of them are the typical things everyone else seems to talk about, but once in a while I come up with something which is nutty and strange. I'd like to share a couple of my ideas on the matter.

Obviously, if you're looking for someone who can write a given language, then you'll probably wind up asking them if they can answer some questions about it. This might include trivia, coding on the whiteboard, or even performing feats of hacking in a shared workspace while they watch you. Yes, some places use a shared notepad type program for this, but others actually have a full-on development environment where code can be compiled and run.

But that's all old hat. Everyone knows about that. I started thinking about some other things you could do, and my thoughts went into some potentially evil places. I came up with the notion of negative testing.

Right now, if you take a test, you probably assume that passing it will get you good results. It's a safe bet that if someone asks you to code C++, they probably want to make sure you can do C++ for them. What I'm talking about is trying to take that same behavior and turn it on its head. Basically, find out who's been tainted by some technology which you find undesirable.

Let's say I really don't like the kind of programmers who use language X. I might add a portion of the interview to assess their proficiency in that very language. Then, if they turn out to do really well in it, I might find out that is their language of choice. This might tell me that it's shaped how they think, or they like it because of how they already think, as the case may be. If this style is incompatible with whatever I was trying to accomplish, their high score on that test might actually exclude them from further consideration.

Maybe that one's a little extreme. Well, I'll try another approach which might make more sense. Maybe I really hate people who genuinely espouse the so-called "brogrammer" thing. I realize most of that is just people trying to be funny, but there are a few bad apples out there who really live that way, and they need to be avoided at all costs. For that scenario, perhaps I would design a test where only the bad people would excel. Then, I might be able to use that as a signal for "no hire".

Of course, there are other ways this could be used, and they're not necessarily good. Maybe someone would come to the conclusion that graphic designers make horrible systems programmers and vice-versa. (This might be true, or it might not. I don't know.) Anyway, let's say they're hiring for a systems job. They might ask you to do some graphic design work.

If you excel at that, they might conclude that you're no good at systems work... or you're that rare (as far as they're concerned) specimen who can somehow do both. Either of those conclusions is a valuable signal to have at hiring time, so determining it would be seen as a win.

I'm not sure if this happens in real life. Can you think of a time when being good at one thing automatically excluded you from another based on the perception it was an either-or proposition?

People wouldn't really think like that, would they?