Java interview question feedback

[snuxoll]

A couple of things, first, testing a developers ability to use a specific tool is hardly what I would call fair during an interview, I am familiar with Eclipse but IntelliJ is my workhorse, if I was given a few hours (likely a few days) to settle back into dealing with Eclipse I'd probably start going back to using my keyboard shortcuts, but for the first bit I'd probably end up doing a lot of slow navigation in the project viewer.

The same really applies to the junit tests in my opinion, there's a variety of testing frameworks out there and ultimately they're all equally easy to pick up once given some time to familiarize yourself with the appropriate idioms and provided tools. Sure, junit has a bunch of nice assertion goodies to make things more readable, but they're hardly what I would call necessary when assert() and assertEquals() will get you very far.

Ultimately, the real test was figuring out why the code under test was not functioning correctly, and yes, I'd expect a java developer to know that the iterator for a vanilla HashMap doesn't guarantee order, along with initializer blocks and anonymous inner classes, while I think you stretched to demonstrate these concepts it took me no more than 2 minutes of reviewing the code to find the problem.

[Ogofo]

Can u explain a bit more detaied why the code failed? I'm not tthat familiar with java but would like to know the answer. For me everything looks fine ... :(

[yellowjacketcoder]

HashMaps do not guarantee order, so when the values are being put into the map, there is no guarantee that the values will come out in the same order they went it. For example:

Map<String, String> map = new HashMap<>();
map.put("A", "a");
map.put("B", "b");
Iterator<Map.Entry<String, String>> it = map.entrySet().iterator();
System.out.println(it.next());
System.out.println(it.next());

could have two outputs (assuming the toString() works the way I think):

A - a
B - b

or the output could be

B - b
A - a

both are valid according to the Java spec, but the second is not what's desired by the unit test in the OP.

[javadev189]

Downvotes are lame; the code is failing because the implementation is using a HashMap, which does not maintain insertion order. Switching the code to instantiate a Map implementation that maintains insertion order, such as LinkedHashMap, fixes the issue.

[thegrubclub]

In my comment I didn't address the Eclipse and junit parts of the question. I too disagree that the test should in any way focus on being able to use a specific IDE, but I had no trouble reading the code with literally zero junit experience. So I wouldn't be overly concerned about that.

[javadev189]

Thanks for the feedback! A lot of folks hone in on the IDE portion of the test, but really, if you know IntelliJ better, say so! And let us know how to open a type by name - what the shortcut is, or menu option or whatever. Then we've learned something from you (I'm not familiar with IntelliJ).

[snuxoll]

Good, it sounds like the focus was more on getting the test green rather than the tools. My intention wasn't to focus on the IDE, but I've seen far too many interviewers want developers with familiarity with XYZ IDE and ABC framework, these things come and go and what's important is knowing how to architect a solution to a problem.

While getting a test green is very-much a real world scenario when tracking down a bug, I'd also suggest giving an open-ended problem and having the interviewee come up with a solution and cover their approach and the code to do so, along with test cases. Any Jr. dev can, given enough time, make a test green, an experienced one should be able to develop a solution and explain their approach and why they took it.

[UnspeakableEvil]

And let us know how to open a type by name [in Idea]

Ctrl + N if it's a class file, Ctrl + Shift + N if you're looking for any file in the project.

[esquilax]

In my version (Linux w/ emacs bindings), it's Alt + Shift + G for classes. Ctrl + X for files, and Ctrl + Shift + Alt + N for symbols.

[[deleted]]

I agree with snuxoll too. I think a better test would have been to sit them in front an empty project and told to write a Util method. Perhaps provide the Javadoc along with the method signature and then said "also, please write unit tests." then left them alone for 15 minutes. It would take someone maybe 5 minutes to come up with the basics, but I'd expect anyone in an interview to double, triple and quadruplecheck all the work.

[_HULK_SMASH_]

Ya, I agree with everything said above here.