What are some good interview questions for Java developers?

[RaiderJ]

I've done some Java development over the years, but now I'm working more in software architecture and design. What are some good interview questions for Java developers with 2-5 years experience?

Very old thread.

 

[Ken g6]

Interview questions thread.

In my first technical interview, I got asked something about reflection, which I had never used - and still haven't used in Java (just C#).

 

[RaiderJ]

Oh cool, didn't even see the questions thread, thanks!

 

[degibson]

Java-specific:
* What is a VM?
* Why is Java portable?
* How does garbage collection work?
* For what applications is Java well-suited? Unsuited?

 

[heymrdj]

What is Java .

 

[presidentender]

I'd ask more general questions, rather than in-depth language stuff. Ask about recursion, not because it's important, but because it weeds out less intelligent people. Don't have them write code on a whiteboard; give them take-home assignments.

Then again, at this point in my career, I'm spending quite a bit more time on the "interviewee" side of the table.

 

[LightningRider]

When I went to do my stage at the company where I am now employed permanently, they asked pretty basic stuff like what does the "static" keyword do, what's the point of constructors, and what code would you put in a catch block. Of course that was just for a stage... Depends on which company you're going to for the interview I suppose.

 

[degibson]

With interviews, you want to start by limiting the chance you hire a total moron. Ask them how to do file I/O, or how exceptions are handled by a try/catch duet... something crazy simple-- maybe how to iterate over a fixed-length array. Ratchet the difficulty up until the programmer can't answer your question... the hire the one that impresses you most.

 

[ahurtt]

I don't have any questions off the top of my head but I can offer this general advice. As an interviewee, you want to limit the chance you accept a job working for a total moron. Therefore, as an interviewer, you should be prepared to receive open-ended answers if you ask open-ended questions. Don't ask any questions to which you might not understand the answer. That is a sure way to have a very bright and talented potential new hire leave the interview feeling like they should have been on the other side of the table and NOT wanting to work for your company. I have been in a number of technical interviews where it was very plainly obvious to me that the interviewer was in way over his head. Needless to say I did not accept offers extended by those employers. When giving technical interviews, if there is a specific answer you are looking for to a certain question, then be sure to phrase the question in such a way as to be unambiguous. There are many many ways to skin a cat as the old adage goes. If you want it skinned in a specific way, then be specific. If you are curious about how many ways the skinner knows to skin the cat, be sure you are qualified to interpret the answer he may give and know many possible answers yourself. Otherwise you won't know if the interview candidate is blowing smoke up your bum or is simply more well versed in his profession than you are. Either way you risk looking incompetent and not making a favorable impression of the company on the interviewee. Above all as an interviewer, just be honest with yourself and before you ask a question of a potential new hire, ask yourself, "Am I qualified to interpret any answer the candidate might give to this question and is there any specific right or wrong answer I am looking for?"

 

[troytime]

ask them about their programming for fun projects.
the best programmers are the ones that love to program...they'll have side projects that they work on as a hobby.

 

[mundane]

It also depends on the technology you're applying this candidate to - you may want to include some Enterprise questions, db integration, tools familiarity (Ant, etc). See what they know about object serialization, RMI, their way around an IDE -or- command line utilities, some Collection efficiency questions, interacting with Swing, synchronization/parallel processing.

 

[johanelmander45]

Hi

This topic help me a lot in developing my project. I will contribute more when I finished it.

If you want to get more materials that related to this topic, you can visit: Typicalinterviewquestions.info/

Best regards.

 

[Cogman]

... Crap, necrothread

 

[degibson]

... Crap, necrothread

(800) 454-8000

 

[Markbnj]

I'll help...

1) Why are checked exceptions stupid?

 

[tatteredpotato]

I'll help...

1) Why are checked exceptions stupid?

I've never actually thought about this before, but I see the point. I learned C# first and Java second, and the exception checker in Java always annoys me and causes me to write code just to surpress the compiler errors.

 

[Markbnj]

I've never actually thought about this before, but I see the point. I learned C# first and Java second, and the exception checker in Java always annoys me and causes me to write code just to surpress the compiler errors.

It's an old debate, and mine hardly qualifies as expert opinion, but they drive me nuts. Not just the fact that you have to write code to tell the compiler you're aware that a particular method throws a particular exception - that's bad enough - but also that there are other exceptions which aren't checked. Blecch.

 

[Ken g6]

The thing I hate about forcibly checked exceptions is that they make some programmers do this:

try {
    [code that may throw exceptions]
} catch(Exception e) {}

Sure, that handles the compiler errors. It also hides all exceptions thrown in that code. So things can go wrong and you'll never know about it!

I've been working with a Java framework lately, and my current favored solution is:

try {
    [code that may throw exceptions]
} catch(Exception e) {
    throw new RuntimeException(e);
}

(Or some narrower variant.) This effectively voids the required checking of all exceptions, but doesn't hide them. (The framework catches them later.)

 

[Markbnj]

I think most of the Java programmers I know do that exact same thing Ken.

 

[PhatoseAlpha]

Is this something you only do when a finally block is also needed? My java is definitely rusty, but I'm having trouble thinking of any other reason you'd do that.

 

[Leros]

I think most of the Java programmers I know do that exact same thing Ken.

Eclipse makes it too easy to just surround your code with a try catch block.

 

[beginner99]

It's an old debate, and mine hardly qualifies as expert opinion, but they drive me nuts. Not just the fact that you have to write code to tell the compiler you're aware that a particular method throws a particular exception - that's bad enough - but also that there are other exceptions which aren't checked. Blecch.

As far as I understand it it's pretty simple. Unchecked Exceptions mean some kind of fatal error (which could be prevented by "correct" programming) from which the application can't recover and must be terminated. Hence there is no need to catch them or declare to throw them because you can't recover anyway like OutOfMemoryError.

A checked exception is an exception from which you can recover and which you have no influence on while programming. Like IOException when out of disk space. The need for having to catch or declaring to throw them is that a user of your API knows what he will have to deal with. A User can't know you are accessing files on hdd.

try {
    [code that may throw exceptions]
} catch(Exception e) {
    throw new RuntimeException(e);
}

I would say this is bad practice too. It's probably manageable if you are the only developer and it's nothing very big/complex. But how do you control that all these runtime exceptions are actually caught? How do you recover from them?

if (e instanceof IOException)
...
else if (e instanceof NullPointerException)
...

 

[Monster_Munch]

With interviews, you want to start by limiting the chance you hire a total moron. Ask them how to do file I/O, or how exceptions are handled by a try/catch duet... something crazy simple-- maybe how to iterate over a fixed-length array. Ratchet the difficulty up until the programmer can't answer your question... the hire the one that impresses you most.

I've been working as a java developer for the last 4 years and I wouldn't be able to tell you much about file I/O off the top of my head. I work on enterprisey database applications which hardly ever have to work with a file system.

 

[degibson]

I've been working as a java developer for the last 4 years and I wouldn't be able to tell you much about file I/O off the top of my head. I work on enterprisey database applications which hardly ever have to work with a file system.

The point was to catch people who couldn't code at all. And, as I recall, Java's file I/O is pretty terrible, so I'd be tempted to go with iteration first and work upward from there. All the same, pseudocode would work as well, even if you can't remember all the BufferedReader garbage off the top of your head.

 

[Markbnj]

As far as I understand it it's pretty simple. Unchecked Exceptions mean some kind of fatal error (which could be prevented by "correct" programming) from which the application can't recover and must be terminated. Hence there is no need to catch them or declare to throw them because you can't recover anyway like OutOfMemoryError.

A checked exception is an exception from which you can recover and which you have no influence on while programming. Like IOException when out of disk space. The need for having to catch or declaring to throw them is that a user of your API knows what he will have to deal with. A User can't know you are accessing files on hdd.

try {
    [code that may throw exceptions]
} catch(Exception e) {
    throw new RuntimeException(e);
}

I would say this is bad practice too. It's probably manageable if you are the only developer and it's nothing very big/complex. But how do you control that all these runtime exceptions are actually caught? How do you recover from them?

if (e instanceof IOException)
...
else if (e instanceof NullPointerException)
...

I understand the rationale. I just don't agree with the implementation. There are times, for example, when I may want to catch an exception one level up from the actual caller of the method that threw it. It shouldn't be a compiler error not to handle an exception. A warning, sure, but it shouldn't prevent building and running.

I guess as mod I shouldn't be facilitating this threadjack, should I?