Does anyone have a good interview question to ask prospective junior java developers? They will have a two year minimum experience requirement. The questions will be on a written test and they will have five to ten minutes to answer each question.
Limit to one interview question per response for voting purposes please.
Here is a common question that has worked well for me in the past (with answer of course).
Develop a pseudocode program that prints the numbers from 1 to 100. But for multiples of three print "Ping" instead of the number and for the multiples of five print "Pong". For numbers which are multiples of both three and five print "Ping Pong".
public class Pingpong{
public static void main(String args[]){
for (int i = 1; i<=100; i++){
if(i%3 == 0 && i%5 == 0){
System.out.println("Ping Pong");
}else if(i%3 == 0 ){
System.out.println("Ping");
}else if (i%5 == 0){
System.out.println("Pong");
}else{
System.out.println(i);
}
}
}
}
Have them write code!
Fizzbuzz is a good quick test... http://www.geekschool.org/programming/fizzbuzz/
There are some great questions here - http://www.freejavaguide.com/java-interview-questions.html
I'd also prepare a logic test with brain teasers. Google and Microsoft do this. I need to know if my programmers and going to be nimble and quick when faced with a server crash, so I think brain teasers test for agility under pressure.
Ask them to do OOAD of a given system description in 10 minutes. Observe how they tackle the problem.
You attempt to run a bunch of compiled Java code that someone else gave you, and you see the following near the start of a stack trace:
NoClassDefFoundError: org.apache.commons.lang.StringUtils.
What went wrong? How can you fix it?
Ask what is the difference between an ArrayList and a Vector, a HashMap and a HashSet.
Explain what it means to write "state-less" code? How does this relate to a multi-threaded application? Give examples of how you'd write a state-less component.
@Mike I use a logic question that I was asked during an interview while I was in college. I like this question because even though I don't think it's too hard, it is a binary question (with a small twist) and I ask the interviewee to think out loud. If they freeze up or simply say that it can't be solved in a short amount of time then I worry about their ability to solve problems under pressure.
You have 12 cubes that all appear to be identical; however one cube is slightly heaver than the other 11 (you can’t tell the difference by holding them). Also, you have a balance scale; unfortunately you can only use the scale three times. Can you tell me how you would find the heaver cube?
What version(s) of java have you been using in the projects (you have 2 years experience after all)?
I must've interviewed a hundred or more developers and my advice is to start with practical coding questions. Even simple code tests will save you a lot of time. Most of the people I have interviewed could answer theory questions quite well, but only a small fraction are what I would call good coders.
For example, I generally start with the following question:
"Given an array of ints, write some code that creates an another array of the same size and copies the elements to the new array but in the reverse order."
I imagine that most readers would consider this question ridiculously easy, but I found that nearly three quarters of interviewees struggled with this test.
If they got past that question, I would ask them to repeat the task, but this time they should reverse the elements in place. The answer should be something like:
for (int i=0; i < (data.length / 2); i++)
data[i] = data[data.length - 1 - i];
The first time through nearly everyone misses that you should only go half way through the array. Watching them fix that bug gives you a good inkling as to how they solve problems and how sharp they are.
Next I would usually get them to sort the array using bubblesort, but by this stage I usually have a reasonably good sense of whether they are worth hiring.
Total interview time using this method: 10-15 mins. Continue with theory or tool questions afterwards if you like, but I cannot recommend enough starting with the practical coding portion of the interview.
Write some Java code with obvious errors. Inside the code you place innocently a '==' comparison of objects instead the correct '.equals()'. (Be sure that the compared objects in memory are different and the code fails, else the candidate may claim optimization).
If you haven't programmed in Java a while (especially if you come from C/C++ !) you simply don't see the error ! It is a warning sign if someone claims long experience and can't detect this error because it is a real pain in the ass when you learn Java.
Compare and contrast (don't you love that phrase?) the modifiers public, private, protected and default.
Compare an interface to an abstract class and give an example of when you might use one of each.
What does the modifier final mean to a class and a variable?
What is overloading and why might you use it?
What is garbage collection and how does it work in java?
How do you make a Thread in java?
Write a generic main method and explain what each item in the method signature means.
Explain how try/catch/throw/finally work.
What is an Iterator and how do you use it?
What are generics?
Are these lines of code valid and describe why or why not:
List<Object> myList = new ArrayList<String>(); \\(hint: no)
Map<Integer> myMap = new HashMap<int>(); \\ (hint: also no)
One of many questions I like to ask junior Java programmers in order to get a feel for how well they know the general Java language concepts is:
Explain when you would use each of the following: final, finally and finalize.
I believe that more important than pure technical knowledge is the ability to communicate complex technical issues to someone who doesn't have a technical background. It's much, much easier to teach specific programming skills to someone who communicates very well than to teach communication to a pure techie.
To that end, my favorite question is: "Pretend that I am your grandmother (or other non-technical person). Explain to me what it means for a program to be object oriented."
Remember--this is all about communication. Ask your technical questions too, but teaching communication is much more difficult than teaching programming.
"Google and Microsoft do this" - you talk about companies as though they are people. Put the ego and beasting desires away. The only place teaser have is for people with no real experience of your business.
You're looking for someone to work with right? Unless the round manhole business is your business, ask people to describe their approach to digging into solving real problems (past and present).
One general source for such questions comes from Sun itself: The Sun Java Certifications.
Questions of those may be found in on-line trainings or tutorials. Feeling lucky(tm): http://www.javaprepare.com/notes/intro.html however there are still no Java 6 related questions.
The best (only?) way to get an idea of someones ability to program is to sit down with them and program with them. If you are too busy to do this, ask some of the developers the candidate will be working with to do it. Better still is to get them to pair with several different developers.
Ideally choose a problem that has a recursive element to it. That is usually a good test of a programmers aptitude, or rather, if they can't do recursion, they would fail the interview if I was testing them.
Let the candidate type, and work with them to solve the problem. Test driven development works well, especially if they haven't done it before, as it will take them out of their comfort zone.
You can learn a lot by how many shortcut keys they know in eclipse/ netbeans etc.
No single question is going to tell you yes or no. You might get a kick-arse c# or C++ developer who would fail 'simple' java questions, but is a far better programmer than the java candidates - java ain't that hard to pick up, good, intelligent programmers are...
Avoid you-know-it-or-you-don't questions about the Java API. These are worthless, IMO. My favourites are questions that ask for value judgements, because they allow good candidates to show their insight without necessarily having to have gained familiarity with particular parts of the API (which is what Javadoc is for, after all...)
My favoured technical question is to get the interviewee to implement the equals method for a simple class with a couple of fields, and in the case of a face-to-face interview to defend their implementation (which will pretty much always be non-optimal or missing something).
Other questions I'd consider at least sprinkling into the list would include things like: "What feature would you most like to see added to Java?", "How would you go about debugging a NullPointerException?", "In a twenty-lecture training course on Java, in which lecture should the concept of object orientation be introduced, and why?", "How does Java differ from other programming languages you've worked with?", and general language-agnostic questions like "Why are patterns a good thing?", "Should good code be self-documenting, or is it the responsibility of the developer to document it?", and the suchlike. Mostly I'm not looking for a right answer as such with a lot of these questions. I'm looking for an understanding of the question, a coherent chain of thought behind it, the ability of the interviewee to defend their viewpoint, and the ability to go beyond the simple multiple choice API questions that got them their JCP qualification that's no doubt taking pride of place on their CV.
They can learn the parameters to String#regionMatches later, or just let their IDE provide the list every time for all I care.
We interviewed someone claiming to have Java web development experience. I asked what the difference between servlets and jsp was, that left him completely stumped.
List some design patterns already in use in the Java API and for each of them :
- write a short sample code showing when or how to use it
- describe it's strength and weakness if any
- for any weakness, what would you change to make it better?
It's easy to enumerate design patterns, but to know where they are in code and how to use them are two separate things. After all, applying theory is the idea behind internships, and this will tell if the company will waste time and money if the latter is lacking. Also, the last point will show you what kind of judgement (constructive criticism, choice of recommendations, etc.) the candidate will make.
First question: In a Java 5 or Java 6 platform, assuming the code compiles, what can you say about this class declaration? Any comments, opinions or criticisms?
public class Foo implements Comparable
{
// constructors, methods and stuff go here.
public int compareTo(Foo foo){... does the comparison logic...}
public boolean equals(Foo foo){ ... does equality test logic...}
}
Second question: In Java, independently of the version, why would you implement/override the hashCode() method? What can you tell me of the relationship of equals() and hashCode()?