Does anybody have any good java developer interview questions? I've got a couple people coming in for interviews beginning this afternoon and I have a basic set of "prove you have some clue" type questions that I have put together, but I'm still trying to flesh it out. The position is a mid-level (2-5 years relevant experience) java web developer. I'm looking for someone who has a solid understanding of j2ee development, but not so much knowledge that they will immediately outgrow the position. Any suggestions on lines of questioning are appreciated.

-Mike

Here are some miscellaneous interview questions we used to use:

What is the software development lifecycle?

Can you some characteristics that distinguish an object-oriented language from a procedural one?

What is polymorphism? Can you cite an example?

What is the main concept of patterns?

Are you familiar with the Design Patterns book from the 'Gang of Four'? If so, what is your most common pattern and how does it work?

What is your approach to testing?

Why isn't there a destructor in Java?

What's the difference between process and thread?

Do you know what a race condition is? How do you guard against it?

What is an exception, and what are some best practices for exception handling in Java?

What is JDBC? Where is it used?

What is an inner class and when should you use one?

What do you most like about development in Java?

Do you have any complaints about Java? (I really like this question personally -- if they have nothing, they don't have much experience, and if they have some, usually what they pick is very revealing)

What do you do to keep you skills up to date?

What periodicals or websites do you read to help keep your skills up to date?

Do you do any programming outside of work, and if so, what?

Do you enjoy working in a group? Do you feel comfortable working on your own?


We also had a small program that we would have applicants write. It was basically a small word game, and it was always one of the more interesting things we got from people because it really revealed how they approached a problem and what type of object-oriented techniques they used (if any -- yikes -- we saw some CRAP).

Since this is a web development position i would probably add something like the following:

What are some best practices for JSP/Servlet development?

When would you make a JSP versus a Servlet?

What app servers have you had experience working with?

When would you put data in the context vs the session vs the request vs the page? What are some pro's and con's of each?

Is there anything you would choose to never put in a JSP? (basically hunting to make sure they're not going to write huge blocks of code inside of a JSP)

Have you ever used taglibs? What did you use them for?

Do you have any complaints with JSP/Servlets? (same deal as the previous one)

When is it appropriate to use EJB's in a project? What factors would affect your decision to use them or not? Are there any cases when you feel like you should always use them or never user them?

Awesome, thanks Mike. There are some good ones in there I hadn't thought of.

Just watch you don't get hung up on knowledge versus .. whatever you want to call it.. ability, or talent, or smarts etc..

Yeah I definitely agree ... This is the big list we used, of which we would just pick some to guage EXPERIENCE with Java. We would use the sample program to assess ability, and some of the personal questions to try to assess drive (which I would rank almost more important than experience). I'd rather have a guy who doesn't know much who is bright and works his butt off than someone who really knows Java but works their day and goes home. That's why I like the question about what kind of programming they do at home -- I feel like anyone who really loves to program doesn't just program at work. I always liked to find people who worked on open source projects, or had personal projects they liked to work on. Granted, I'd rather have some with drive AND experience, but that often costs $$$.

I would expect my staff to *want* to work extra hours, at least from time to time. This is indicative that they are enjoying their work, the project is cool, the environment is good and that they share the responsibility to deliver the goals. When the office is deserted on the dot of leaving time there's a good chance that some or all of those things are absent (unless we all went to the pub of course).

When it comes to motivating people to be really into their work, the last thing to do is to *tell* them to work the extra hours. If someone doesn't want to be in the office they are unlikely to deliver their best work. The aim is to make being at work better than being at home, at least some of the time!

Rob

I agree w/ Rob and Peter. I will point out though, that at the company where I was using these interview questions, we were a small company with an even smaller development staff. I tried to be up-front with the people that we hired that it was very likely that they would be working more than 9-5 and that they needed to be OK with that working here. We were very flexible about the particular hours that were worked, but the deadlines were often not controllable by the development team (ugh), and thus created less-than-desirable time requirements. I like to think we had a really good environment with interesting work (and adequate compensation if you count the thousands of now worthless stock options ), but I didn't want to mislead people about the expectations. In my old and wise age now , I'm in a bigger company where it's almost always 9-5, but even here there are days when I have to stay long (software has a way of doing that as the deadline looms near).

I think the size of the company is irrelevant. If you're working 12 hour days to get the job done then something went wrong in the planning stage. You may think doing all this work will pay off in the end, but unless you're the boss I doubt you'll see anything. Sorry if this sound cynical, but BBC Technology have suceeded in turn an ethusiastic hard working graduate broadcast engineer into a down trodden, embittered, frustrated, under paid computer programmer. I've seen far too many people work themselves to the point of nervous exhaustion and be left with nothing.

I don't think that's necessarily true. In a small company, you often don't have the money to hire all the employees necessary to run a project like you would in a company with appropriate funding. In exchange for giving up your free time for such an arrangement, you should expect appropriate compensation (stock options, stock grants, deferred bonuses, etc). But to a large extent, it's a gamble and the potential employee has to evaluate the entire situation for him/herself to determine if it's worth the risk. Now that's not to say that there aren't plenty of small companies that aren't also terribly run, but I don't think you can say it's a planning failure in the general case.

Sorry to get in late on this, but what I've found through interviewing and hiring programmers is that there is a HUGE difference between knowledge and ability. Knowledge helps, but being able to assess ability is key. I realize this was already brought up earlier, but just to throw my opinion in the hat I think the most important skill is creativity (or intuition). What I mean by creativity/intuition is the ability to take a set of tools and produce something new that solves some problem or another. To me that is the very essence of programming, the rest is just syntax. Without this skill programmers tend to cost more than they're worth. And the truly unfortunate thing is that creativitily/intuition is not something that I think can be learned.

On the other side I have worked with one very productive non-creative programmer before, but he had more tenacity than anyone else I've ever met. He listened to input and then worked his tail off until he was successful. He used to say "I make up for my lack of talent with brute force", and he was right. I gave him coding guidelines and he followed them explicitly, producing very usable and readable code. However, this has been the exception rather than the rule.

Of course, there are other key pieces beyond creativity and intuition. A programmer must be disciplined and work well with others, which is often contrary to the very thing that makes a person creative in the first place. But that's why hiring is such a difficult taks, and also why I've seen far more poor placements than I have productive ones.

Oh, and to weigh in on the "overtime" issue, every organization is different and matching a developer to the enviornment is key. But to take the stance that a programmer who doesn't want to work overtime is "not committed" is wrong (I don't think anyone here is making that argument, but I've heard it before). There ARE times people have to go above and beyond normal expectations for whatever reasons, but this should be identified and rewarded by management, not cast off as "excpeted". If the cultre of the company is 40 hour a week and a developer ends up working 60 for a little while, the developer should be rewareded and thanked for the extra contribution, and the process should also be examined to determine what the cause of the extra time is. If it's part of the culture, then that's just what it is. If it's marketing pushing unrealisitc deadlines you should drop them off a cliff (just kidding!), if it's management not managing the programmers correctly, they should be reprimanded.

I work 40 ours a week and am very productive. I'll put in overtime if necessary, but I'll also hold others accountable if this happens (unless it's my fault, in which case I'll hold myself acountable). Fortunatly I'm in a position to do this, whereas many programmers aren't.