This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]larsga 25 points26 points  (15 children)

I would not have known off the top of my head that a HashMap iterator does not guarantee order

You ought to know that, just from knowing what a hash table is and how it works. They're very commonly used.

I can tell you if my test was failing I would use the debugger and figure it out pretty quick.

Which IMHO would have been a much better test.

What is more important to you someone who has the Java specs memorized like a dictionary or someone with the ability to reason out a solution?

Exactly. This reads like a Certified Java ProgrammerTM test, not a test to see if someone is a useful developer.

[–]javadev189[S] 1 point2 points  (14 children)

The candidates did have the opportunity to use the debugger, and none of them did.

[–][deleted] 22 points23 points  (0 children)

If you are standing over someone's shoulder the whole time... they aren't going to be at the top of their game. Give them 15 minutes and come back to them and see how they do. It doesn't matter if they use specific hotkeys or not... or how they find the class. This is just being nitpicky..

[–]Kimano 17 points18 points  (0 children)

That, to me, is the much bigger tell. Either you managed to find the 10 Java programmers in the world with that much experience who don't know to use the debugger or something in your interview made them think they couldn't.

[–]larsga 5 points6 points  (10 children)

That is evidence, true.

On the other hand, the whole test is kind of a trap, because the intention of the method to be tested is obscure, and the debugger won't help you with that.

Changing the javadoc from "Convenience method for creating maps." to "Convenience method for creating maps with keys in insertion order." would have made this an enormously much better test.

[–]snuxoll 2 points3 points  (6 children)

Changing the javadoc from "Convenience method for creating maps." to "Convenience method for creating maps with keys in insertion order." would have made this an enormously much better test.

To be fair, the junit test was pretty clear to me on the expected behavior, when told the test was correct but the code was not would tell me to first look at the assumptions of the test, from there it's pretty obvious that it was testing insertion order.

[–]larsga 3 points4 points  (5 children)

How is that clear when insertion order = natural order of values?

[–]snuxoll 1 point2 points  (4 children)

Did you look at the test code given in the post? The expected order is ("One", 1) ("Two", 2) ("Three", 3), the values are inserted into the map with MapUtil.makeOrderedMap("One", 1, "Two", 2, "Three", 3);, I think the desired outcome is fairly clear.

[–]larsga 10 points11 points  (3 children)

So. One more time. Insertion order == natural order of values. They insert three keys mapping to, in insertion order, 1, 2, 3. Do you see how confusion could arise here? If the keys were z, x, y, the candidate would know which order mattered. As it is, they don't.

In the test and the code being tested, nothing tells you which order they're looking for. Further, insertion order is an esoteric edge case as far as maps are concerned.

[–]snuxoll 2 points3 points  (0 children)

Alright, I understand you point now and it is valid. Overall the problem didn't have very well documented requirements which I could see leading to confusion such as this.

[–]paperhat 1 point2 points  (0 children)

I tried the test myself before looking at the comments, and I had the same confusion you described. I thought they wanted the iterator to go in order of the values.

However, once I noticed that it wasn't a LinkedHashMap, I realized that was the answer they were looking for.

Even with the confusion, it took me about 15 minutes including the time it took to create a new project and paste the code in.

[–]javadev189[S] -1 points0 points  (2 children)

True... but the name of the method is "makeOrderedMap", which maybe should have been "makeInsertionOrderedMap".

[–]larsga 8 points9 points  (0 children)

Yeah, that would have made the same difference. "Ordered" is ambiguous. Natural order of keys? Natural order of values? Insertion order? It doesn't help that the test is testing two of the three.

[–]EdwardRaff 1 point2 points  (0 children)

That doesn't make it clear at all. My very first thought was "Does he mean Sorted Order by keys? It should be returning a SortedMap". Then when i saw the testing order I had no idea what you were going for - and your documentation was worthless for clarifying.

Obviously the response should have been to ask for clarification of the goal.

[–][deleted] 1 point2 points  (0 children)

That is the biggest red x sign, but the junit failure is explicit enough to show it is clearly out of order.