As friends of mine who became victims of the recent US economic crisis start to look for jobs, I am often getting, usually over (a few) beers, very scary stories about what it is like interviewing today. Sadly, it is reminding me that not much has changed since last time I interviewed during hard economic times, back in the early 2000s.
Lets face it, technical people are mostly horrible at technical screening. We choose questions from lists, like a famous one Scott Hanselman put on his blog a few years back. And then if someone knows a sufficiently high number of trivia questions, we assume they will be a good developer, and the next phase starts, which usually involves making sure they shower, shave, etc. – and are not a total psychopath.
The real issue here, of course, is that forming good technical interview questions extremely difficult. Ideally, most companies would hire for aptitude, since we all know that good developers learn things very quickly – that is part of what being a good developer means. Sadly, many still do not.
Let me illustrate through a story. Lets say that, for sake of example, someone was hiring a developer to build something useful, like the i4o indexed Linq framework that I wrote a couple years ago – and continue to maintain to this day. My guess is that if someone else were trying to build such a framework in 2007, given that in 2007 I had zero Linq experience – other than a vague idea of what it was for, I would have never been even granted an interview, much less passed it.
I, like most developers, learn things when I need to learn them, rather than just studying trivia just for fun. Thus, I learned Linq – because I wanted to write an indexing framework. On a Friday night. During which time I wrote 500 lines of code. By the end of that architectural spike, I had the essence of i4o working. I then spent the next Saturday – another 8 hours or so, cleaning things up and handling some corner cases. No experience to working software that – now – actual software companies like Component ONE are copying and selling for money (see LiveLinq).
The point isn’t that I was, or am, some sort of genius. Actually, I am a rather ordinary software developer. The thing is though that despite all the world’s APIs, I understand computer science. In college, we had classes for:
- Algorithms and learning the meaning of computational complexity (i.e. why a hashtable is faster than a linked list – and why the former takes up far more space)
- Software Design – where you learn about the general value of reducing coupling and limiting scope of variables (the “fewer moving parts” bit of software engineering)
- Compilers – so you understand what happens when you, well, compile from the language into native code
- Language Paradigms – Procedural, OOP, Functional (F#, Haskell, etc.), Logic, and yes, God’s Language, Lisp
- Operating Systems – so you understand the environment of most things you will write, what processes and threads are, etc.
- Databases – so you understand how things generally get persisted, normal forms, and so forth
Frankly, everything important I know about software architecture is in one of these, or a small number of other more fundamental areas. When I operate in a programmer role, I only decide to understand what I need to understand when I need to. Lets put it this way, if I had to design a multi-threaded system in Java in 3 days, I probably could. Not to take anything away from Java gurus, but given I know that Java is a language that generally runs on a JVM, that it probably has a thread system, that there are probably some libraries people use to manage that and not have to operate on thread primitives most of the time, I could be reasonably competent in not very much time.
But this is really the symptom of the larger problem. The real issue is that some companies, when they hire software developers, hire them like contractors. I understand testing for how well someone knows a given part of an API if all you are going to do is bring them as an expert in that API for a month. In consulting, we run into that interview all the time, and expect it.
The problem is when companies who are hiring for long term – who should care about very different things, start with questions like “what are 4 methods supported by all delegates in .NET? (know 3… not good enough… gimme 4 you idiot!)”. I am convinced that people who do this kind of interviewing really don’t care that much. They want an easy screen that is easy to administer, makes them feel smart (because it is their own favorite API), and gives them plausible deniability if a hire fails (well, he passed the “hardest test we had”, not my fault he came in and messed up the group).
Real interviewing is hard. I don’t know all the answers, but a a good starting place is Joel’s “Guerrilla Guide to Interviewing“. And for the candidate, frankly, I would tell you, strongly consider whether you would want to work for an organization that relied on quiz show, trivia question interview techniques. While not reliable, there is a pretty good unscientific correlation between “cultures of asshole”
The Nomadic Developer 