The Puzzle of Hiring Technology Professionals
Hiring talented technology professionals is hard. There is no way to guarantee you’re getting a winner. A lot of methods that companies use to determine a candidates skill level are often inadequate as well. What are employers to do?
Do we test all prospective candidates? This seems to be a popular method, but it is deeply flawed. I have been a strong contributor on a number of projects, built applications from the ground up, and have generally met with a high level of user acceptance. Yet I have failed most every technical exam I have ever been given. Why is that? How is it possible that I can competent at my job, but fail a technical skills test? Actually, the answer is quite simple.
Technical tests are often more about rote memorization than actual technical understanding. If I haven’t done something in awhile or I am about to attempt to do something new, I can find information that shows me how to do it. Once I understand the basics, I will attempt to do one better, or use that information in a more complex way. A lot of developers can’t program beyond what they’ve been shown. Someone might be able to implement a program based on examples they have seen, but never do much beyond what you show them. Many people may be able to discuss concepts and memorize vast amounts of information, but be able to do little with it. The only thing a technical test will give you is someone who is good at remembering technical details. That is not the same thing as a competent developer!
How else can you gauge ability though? Asking similar questions in an interview is going to give you similar results to having just given them a test. Some places say they use it as a way to gauge a person’s problem-solving abilities, but I rarely see that in action. I’ve also seen a number of companies try to purposefully stump candidates. Why? What does that accomplish? They’re coming into the interview cold with no idea what to expect and you’re asking them questions you already know the answer to. When interviewers begin feeling pretty smug that a candidate doesn’t know an answer, I get frustrated. Sure, it’s easy to feel superior when you already knew the question in advance, how is this helping you hire someone again?
What would I do in a technical interview? First of all, I’d set aside some time to actually talk to the candidate. This is important because you’re not going to be able to tell if they are going to be a good fit by trying to cram everything into a fifteen minute interview. I would ask some core technology questions. I want answers that show an understanding of both concepts and execution. If they have the basics down pat, then that is a good sign right there. Then I would ask them about more advanced concepts, not in the sense of “how would you do X” though. They’re on the spot and you rarely see things done like this in the office. Even under tight deadlines I don’t have to sit there and design a solution with my manager looking over my shoulder.
What I want to see is someone who is passionate about their work. Someone who can tell me with concrete examples what kind of work they have done and how they went about doing it. Explain to me how your past application worked and what your role in implementing it was. A fraud isn’t really going to know, they aren’t going to understand. They’ll be vague about their role, they won’t explain the inner-workings. The Real McCoy will happily discuss a project they work on, they’ll be able to explain it in detail. Not only that, but if it was something they were proud of, they’ll happily discuss it.
Not that you won’t still get some bad eggs. Still, unless you really get to know your candidate and understand how they feel about their work, you are still shooting in the dark. Someone who passes a test isn’t necessarily a good employee. An interview is supposed to be about getting to know someone. I’d rather take someone passionate about their work over someone who is good at memorization. Unless of course you believe in the myth of the commodified developer, in which case you may be better off sticking to the technical tests.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
May 1st, 2006 at 8:14 am
I’ve stayed away from specific technical questions when I’ve performed interviews, preferring to judge them by describing specifically the recent kinds of projects they worked on and getting details on what went right, what didn’t, how they handled it, etc. If you can get a handle on the kind of job they were doing, you can tell they kind of job they’d be capable of, generally.
I’m actually fervently against tests and quizes as mandatory parts of a job interview. They’re not a realistic model for how developers work anyway. I’ve never come into work, sit down with a cup of coffee, and answered a multi-part question in under thirty minutes … so why would I care how well a candidate could perform such a task?