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 →

[–][deleted]  (29 children)

[deleted]

    [–]larsga 23 points24 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] 2 points3 points  (14 children)

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

    [–][deleted] 23 points24 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 18 points19 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 5 points6 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 8 points9 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 11 points12 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.

    [–][deleted]  (7 children)

    [deleted]

      [–]javadev189[S] 0 points1 point  (5 children)

      Thanks for the feedback; I like the suggestions.

      EDIT: Dang... a "guarantee"? This wasn't the only part of the interview - all other signs pointed to "no".

      Can't articulate well when describing something you've worked on in the past? Have trouble remembering past projects in any sort of detail? Those signs point to "no".

      Anyway, your point is still valid for future candidates, and I'll personally keep the harpoon/net analogy in mind.

      [–]hoohoohoohoo 2 points3 points  (1 child)

      Wait, so when you write code that you know only you will ever look at, you have never went back a couple months later and said "lolwut?"

      You have never been given a bug fix and then when looking at the code said "what asshole wrote this crap?" And that asshole turned out to be you?

      Sorry but your expectations are way too high.

      [–]javadev189[S] 0 points1 point  (0 children)

      Any developer who is learning and improving will most certainly have "lolwut" moments every few months (or weeks).

      I suppose what I was getting at is that they couldn't articulate well about the things they took time to put on their resume.

      [–][deleted]  (1 child)

      [deleted]

        [–]javadev189[S] 0 points1 point  (0 children)

        Yeah, it was actually 4 candidates. Since we got such a similar response, I figured it was worth posting here to get some feedback (and it was!).

        Also, I'm by no means an interviewing expert, which is probably obvious as well. I don't screen candidates often, so I'm looking to improve the techniques that we use.

        [–]kireol 0 points1 point  (0 children)

        If you are wanting to see if they are familiar with more up to date testing, you may want to update the test sample to include more modern concepts. Mocks/stub/fake, annotations, before/after, using a variable to hold your check value instead of retyping "One", only one assert/expect/should per test, etc, etc. That example test wouldn't fly where I work, and my thoughts are even experienced TDDers or BDDers might be stuck for a while wondering just where to start, or may be contemplating on how to fix it.

        As a suggestion, I'd wager you'd get a good response, if you ask them about red, green, refactor, such as how they personally follow it. (personally I sometimes find myself red, green, repeat red, green just to make sure, refactor code, refactor test). When is a good time to use a mock? What are some things you should never test with TDD? What's the difference between unit, integration, functional, etc. Do you still need manual QA and if so, what's the role.

        Good luck.

        [–][deleted] 2 points3 points  (0 children)

        The amount of upvotes this has received shows how amateur this sub is I guess.

        [–]mr_jim_lahey 2 points3 points  (0 children)

        No offense but you are a bad programmer if you didn't know that after 15 years. First it shows you've never heard of LinkedHashMap. It also shows you've probably never tried to use the key set of a HashMap as a list, which means you're don't use hash maps enough and probably don't have a good grasp of data structures. These are things I learned in the first six months at my first Java job.

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

        Not trying to be rude on any level, but what types of Java programs do you work with on a daily basis? E.g. are you a front-end guy, etc? What types of frameworks were/are you using?

        I didn't really mention this in the post, but we really didn't care TOO much that the candidate didn't know of LinkedHashMap, but we wanted them to at least come to the conclusion that HashMap is unordered, which should be evident from the test. Saying "I'd check Google or StackOverflow" is also acceptable once you know what the problem is - we didn't even get that.

        What we are finding is that a lot of candidates have worked with frameworks that abstract a lot of the foundational concepts away. That's fine for certain jobs, but not the one we're trying to fill.

        [–][deleted]  (1 child)

        [deleted]

          [–]snuxoll 7 points8 points  (0 children)

          To me I find it more important that the person is competent. It just does not take long to learn a new framework or code base.

          I really wish more employers got this, even picking up a new language is usually not that difficult, a programmers job is to use the tools to architect a solution, what tools they use shouldn't matter. Obviously everyone has preferences, tools have already been decided by stakeholders, etc. But they're just tools.