I’ve been a hiring manager for twenty years (low ’80s to low ’00s), but I haven’t done any hiring in the last (almost) decade, and I’m disappointed how things have changed in the software industry over that period.
I was hiring for technical support and programmer positions, ranging from IBM assembler and mainframe MVS experience to Java and Objective-C programmers; sometimes this would have been mainstream qualifications, and other times not. I did a good job of this; thinking back, most of my hires received a substantial promotion not long after joining – a real promotion, but just moving from a trainee grade to another; and some left to join Apple and other significant employers. I didn’t like that much, but I think it shows that my hiring approach was working.
Current practice seems to be to require applicants to jump through humiliating hoops to prove their current knowledge of existing technologies – JavaScript, C++, .NET, where the hoops are basic algorithm tests. But this doesn’t get anywhere near the real issues. However, I have the Internet, search engines, auto-completing syntax aware IDEs, and an excellent collections of books; and with new technologies coming out all the time, keeping up with the best solutions can be a full-time job. The exam approach just isn’t a good one; in fact, getting the right employee with this approach can only be a matter of luck, where the hiring manager effectively ignores the guidelines, knowingly or not.
I don’t want a new employee who will be bored with their routine work – I want to stretch them, and I want them to learn on the job; in fact, if they won’t be regularly learning, they are wrong for the job, and I don’t think I can emphasise this enough. I’m not alone in saying this; if you read any of the books and blogs over the last ten years, you’ll have seen this time and time again. So what’s going wrong?
My strategy was simple: I wanted to hire people like me. Specifically, people who can think, can learn, and were motivated to achieve. I also had a hiring trick: my benchmark, if you like, was (and is) the classic hacker, as described in the appendix to Eric Raymond’s Jargon File (see here). The Pragmatic Programmer book covers the same ground from a different direction, but the conclusion is just the same.
Post a Comment