I do this mostly as I don't get enough time to interview someone - 1 hour is not nearly enough time to get to know a person's technical and soft skills. Also my focus tends to be on the technical questions since these questions allow for a good "Apples-to-Apples" comparison which leaves less room for mistakes.
So here are my favorite questions to ask - I have plenty more, but these ones I've found really useful - often for surprising and unexpected reasons. Sometimes the answers aren't as important as the attitude taken in responding.
The "obvious" side - Technical Q&A
Q 1: When does the JVM do Garbage Collection?
This is kind of a trick question as the answer is really "it depends".
REALLY WHAT I'M ASKING: Do you really understand the language you use almost every hour of every day? Do you know what's important and what's not?
NOTE: The non-verbal response to this is almost as important - it catches people by surprise quite a bit - but for two different reasons. One response style is for those who don't know the answer. The other is for people who know the answer but are wondering why I'm asking.
Q 2: What's the difference between an interface and an abstract class?
REALLY WHAT I'M ASKING: How good are your oral explanatory skills? This is a somewhat complex topic under interview pressure.
NOTE: Amazing how many times this trips up so-called Java experts.
Q3: Name the different types of JDBC drivers?
REALLY WHAT I'M ASKING: Do you understand the tools you use everyday especially when it comes to performance
NOTE: Those who've really been involved in, or care about, performance tuning really understand their JDBC driver inside-and-out and will know a Type 1 from a Type 4.
Q4: How do I find out how many rows there are in a ResultSet?
REALLY WHAT I'M ASKING: Everyone's done this or should have, but what's the best way?
Frankly sometimes there are no short-cuts.
NOTE: Often really good Java developers are hoping I'll have a short-cut / high-performance answer to this. Unfortunately there is none (that I know of). However the "interest" they display is a good sign because it means they care about doing things better / faster.
Q5: Does Java use pass-by-value or pass-by-reference semantics?
REALLY WHAT I'M ASKING: Again, do you really understand the language you use almost every hour of every day?
NOTE: Amazing how many people get this wrong - even people who claim to have passed SCJP or even those working at Sun for years!
Q6: What does "NULL" mean in SQL?
REALLY WHAT I'M ASKING: How is data (or the lack thereof) represented? Do you really understand relational databases?
NOTE: It's amazing how many people very familiar with databases and/or are Comp Sci graduates who don't really know this.
The not-so-obvious side
What happens when you don't know the answer? Do you bluff or just admit it? Are you interested to learn and grow? Do you get angry and say "Why would anyone want to know what?". I've seen all kinds of interesting responses here.
I'm also looking for elements of developer-to-developer 'rapport' - interviewer and interviewee probably faced the same issues at different times in different jobs and that shared experience can help build some initial camaraderie.
Also important are the questions the interviewee asks
- What's your Source-code Control system & your IDE / Tool-set
- What are the Team dynamics (individual silos vs. more "group-oriented" work)
- What's the Release schedule look like?
- Hours worked each week?
- Company's financial state and outlook?
All these are good signs.
What I don't ask
It may surprise some folks but unlike some technical interviewers I don't ask the quasi-legendary puzzle questions. One of the reasons for that is that I find I don't do that well on those questions myself without lots of practice. But more importantly I don't find the exercise indicates much about a developer's skills per se. They're all too reminiscent of the SATs and GRE exams which don't really indicate other key aspects of a person's personality e.g. persistence, motivation, inquisitive nature etc.
Probably the biggest point of all . . . .
Most of what a developer does everyday is not abstract problem solving (I can hear a collective "WHAT!?!?!?") - but think about it - you really spend a lot of time figuring out how to implement the solution to an abstract problem? There are always people around who can help you find the (abstract) solution but few people who will implement it for you!
For example - let's take a requirements for a high-performance message-based system - which listens to stock price changes and updates a database. I might already know the solution will need multiple threads, a thread pool, a JMS provider etc. but . . .
Should I write my own pool or is there a good package I can re-use (JDK 5.0 has some awesome utilities for this)? Also . . .
- Should the pool grow to meet demand (probably)? By how much?
- What if the pool can't grow enough to meet demand?
- Do I need a "reaper" thread?
- What's the best way to stop a thread when it's been idle too long? What is "too long"?
- How do I ensure as little locking of common resources as possible but allow for shared caches?
- How should a thread handle an exception? Checked or Unchecked?
- Should each thread have it's own dedicated queue?
- Should they be listening to a global topic instead?
- How do I prevent deadlocking on the database?
- Does my JDBC driver support connection and statement pooling?
- How do I unit test each Thread?
- How do I test for possible race conditions?
- At what point are there simply too many threads and it hurts performance.
- What if JMS crashes? Should messages be persistent? How do you ensure each message is processed only once?
That's a lot of questions and the answers to these questions are rarely abstract - that is they are not algorithms independent of the implementation. The solutions depend very much on whether you are using C, C++, Java or C# and hitting Oracle, Sybase or MS Sql Server, using MQSeries, Tibco or Sonic MQ? These are nitty-gritty implementation issues which depend more on your experience and willingness to investigate than on abstract problem solving. Even the JDBC and JMS APIs don't obviate the need for understanding the underlying database / messaging platforms.
Above-all, I think the most under-rated (and under-interviewed) attribute of a developer is persistence rather than problem-solving. Will you stay plugging away at a problem, trying different angles, working with different people until you can solve it? Will you write a good set of unit tests before declaring victory? Will you trawl through Google to find an answer when your JDBC driver doesn't behave as expected?
So for me, often the Java/J2EE questions I ask (e.g. nitty gritty details of JDBC drivers) are really about finding out how deep / far you have gone to solve common issues (e.g. error handling, resource cleanup, performance tweaking etc.).
I've been quite disappointed lately about how some people shamelessly pad their resume. Now I'm not talking about cases where a person says s/he has used JDBC and doesn't know it inside-and-out. I'm talking about people who, for example,
i) Claim they are "expert" in MQSeries but don't know the difference between a Channel and a Queue!
ii) People who claim 5 years of JDBC but then can't tell me the different types of Statement objects!
I'm talking blatant exaggeration.
Finally then there are the needles in the haystack. The people who just have the "gift" - they're gonna kick ass and probably teach you as much as you can teach them.
When you find that person, all that effort is worth it.
BTW I'm sure interviewees have similar bad stories about bad, disrespectful or dishonest interviewers - I know I have - and I would love to hear them or other good / favorite interview questions!
Compare and Contrast
Just recently I read Joel Spolsky's updated Guerrilla Guide to Interviewing (version 3.0)
and although I respect Joel quite a bit I was quite surprised that there were a few specific details I disagree with him on.
For example he says "If even two of the six interviewers thinks that a person is not worth hiring, don't hire them . . . I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn't like them."
Frankly I disagree here - if you hire this person and one of your developers gave the person a "No Hire" you may have gained one employee but "lost" another. I've had managers hire developers over my "No Hire" recommendation and I found it very frustrating - especially so when the person turned into an unmitigated disaster.
Perhaps Joel would think of me as a "Quiz Show Interviewer" - the things I'm after might seem like trivia but I feel they are very important - understanding how to release resources, how JDBC works, how to use threads etc.
In particular I 100% disagree with the idea that "software teams want to hire people with aptitude, not a particular skill set.". Huh? Frankly I have a particular job that requires a certain skill set and really don't have much time to teach a person that skill set. True, they definitely need an aptitude to learn - but people with strong skill sets have strong skill sets for the most part BECAUSE they have the aptitude to learn. I'm not jumping from Java to C# or Ruby any time soon so I need people with good/great Java skills!
It takes years to learn good exception handling, resource releasing etc. in Java and I don't have time for someone to learn that (as a Senior Developer) on my or the company's dime.
I agree with him, though, that you should look for people who show passion, can explain things well and exhibit leadership potential.
In the end we're both after the same thing we just have different ideas (personal conceits) about how to get there. I'm still learning how best to interview and after writing this and reading Joel's article I definitely have some things to think about.