« Showing compiled... | Main | How to Interview... »
Tuesday Jun 20, 2006

How-to Interview Java Coders

Interviewing to me is definitely a trained skill that you have to practice with. Your goal is to extract as much information from the candidate so that you can make a useful recommendation. If you get too little information then your recommendation will contain more of a risk.

Each candidate that is interviewed is a different person and thus each interview is slightly different. For example: A candidate directly out of college will be asked different questions then a person with 10 years in the industry.

Regardless of the person, if they are wanting work as a professional programmer then they need to know a few of the basics. For the most part, it comes down to communication. When you interact with other programmers you have a basic vocabulary that is used. If the candidate doesn't have that vocabulary, then communication between the candidate and the other developers will be hindered.

I also am a strong believer that if you are going to work in the industry, you should at least have a basic understand of the underlying workings of a computer. Thus my questions are more general, yet still technical.

So this is my personal interviewing technique. One thing to note is that I try very hard to not ask trivia questions. These questions are things like "What does transient mean?". Guess what, I can look it up if I need it. I'm much more interested in if the candidate has a good solid base to grow with.

The first thing I hit on is what is a bit and a byte. From there I ask the primative types in Java and their sizes. The sizes question shouldn't be difficult if the candidate understands basic memory storage. Simply start with byte and work your way up, increasing the power of two each time.

Directly following this is a discussion about Data Structures. Remember your old friends (Map,Set,List,Array,Tree,Graph,Stack,Queue)? Hopefully you can name a couple of these, explain what makes each of them special, and have an example of when to use them. Oh, and a good side discussion regarding the equals() and hashcode() methods is good here as well.

Next is basic OO terminology. This is that vocabulary I discussed above. Polymorphism, encapsulation, interface, inheritance, overloading, overriding, pass by referrence, object, class, abstract class. If you don't know these then how can you a)communicate with your co-workers and b)create object-oriented software?

After OO I look at the resume and determine if they have database experience and if they are comfortable answering database questions. If yes then I would discuss primary keys, relationships, common database problems, and joins.

To round off the technical portion of the interview I discuss software designing. Things like coupling, cohesion, design patterns, tiered architecture. Usually I also go through a modelling question as well to see what types of behavior and attributes the candidate can come up with. The modelling question has been an item of hot debate with the team and we have yet to find a question that we are happy with.

My final technical interviewing requirement is asking the candidate to code. What? Code at an interview for a job that requires coding? That's crazy! The sad fact is that I have never been asked to code at any interview I've gone through. Would you hire a knife throwing juggler without seeing him or her juggle? NO! So why do we allow people to code without seeing them, well, code?

It doesn't take long to come up with some sort of coding exercise that can be written on the board or a piece of paper. Yikes! No IDE for help? Well, yeah, see the idea is that the exercise shouldn't really need an IDE. It should be simple enough to finish in 5 min, yet hard enough to get some sort of information from it. Currently the "Write a function to reverse a string" question has been working well.

If the candidate passes the technical portion of the interview, then it is onto Step 2, the soft skills interview.


Posted at 11:50PM Jun 20, 2006 by Aaron in Java  |  Comments[19]

Comments:

"What is a bit and a byte?...primative types in Java and their sizes?"

Guess what? I can look that up too. It's trivia, but at a lower level.

Posted by Rufus on June 21, 2006 at 08:11 PM CDT #

Yes, this is true, you can look these things up, but this information should be at the tips of your fingers. It is also something that everyone, regardless of their speciality will use every single day.

Posted by Aaron Korver on June 21, 2006 at 08:37 PM CDT #

The "reverse a string" question is really old. There are two basic methods, one of which involves XOR, and is therefore "better". But who hasn't done it before?

Posted by namehere on June 22, 2006 at 02:06 AM CDT #

No, not everybody needs to know how many bits are in a float every single day. Where do you get ideas like that? If I had to spend my workdays counting bits, I would go out and find a more interesting job. Shoveling dirt would be more appealing.

Posted by Rufus on June 22, 2006 at 09:02 AM CDT #

I tend to agree that the bits and bytes and sizes questions aren't really that revealing, although I suppose I would be concerned if someone didn't know what a bit is. On the whole your interviewing approach seems very solid. Personally I might use a more involved programming problem that exercises some of the stuff discussed ealier in the interview. I wonder if Microsoft is still using their old and tired problems twiddling with arrays and strings?

Posted by Fred Garvin on June 22, 2006 at 11:26 AM CDT #

In java without doubt the best way to reverse a
String is new StringBuffer("string").reverse().toString();
probably spread over a couple of lines.

Unless there is a very good reason to duplicate core functionality you shouldn't do it.

Of course you may need to do this *ALOT*, in which case you would probably implement something yourself, but then again you may wish to consider your string storage mechanism, but that's probably a completely different question.

Posted by David Hutchinson on June 22, 2006 at 01:09 PM CDT #

Namehere -- Yes, the question is asked alot, yet, when asking candidates they either fail terribly or they get it.

Rufus -- You really do need to know the number of bits. I'm not saying you have to consciously worry about it every day. But it is the foundation of our profession. Would you expect a Chef to not know about salt? Or a Banker to not know about pennies?

Fred -- If there is time we may use a more involved programming exercise. We have also experimented with giving an exercise and asking the candidate to complete it BEFORE the interview.

David -- StringBuffer is syncronized, so it tends to be a bit slower. I'll be posting a quick run down of just a few ways to reverse a string and the performance of each. Stay tuned.

Posted by Aaron Korver on June 22, 2006 at 06:51 PM CDT #

I wouldn't say the 'transient' keyword is a bit of trivial, it's a useful tool when you're serializing objects. Most people just implement Serializable without considering what happens to the object. You wouldn't want to serialize a local file handle if the object is being use in RMI.

But I agree it's not something to bring up in a first interview, but if a candidate is going to be working with serialization, they need to be aware of it, because if they aren't, how are they going to know to look it up?


Improving on David's suggestion, you can reverse a String without synchronization in Java 5 with:

new StringBuilder("string").reverse().toString();

Converting a String to a byte[] or a char[] and reversing the array in Java is wrong because a character may be longer than a byte or char. Doing so would indicate a candidate is unaware of Unicode and i18n issues.


Don't get me wrong, I think your outline for an interview is good and covers all the important things. What I struggle with when interviewing is the technical details. If I'm interviewing someone for a senior Java job, I want to make sure they really know the language, but you don't want to lose someone because they got a bit of detail wrong. Coming up with a coding task that can do than and fit into a hour is very hard and something I'm still working on.

Posted by Miles Barr on June 25, 2006 at 02:39 PM CDT #

How about asking the interviewee how to spell 'candidate'.

Posted by jmalon on June 26, 2006 at 06:52 PM CDT #

I generally agree with most of what has been said in both the article and in other people's comments, so I'll just comment on something else.

For someone who places a lot of value on communication, your ability to correctly spell leaves a lot to be desired. Just two examples: "canidate" and "inheiratance".

Written communication is as important as its oral counterpart, wouldn't you agree?

Posted by Wagner on June 26, 2006 at 07:28 PM CDT #

I disagree. You tend to interview a computer science student other than a effective programmer. Good luck

Posted by pcdinh on June 26, 2006 at 08:44 PM CDT #

Jmalon and Wagner -- thank you for pointing out my spelling mistake. I do agree that spelling as part of communication is important and I have corrected the errors.

pchinh -- I agree that you interview someone out of college in a slightly different manner than an experienced programmer. However, they should still know the basics.

Posted by Aaron Korver on June 26, 2006 at 11:12 PM CDT #

So what about SCM? What about build management? What about bugtracking? I totally disagree with your interview style, every "sun-certified-this-and-that" will be able to answere them but not necessarily able to work in a team in a shared environment. By the way: if the candidate only knows about java, who cares anyway...

Posted by Sven Bange on June 27, 2006 at 01:04 AM CDT #

Gone are the days when graduates only knew about the languages taught in the classrooms. They guys are now exposed to whole world of frameworks and design patterns.

I feel, if someone can clear elimentry questions he/she would be an okay programmer but may not develop into an skilled developer.

We try to see the problem solving skills and learning ability.

Posted by Shilpa on June 27, 2006 at 09:12 AM CDT #

I like concrete questions (puzzles and even
trivia, if the acceptable grown-up answer
is "I'd look it up" and is not met with "ha-ha-
you-don't-know-the-length-of-Ritchie's-beard"). Open-ended ones ("How would you go about
designing X") are still concrete. Provided
that you cut the interviewee some slack for
being nervous under pressure of an interview,
these certainly beat HR-type questions of
"How do you interact with a team?" (I am
not saying the answer to that is meaningless
at all; but the posing of the question is :).

Posted by DEBEDb on June 27, 2006 at 09:27 AM CDT #

Yes, ask them to code. But no, don't ask them to code at a whiteboard. Sit with them at an IDE and see whether they know the tools of the job and how quickly they can get up to speed with an existing codebase. Any coding exercise that can be done on a whiteboard is too trivial to tell you anything about their real programming ability.

Posted by 155.140.122.227 on June 27, 2006 at 02:44 PM CDT #

As an effective programmer, you should have working experience on business workflow of many different information systems. The more extensive experience you have, the more correctly you compile/elicit your customer's requirement. Then you are ready to build a quality software.

Detailed technical skills can be improved via work/project and using code review tools such as PMD, FindBugs...

In case you dont know what underlying mechanism sit under reserving a string, dont worry, open a textbook and you can find it easily or search an API that serve it. But you dont know how that information system work and how to read and implement that sequence diagram, forget it, you are fired.

As you may know, I may not know about how my internal body work, I run well. With a little luck , I can be a good athlete ;)

@Shilpa: I feel, if someone can clear elimentry questions he/she would be an okay programmer but may not develop into an skilled developer.

I disagree. There is no connection between a skilled developer and those having very detailed basic knowledge on computer science. Ok, you may know the low level knowlegde on bit and byte manipulation, so what is the next? Are you ensure that you can produce good code when develop a user management system with Servlet 2.4? No clue.

Posted by pcdinh on June 27, 2006 at 04:24 PM CDT #

"Would you hire a knife-throwing juggler without seeing them juggle?"

Sure, but not without seeing them throw a knife.

Posted by Dave Newton on June 27, 2006 at 08:34 PM CDT #

@pcdinh I believe your athlete example is flawed. To be a professional athlete you do need knowledge of how your body works in order to make it work to its fullest. Without the knowledge you can still be a good athlete, but will anyone pay you?

Also, knowing about how a Servlet works is just an extension on the building blocks of bits and bytes. Thus with a good solid foundation, anything can be built. The opposite arguement fails though, just because someone is an expert in say Struts, does not mean that they can produce good JDBC code.

@Dave I thought saying "Knife juggling juggler" would be redundant ;-)

The reason we don't have them work with the IDE is this...which IDE? Maybe they don't know Eclipse? Does this mean we should not hire them? The whiteboard becomes the least common denominator.

Posted by Aaron Korver on June 28, 2006 at 09:56 AM CDT #

Post a Comment:
Comments are closed for this entry.