Thursday, April 12, 2007

Recruiting headaches; how not to get hired

I spend much of my time recruiting people for my technology teams. Currently we have openings for software engineers, QA Analysts, and a DBA. Thankfully I have corporate resources to post ads and review resumes. After candidates successfully navigate through HR, I do a short phone screen to gauge the candidate's ability to carry a conversation, and to match their knowledge with their experience (as it appears on paper).

I believe the best developers and testers have a strong academic knowledge of their profession. From this knowledge, good coding habits or solid testing methodology is learned. So my phone conversations always start with a discussion of fundamentals.

For software engineers, the conversation begins with a discussion of object oriented programming. Because I often catch candidate by surprise with this line of questioning, I always list the specific terms we will discuss. Abstraction, Encapsulation, Inheritance, and Polymorphism. I have been applying these concepts for nearly twenty years and expect every competent developer understands how they work in real world applications.

Of course some candidates can not describe OOP concepts. I usually give a lot of latitude on abstraction and encapsulation. These tend to be more conceptual than inheritance and polymorphism, which are implemented with specific language constructs. Imagine my surprise, though, when a candidate recently told me he did not know any of the terms.

When a candidate struggles with my OOP discussion, I try to give him some relief by asking him to define inheritance. Inheritance, after all, is fundamental to all modern programming and is easy to describe; simply define the word. But I was shocked when the candidate admitted that he did not know of inheritance.

This story should end right here, for at this point I politely ended my line of questioning and suggested that we did not have an appropriate "fit". The candidate, however, wasn't quite finished. He assured me that given proper requirements he could finish any project. Then he claimed that academic concepts weren't that important and if necessary he could easily look up the information he needed.

Of course he was wrong. A developer can not possibly build a class library or reusable object without understanding inheritance. In fact you can not write a meaningful Java, c++, or .Net application without inheriting an object. And you can not possibly know when to use an interface without understanding polymorphism. You can not implement objects without understanding encapsulation, and your objects will be a mess if you do not apply abstraction. Most of all, you can not hope to get hired into a position if downplay knowledge an interviewer deems important.
My quality assurance conversions cover testing methods in a similar manner as the OOP concepts. For QA, I have twelve types of tests that I expect a candidate to discuss. In the course of the discussion, I ask that the candidate describe how he applied each type of test in his experience.

I am guilty of acquiring my definitions of the tests from the web. I can't even remember where they came from, but we have a list of a few dozen QA terms. From this list I have flagged twelve to drill candidates. I always start by asking the candidate to describe Black Box Testing.

It was surprising when a recent candidate quoted the exact phrase "not based on any knowledge of internal design or code." Surprising because that phrase is an exact match of the definition on my sheet. I assumed this was a coincidence and continued.

But the next item was quoted exactly too. And the third, Unit Test was again quoted exactly, using the phrase "the most 'micro' scale of testing." Nobody talks like that. She could have at least used the word "smallest".

At this point I stopped her and asked what she was reading from. She denied reading the responses. I mentioned that I was reading my terms from a sheet that we had acquired long ago, and asked where she had gotten her material. I do not believe it is possible for anyone to have memorized those specific terms using such precise language. Again, she denied using reference material.

Generally speaking, I would not fault a person for using notes or reference material during a phone screen. But I expect they can show how an academic concept makes sense in real situations. I would also expect a person to acknowledge using reference material when it has become obvious to the interviewer. She had the opportunity to look resourceful, but instead looked like a cheat.

In both these cases, the candidate's resume looked great but they weren't a good fit for our team. These candidates simply didn't apply common sense to our conversation. Want to know how not to get hired? Simple, be unprepared, lie, or ridicule the interviewer's questions; it's guaranteed to keep you out of the position.

4 comments:

  1. Wow!

    While I'm all for learning on the job and knowing how to look up things I don't know already, I absolutely agree that you have to have the basic vocabulary in place in order to understand what you're looking up! So, first guy is out.

    For the woman who refused to say that she was cribbing definitions... anyone who says, "the most 'micro' scale of testing" gets black marks on their ability to communicate with other developers. Okay, that might be a little extreme, but I'm just surprised that she didn't rewrite it in more natural english when parroting it back to you. If she's not savvy enough to do that, or doesn't understand it well enough to do so, that's no good at all.

    ReplyDelete
  2. I found the first guy very irritating. Not only was he unaware of the basic OOP constructs, but he implied it was not necessary knowledge to be a good developer. The idea being, the end justifies the means and he can get the job done without the academic background. Of course, without OOP none of his work will be reusable. And if he uses the Visual Studio designers, then his work will be difficult to maintain too.

    ReplyDelete
  3. I wrote a plugin for the Eclipse IDE once. At the time, I was fine with OO and programming in general, but I didn't know anything about the "design patterns" community which has sprung up in the past 12 years or so. In fact, I'd actively avoided reading the design patterns literature, because it seemed like any time someone started talking about patterns, their eyes would glaze over and they would insist on seeing patterns everywhere...

    The structure of Eclipse is pretty non-intuitive if you don't know the "standard" design patterns, and more importantly, the vocabulary used to talk about them. Everything was hopelessly indirect. I muddled through, but there were definitely parts where I was just copying someone else's style because I wasn't sure how this piece or that fit into the big picture.

    One of the good things going back to school has done for me is to force me to learn some of the things I'd avoided. Eclipse makes more sense now. More importantly, Java (and .NET) terminology also make more sense; they're both pattern-rific, although Java's old enough that what should be called "StringBuilder" is called "StringBuffer", because the language hadn't set yet.

    If I'd had the knowledge of the literature, it would have been much easier to work within Eclipse. And I've found it useful since then, when talking with the few other real-world programmers who also speak patterns. It's been a win for me, except in the cases where you spend more time quibbling about pattern definitions...

    ReplyDelete
  4. Being on the interviewee end of similar questions, I can empathize with the first interviewee's complaint about "academic" questions. There is a danger in asking such questions, only because you're not really testing the applicants understanding of the concepts so much as their ability to articulate that understanding. Important or not, articulation and application are often very different skills.

    Of course, that doesn't make up for being underqualified and obnoxious.

    ReplyDelete

You might also like ...