I started out writing a bit about mock objects but this topic has been on my mind lately so I’ll cover it first. Plus, my mini rant about the proliferation of long resumes seemed to hit a nerve.
I’m curious how others approach their interviewing? Do you go hardcore on the tech questions? Or ask specific questions about their experience? Maybe you look for aptitude more than direct relevant experience?
I’m been trying to hone my approach lately. In some ways my approach has to been to give the developer open ended questions and see if they answer them or hang themselves, to borrow a phrase. Basically, I start asking questions about decisions they have made at previous jobs and projects that they list on their resume. The first thing it tells me is if they actually worked on the projects I find interesting. You’d be surprised at what I come across. I had one guy spend almost half a page talking about these business processes that he built so I asked him how they were configured (i.e. XML or some other metadata) and what tools he looked at to help him solve the problem. He immediately fessed up that they were just hard-coded Java classes and weren’t really workflow. That pretty much sunk his interview, although he wasn’t doing great up to that point anyways. The good candidates tend answer the questions pretty quickly and don’t go overboard with their descriptions. They show they know their stuff and then tend to ask questions back about what other specific things I’d like to know. Bad candidates usually go off on tangents and never get around to answering the question. I don’t stop them, either. I want to see how far they’ll go.
The next step after these types of questions tends to be specific questions about tools that they have listed knowledge about that I have strong knowledge in. For instance, if they’ve listed Hibernate experience and claim their skill level is like a 6 or 7 out of 10 I ask specific questions about the difference between the session and second level caches. If they know that then I go in to questions about how they’ve configured Hibernate. Then maybe on different ways to model a many-to-many type of relationship. I like to dig and see if they’ve really used the tool and then pose what-if questions to see if they understand the tools they use as well.
Last (hey, I only usually have an hour with them) is the coding challenge. We make candidates code. Lately I’ve been using a challenge to make them write a random weighted list implementation. It’s basically a weighted round robin algorithm implementation. The code for it is actually quite simple. It’s maybe 8 real lines of code if done correctly…something like that. The first thing it tells me is if they can think through a problem and come up with a simple solution. The last thing I want is for them to start inspecting return values and insuring a specific statistical return percentage based on an item’s weight. That’s just ridiculous. The second thing it tells me if they read requirements. I give very specific requirements and in some ways make it easy if they would just read and think for a minute or two before starting their response. Most don’t. I then look at the solution. If they do things like make the class immutable to keep the implementation simpler then they get bonus points. Even more if they can coherently explain why they did what they did as well. Hey, they might have seen the question on the Internet and are good at regurgitating without understanding.
So anyways, after using this approach for a while I’ve started to ask a little more Java related skills to see if they understand the language and programming concepts in general. It seems that folks that know the little things tend to be developers more interested in their craft as well. My latest test (and I came up with this when discussing the answer to the first question with a candidate) is to give them a simple Java class that is mutable. It has a default constructor and a getter and setter for an attribute. I then tell them to modify the class to be immutable. No sub-classing or anything like that. Just change the code. Again, I get some very strange looks and even stranger responses. It’s kind of boggling that people with a good deal of experience don’t even understand the concept of immutable or can even describe its benefits.
That was longer than I expected. Well, if you guys have any ideas or tests you like to use, drop me a line and let me know what you do and more importantly why you ask and what their answers tell you. That’s more important than the question in my opinion.
Predictable Chaos 
To answer one of your questions. I do try to “hang up” the candidates by asking some very hard questions (garbage collection, APM, etc). I’m not neccesarily looking for the correct answer though. I want to see how the candidate responds. I’ve had several candidates get angry at me for asking such questions. Obviously, they didn’t get the job. My goal is to determine how the candidate responds to adversity because nobody will ever have all the answers. If they act that way during the interview then I certainly don’t want to work with them.
As for the programming task, I’m thinking about coming up with an exercise so that I can pair-program with the candidate. I want to get a feel for how well this person works with others. For us, we are not looking for “rock star programmers”. We just need folks who are competent with the technology and will work as a team.
Hi,
I’ve seen a lot of interview-code-test-approaches, and to me it seems rather useless to provide a set of requirements and then see if the candidate codes the solution just the way you’re looking for. If a candidate has no experience with the exact algorithm youre hoping for, but have tons of experience in other (more total) areas – they most propably will slip your “right-on-the-nail”-test. I’ve found a better way to test the programming skill’s of candidates – to perform code review together, using some central business code and let them comment as we go along. To me this gives much more information than an explicit code-writing test.
Hi WiDef,
I agree that it’s unfair if I were to excuse them if they don’t get the answer just the way I’d like. The particular test I chose is also good because it tells me whether or not they tend to read requirements before attempting a problem as well. The questions they ask are also a good barometer. For instance, I had one guy spend 5 minutes asking me questions about a requirement where as the exact answer was in the next section if he had just bothered to read it. After telling him to finish reading the requirements for a few minutes I finally just pointed it out to him and he was like, “oh.”. A developer that don’t read requirements before jumping to conclusions is not a good sign, either. The other part it tells me is how well they structure code. The good ones will at least get the class structured right since I specifically state that I want a class that takes a list of objects and then a function within that returns a random item from the list, etc. What I get most of the time is a single function that takes a list each time they want a random object. Again, not what I specifically listed in the requirements. No one thing will sink them in this test but it gives me multiple points of information and areas that I will tell the next interviewer to watch for and give additional feedback on. I am tempted to just say, “make the class immutable” and see how many understand what that means but at the same time I don’t want to overwhelm the person with multiple things at once.
It’s something I ask the developer next, though. “How would you make this solution immutable and why would it benefit your code?”.
Thanks!