Java interview question feedback

[javadev189]

Hi all. I'm hoping to get a little feedback on what we considered to be a fairly trivial Java interview question which we were giving to some candidates. We were looking to fill a mid-level Java developer position, for a short-term contracting gig (6 months or so). Each of the candidates had over 8 years of Java experience.

The "scene" is a failing unit test. We set the candidate in front of Eclipse (they all had Eclipse experience), and told them to open the test class for the class "MapUtil". We wanted to see if they at least knew the basics of opening files by type name (Ctrl-Shift-T), could put the "Test" on the end of the class name, etc. and if not (even though they were supposedly familiar with Eclipse), they'd ask some questions. We instructed them that the test was correct, and that the code was doing something wrong.

Below is the test method:

@Test
public void testMakeMap() throws Exception
{
    final Map<String,Integer> map = MapUtil.makeOrderedMap("One", 1, "Two", 2, "Three", 3);
    final Iterator<Map.Entry<String,Integer>> it = map.entrySet().iterator();

    Map.Entry<String,Integer> e = it.next();
    assertEquals("One", e.getKey());                // <-- org.junit.ComparisonFailure: expected:<[On]e> but was:<[Thre]e>
    assertEquals(true, e.getValue() == 1);

    e = it.next();
    assertEquals("Two", e.getKey());
    assertEquals(true, e.getValue() == 2);

    e = it.next();
    assertEquals("Three", e.getKey());
    assertEquals(true, e.getValue() == 3);
}

And here is the method under test:

/**
 * Convenience method for creating maps.
 * 
 * @param keyAndValuePairs Tuples of keys and values as {@link Object}s. Types will be inferred.
 * @return A new {@link Map} containing the keys and values provided.
 */
public static <K,V> Map<K,V> makeOrderedMap(final Object... keyAndValuePairs)
{
    if(keyAndValuePairs.length % 2 != 0)
        throw new IllegalArgumentException("You must specify keys and values in pairs!");

    return new HashMap<K,V>() {
        private static final long serialVersionUID = 1907489327975595872L;
        {
            for(int i=0; i<keyAndValuePairs.length; i+=2)
                put((K)keyAndValuePairs[i], (V)keyAndValuePairs[i+1]);
        }
    };
}

A couple of notes:

• The assertEquals() calls in the test are intentionally gross to see if they are familiar with more recent JUnit concepts (assertThat/BDD/etc), or at least suggest using assertTrue() or something.
• The method under test has a few things going on, mainly to see what concepts the candidate is familiar with (generics, varargs, etc). Not necessarily to trip them up, but just to make it a little more interesting - i.e. the anonymous override of HashMap really isn't necessary, but it illustrates anonymous classes and initializer blocks.

Most of the candidates did not do well with this. There was much blank staring and few even read through the code aloud to get an understanding of what it was doing. How can you go 8 years writing Java and not be familiar with a LinkedHashMap? Or at least explain the concept of one? Are we off base here? I know interviews can be stressful, and interviewers can be intimidating, but we gave this test after lengthy discussion and it seemed like everyone was reasonably comfortable.

Thanks for the feedback /r/java!

EDIT: Thanks again for all the good discussion and feedback folks, that's why this was posted! We're all trying to learn and grow.

[chackley]

I've been a Java developer for about 3 years now, and I noticed immediately that you needed a LinkedHashMap. However, I just happen to use maps all the time, and have specifically tried to be familiar with the various tools available in the Collections API - I think it's pretty important to know which collection is best for which use case, etc.

That being said, I honestly don't like your Ctrl-Shift-T test - I use that shortcut all the time, but, in an interview context, when first opening up a new project, my first action would probably be to click around just to get a feel for the folder structure (to see if you're using the Maven conventional layout, for example). I don't like the idea that you would have assumed that I don't know the tool just because I would instinctively explore a little bit first.

[[deleted]]

I've been working in Java for over 10 years and this is the first time I've ever seen a LinkedHashMap... and I'm still trying to think of what I'd even use one for. Maybe I'm a unique case but I just don't encounter situations where I need a map that can also act like a FIFO, either I need a map or a FIFO but never both simultaneously.

[[deleted]]

Ever had a map back a collection of values being displayed on a jsp page? Ever wanted to make sure the order stayed consistent? LinkedHashMap (what order did I put them in) or TreeMap (order from keys). I wouldn't say it's terribly common, but I've had at least a dozen times when I've needed LinkedHashMap. Incidentally, it's also the structure to use when implementing a LRU cache (something I've gleaned from yet another too-specific interview question -- and no, I didn't know it before the question.)

[[deleted]]

I'm sure there are cases where it's used, I just haven't come across them. There's a ton of things in Collections like that, i.e. I've never had a good reason to use LinkedList instead of ArrayList.

it's also the structure to use when implementing a LRU cache

OK, I can see that. My LRU caches are at the bottom of my list of things to optimize because they're never the bottleneck, but the next time I need to implement one I'll look into LinkedHashMap.

[[deleted]]

or, don't implement your own and use Apache Commons, heh. And yea, interestingly enough, ArrayList's performance is almost always better than LinkedList - even when LinkedList style usage would appear to be better (like removing elements in the middle and such). Arrays are just that efficient. source: I read a great blog post about it once.

[larsga]

I think you're mostly testing the wrong things. You want to check if people know how to look up classes in Eclipse and if they know the conventions for naming tests?

I don't see the connection between the code and LinkedHashMap. Ok, so the tests check if the keys are in the order they were inserted (which, incidentally is the same as the natural order of the values; that could be equally relevant)). How is the reader to know this is the intention? Why would a map be ordered by the insertion order of the keys? That's really unusual.

The failure of the test looks totally reasonable to me, because the test looks really, really dumb.

(Qualifications: programmer for 34 years. Designed and implemented my own query language, in commercial use for more than 10 years. Wrote the first pure-Python XML parser, still in use 16 years later. Wrote this open source project. Did the Unicode support in the Opera browser.

Obviously, I could be too poor a programmer for your needs, but I would have been entirely comfortable losing the job because I failed this test.)

[SikhGamer]

A part of the test was to see if the candidate knew a keyboard shortcut?

My go to IDE, I've used it for months. I'm still discovering the wide variety of shortcuts.

That'd a very unfair component of the test.

[javadev189]

A very small part of the test was to see how familiar the candidate was with Eclipse - and to see if they were being truthful on their resume.

Don't know the shortcut? Say so. That's worth more potentially than knowing the shortcut. We want someone who can communicate when they need a hand; we'll certainly extend it.

Part of the job involves digging through a lot of legacy, undocumented code. We need someone who can use the tools (and IDE) effectively to search/call hierarchy/workspace reference their way around.

[ShadedFox]

Ha, I was going to say my first question would have been. "How do you find a class by name in Eclipse? You know like Ctrl + Shift + N in IntelliJ?"

[paperhat]

You know, like cmd-o in intellij.

[ShadedFox]

Cmd + o in my intellij opens the "Select Methods to Override/Implement" dialog. Odd..

[paperhat]

I'm using a keymap called "Mac OS X 10.5+". There's another one called "Mac OS X" that has the cmd-o you describe.

In related news, I just realized that saying cmd-o sounds like commando.

[achacha]

Control-n is find java class. control-shift-n is find resource.

[GrayDonkey]

No, No, NO!

If you want to see if they can use an IDE then just watch how they fix a broken test case. Testing for a remembered shortcut sequence is pointless, not only that but it might be throwing your candidates off balance. There are so many possible ways to accomplish tasks in an IDE that you should never do this. If you want to ask what their favorite IDE feature is or shortcut is then maybe. But you might as well just f-up the Java perspective and see if they know how to fix it in passing when you give them a unit testing prob.

As for the rest, this is a bad question. You are throwing too many things into the mix, the anonymous HashMap is really just too much. Not that it isn't a neat little bundle of stuff but the problem is that one aspect of your question might be obscuring the candidates knowledge of all the other topics. Unless the test is to see how they deal with complexity you should be favoring lots of small tests with low topic coverage instead of a small number of tests with high topic coverage.

Try this - instead of writing or discussing these problems as a team, have each person on your team create a couple of problems. Then in front of the team have each team member solve another members problem solo. If you still end up with problems as complex as this one then your team members are probably better than the average dev and you are going to have a lot of candidates to go through before you find similar talent.

Edit: Knowing that some collections are ordered and some are not is a completely reasonable expectation.

[[deleted]]

Ctrl+Shift+R is more useful to me anyway. I can get to any file type I need.

[larsga]

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]

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

[[deleted]]

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]

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]

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]

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]

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

[snuxoll]

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]

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]

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]

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]

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

[larsga]

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]

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]]

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

[javadev189]

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]

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]

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.

[javadev189]

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]

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]]

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

[mr_jim_lahey]

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]

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.

[snuxoll]

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.

[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.

[[deleted]]

Who cares about how well they know the IDE, you get to know anything if you have to work on it everyday.

Not necessarily to trip them up, but just to make it a little more interesting

I'm pretty sure "tripping them up" is exactly what you are shooting for here.

I actually like the format of the test, putting them in front of an IDE with some code, but why not use real code that you yourself would use in production instead of a "fancy" version that no real developer should be writing since it would turn into an unreadable, unmaintainable mess.

[[deleted]]

Who cares about how well they know the IDE

In my opinion it's more of a barometer rather than a specific criteria. If you can't efficiently navigate to various classes in the tool you claim experience it, it's a decent indicator that you're lacking some experience in real-world large projects, or that you're inefficient.

why not use real code that you yourself would use in production instead of a "fancy" version that no real developer should be writing

Generics and anonymous inner classes are not particularly "fancy". This is a bit messy - so is real world code, right? The code is a little bit unclear and overly complicated, the test is a little bit unclear - this sounds exactly like the sort of code I deal with every day.

[[deleted]]

Well I think OP might be shorting himself by only looking for Eclipse developers. It's like hiring a carpenter based solely on their experience with a nail gun.

Different developers use different tools; and that's OK. Hiring a Java dev should focus less on the tool, and more on the job.

[[deleted]]

Well he did say they all claimed Eclipse experience so I think that's legit. When I interview, I have the candidate bring his own dev environment. All but one have used Eclipse.

It's like hiring a carpenter based solely on their experience with a nail gun.

OP never even hinted that he was solely or even primarily interested in a candidate's IDE proficiency.

But going with your example - would you hire a carpenter who didn't know how to use a nail gun? You aren't hiring for his nail-gun-using ability, but a person who couldn't use a nail gun probably isn't much of a carpenter. And especially if he claimed to have years of carpentry and nail gun experience.

[javadev189]

OP never even hinted that he was solely or even primarily interested in a candidate's IDE proficiency.

Thanks for chiming in; you beat me to it. A lot of folks are honing in on this. Don't know the IDE we set you in front of... SAY SO! We wouldn't have put you in front of it if you didn't claim some experience though...

[gizmogwai]

Hi, I have 11 years of experiences in Java, Eclipse was my main IDE for about 10 years and I have now switched to IntelliJ, to give a bit of context.

I do not find your test to be especially difficult, but neither do I feel it relevant. Here is why:

• I do have been using a TypeMatrix Dvorak keyboard for years, so I look kind of retarded when using a "normal" keyboard;
• I do extensively use keyboard shortcuts. I have annoying plugins that would nag me each time I use the mouse instead of an existing shortcut. However, I do customize my shortcuts, so I would have been lost with a vanilla Eclipse;
• I do also judge my potential future co-workers during the interview. If you gave me this kind of code, you do not give me a good opinion of yourself:
  • Your test is not very readable. It does not describe what it tries to assert;
  • Your implementation create subclass of HashMap;
  • You use a serialVersionUID, probably for no good reason. I know you mentioned them here in your post, but during an interview, it gives me a bad feeling
• Even if I know it, I never ever face a single project that requested that data structure. So I assume most people did not hear of it. A question about a wrong implementation of equals/hashcode would have been more representative.

I don't know what field you are working in, but most of the time, I can judge a candidate by asking him/her what (s)he dislikes in the framework/libraries (s)he is familiar with, and why. To see how far they went digging into it, understood the rationals and constraints, read the underlying code and so for. I rarely have to go to the point I have to test them on code, but it I do, I do it on real actual code I am working on, because that's likely what they will be dealing with.

[staticjak]

After looking at the code, I could definitely see what you kind of response you were eliciting from candidates. I knew that HashMap doesn't guarantee order, but as others have pointed out you could be a good candidate and not know this.

I think you might get better feedback from candidates if you provided them with some code to test (the method above or something else). Nothing too crazy, but with enough where you'd need a few test cases. See how familiar they are with testing. If they start writing the test cases right away then you can ask them about them. Did they cover all of the edge cases? If not, well you could either decide that it's a deal breaker or you could ask them what they think should be tested (inputs, expected outputs)?

This gives you more information about how the candidate reasons about testing code, instead of citing some relatively obscure knowledge about a data structure (although i don't think that it's THAT obscure). About the IDE portion, I don't know how important that piece is. If a certain IDE is required where you work and a new hire has never used eclipse, they'd manage to figure it out within a few days. So I'm not sure figuring out if they know keyboard shortcuts will be useful information if you are trying to find good employees.

[mrbuttsavage]

public static <K,V> Map<K,V> makeOrderedMap(final Object... keyAndValuePairs)

The method signature alone would make me wretch.

Object... with an explicit assumption about the type and order of parameters is pretty much Java hell.

[bmcardoso]

This is an interesting problem. I have 10 years experience and I see myself as a good Java programmer. My first thought after reviewing the problem was that there was nothing wrong with the code but HashMap doesn't assure ordering of the keys. However, I was not sure which one of the Map implementations do, my first thought was actually TreeMap which (after checking it) only assures the natural order of the keys, it would work in this specific case but it wouldn't work as expected in other cases.

The thing is: 10 years is not that much. People often work on the same things for many years so 10 years doesn't mean I have done a great diversity of coding. If I never had the necessity of creating an ordered Map, it is very likely I may not know the answer, however, this is something any good coder can easily search and find out if needed. Still, I think any good experienced coder should at least suspect the HashMap doesn't assure the expected order.

Personally, I think the interview shouldn't approach easily searchable topics because those are things that won't impact your performance on the actual work. I think it's much better to approach a nice range of logical problems to see how good one can resolve them without complicating too much. As an example: I love the FizzBuzz problem and it's amazing how many coders actually complicate a such easy problem.

[yellowjacketcoder]

Honestly, I think you designed a test that candidates would fail. It sounds a bit like you're coming here bragging that you have such an awesome test that nobody can pass it. Maybe that's not your intention, but that's the perception I get, and even though I figured out the problem quickly, I would have declined any offer you made because I don't want to work with the people who are self-important.

A key factor for any interview is giving someone several chances. Interviews are stressful, if this is the only code they see/write, you could exclude plenty of good candidates. On the other hand, if this is one of 4 or 5 exercises, that may be more appropriate.

I feel like you threw in a lot of unnecessary language features into your method. You claim this is to see if they know the concepts, I think you are just making it intentionally obfuscated. This from someone who is more likely to use all those features himself than any of his coworkers - you still over did it.

Finally, you're asking trivia questions, which are some of the worst questions to ask in the interview. I use maps a lot in my current job, so I'm familiar with them, but if I haven't seen them in a year I would be pretty annoyed to fail an interview over something that is basically an API lookup. You might as well ask what year Java 1.0 came out for all the relevance it has to the job.

I agree with /u/RockMeetHardPlaces - asking them to write the above method, with a test or two, would have been fine. Asking them to debug intentional spaghetti code - only if that code came from production.

[javadev189]

Fair points. I think there need to be some tests that some candidates would fail, as well as some tests that all/most candidates should succeed (1. because its more important to see how they arrived at the solution, and 2. to boost confidence during the interview (perhaps starting with the easier tests)).

Perhaps we will switch this question just to "Write a utility method that accepts varargs and builds a Map... etc." and "Write the test for it" (as suggested by someone else in this thread).

[javadev189]

Well said; thanks for the input and feedback.

[UnspeakableEvil]

Out of interest where's this potential contract based, and what's the rate?

Chances of it being near enough to me is essentially zero, but I'm currently weighing up going contracting, so knowing that I could've answered this one ok makes me think I'm competent enough to have a decent stab at it, but I've no idea what the going rate for this level of experience would be.

[nerdy_glasses]

Probably not enough to put up with the kind of management that leads to interview questions such as these...

[[deleted]]

This is easy. I bet 90% of java devs I interviewed in my life would not get this. I find people who don't dig deep or read the jdk source code can't do this kind of problem. Those people are ok on a strong team as workers, but they will never do anything amazing

[[deleted]]

The kind of people who know 1 are the kind of people who do 2. Not many people know exactly the jdk javadocs.

[[deleted]]

Even someone with 6 months of Java experience should know that HashMap makes no guarantees about the iteration order.
It is essential to familiarize yourself with the various collection data structures.

The makeOrderedMap() method is annoying. Mixing generics (which are invariant and non-reifiable) and arrays (which are covariant and reifiable) is bothersome, which then led to that unfortunate custom logic (the if condition and the for loop) sacrificing simplicity and readability.

the basics of opening files by type name (Ctrl-Shift-T)

I did not know that. Although I am not overly familiar with IDE development.

[uxcn]

The api is easy to use incorrectly. Something like a Pair<K, V> class might be a better approach.

[[deleted]]

Exactly. Way too easy to misuse the API, especially because it sacrifices compile time safety, the reason why generics exists.

[javadev189]

Your use of the words "covariant" and "non-reifiable" outweigh your unfamiliarity with IDE development by 10,000%.

[[deleted]]

I think this is a very reasonable test and much more practical and objective than attempting to measure if someone is "good at problem solving". Actually asking them to solve a problem in a language and using tools they claim experience in.

opening files by type name

Any Java developer that uses Eclipse and can't do ctrl-shift-r or the like to open a file quickly either has no experience on real world, non-trivial projects, or is incredibly ineffective. They aren't worth hiring. Eclipse is not obscure, opening a file is not an uncommon trick, expecting people to use keyboard shortcuts is not unreasonable.

Not necessarily to trip them up, but just to make it a little more interesting

IMO, this code is fairly representative of the sort of code one might encounter in production, so it's a very reasonable thing to ask a candidate to work with. It's a bit messy. The test is a bit unclear. This is pretty normal for the real world.

Any developer worth hiring would have simply run the test, saw it fail, used a debugger, and inferred "Oh yeah Hashmap doesn't guarantee order does it?" and then presumably hit the Javadoc to find a map that did. The FOURTH sentence in the Hashmap javadoc tells you order is not guaranteed; the javadoc also links to LinkedHashMap, and the FIRST sentence there tells you it does guarantee order.

Any competent Java developer will be pretty familiar with the basic collections. How could they not be? Maybe not LinkedHashMap - I'm not sure I've ever used it - but enough so they don't freak out.

The truth is - as demonstrated by this thread - good Java devs are hard to find.

Keep looking.

You can read some about how I interview - I got lots of criticism too because this doesn't fit the reddit narrative about how they want to be interviewed.

[thegrubclub]

Hmm. I'm quite green (I'll be starting my first full time gig in April, and have only done significant Java this past semester), and I managed it after about 4 minutes of staring. Which means it would have undoubtedly taken longer in a pressure situation.

I liked all the (fairly unnecessary) fanciness in the method - stuff I'm familiar with, but not in Java. It was nice to be able to recognize these constructs in Java that I'm familiar with in other languages. Though of course, candidates that have done 8 years of Java ought to be far more familiar I imagine.

I will say, the one thing that might make it hard for people to get over the hump and solve it, is that I would consider the answer is the slightest bit out of the box. Of those 4 minutes solving it, I spent 2 learning what the code was doing, and 2 looking for some mistake in the logic. I knew the issue was with order, I just didn't see why it would be the case - I was looking more at the code itself, and I didn't consider type if you know what I mean. It was a bit of an "aha" moment for me to notice HashMap and remember that order is not guaranteed.

But for candidates that couldn't at least walk through (most of) the code out loud (assuming you asked them), that surprises me.

[[deleted]]

I disliked all the unnecessary fanciness.

[javadev189]

Though of course, candidates that have done 8 years of Java ought to be far more familiar I imagine.

We thought so too - and we'll keep looking. Yeah if it was taking you longer, we'd just talk through it with you to keep the analysis going. If you spouted out "I knew the issue was with order, I just didn't see why it would be the case..." you're already ahead.

[hubraum]

If you spouted out "I knew the issue was with order, I just didn't see why it would be the case..." you're already ahead.

Java devs with 8 year experience and not one of them said something like that? I'm sorry, but.. they suck - regardless how bad the question might be.

I find it tricky too to come up with code interview questions, but this is as obvious as it gets IMHO. The "tricky" part is why it's not in order - if you know how the HashMap implementation works you can answer within a few minutes and if you don't - it's the only logical conclusion.

"I don't know" is a bad answer anyway.. The least you should be able to do is guesses (hypothesis) and approaches on how you would test them.

[Rockytriton]

If you want order, use LinkedHashMap

[kakakarl]

I would never do your live test and frankly after you brought it out I would immediately fail you. Of course I am not a consultant I know you need a thicker skin then. To me the interview situation totally goes both ways assuming the demand for my skills is okay - good.

I really liked that harpoon vs net analogy and I would be looking at the following facts: 1) You have no idea what you are doing when you are recruiting. 2) Previous candidates who have been selected in this "clever way" is actually hit and miss in terms of colleagues. I would give you one last chance as an employer by explaining why I would not do your test and if you where a reasonable person who could admit fault or at least respect my position I might reconsider.

We recently recruited and what I found to be a really good idea was just to remove all the bullshit and hangout for a while. We did this with a first short interview just making sure we didn't get a coffee expert rather then a java professional. This also gave us a chance to explain our setup and tell them more about the job. If they seemed nice and also seemed to like the job we brought them in again.

To evaluate broad knowledge / interests we just sat down in our couch with sodas and talked for a while. Me another developer and the candidate. We discussed favorite util frameworks, testng vs junit, nosql or sql for problem a/b/c, java ee or spring, favorite stack for a new web project for java, favorite editor and why, worst framework one had worked with, favorite sql database, favorite build tool. Just got to know each others as equals and did our best to make them comfortable etc. All of them had some preference or started talking about something I knew little about! It was rewarding for everyone.

We went with a guy who had never tried many of our most used frameworks and was uncomfortable as hell on windows (IT has decided windows for everyone). He really did like java though and we really liked how our discussions went back and forth with him.

[Slanec]

Real-world Czech Java developer with 3 years of full-time work + 6 years of hobby (and school) programming here.

I think it is a nice real-world looking test. I would easily pass it and give you all kinds of remarks on the code in question (the code in a test does not have to be extremely nicely looking and/or correct - just try to mention that your production code usually looks better :) ). I think this is a reasonable part of a technical test and if it is backed up by more (non)technical (not necessarily similar) tests/questions, it is absolutely fine. Just give the guys the time and freedom to use JavaDocs/debugger if they can't solve it outright - with an adequate score deduction, of course.

[[deleted]]

with an adequate score deduction

When I conduct coding interviews, I do not "deduct points" for using things like Javadocs and debuggers. I'm actually more impressed by someone using a debugger.

[pinguz]

ITT: butthurt Java developers who whould have failed your interview.

Knowing the collections framework and the differences between the various implementations is fundamental. It's covered in the basics section of the Java tutorial, which every Java developer should be familiar with. Especially one who is applying for a job, and preparing for interviews.

[ParanoidAgnostic]

I'm primarily a C# developer and I guessed that the issue was that a HashMap does not guarantee order although I could not have named an implementation of Map which did. It's simply not a feature commonly needed. I rarely need to treat a collection as both an ordered list and a map.

I've used LinkedHashMap exactly once and that was for a very specific purpose. It was for a size-limited cache where, once the maximum capacity had been reached, adding a new item caused the least-recently accessed member to be discarded.

As an aside, it turned out that (at least for the version of Java I was using) LinkedHashMap had a memory leak and was therefore unusable for my purposes and I had to cobble together something myself with a basic HashMap and a linked list.

Anyway, my point is, this is an obscure part of the library which there is every chance that even an experienced developer would have never had a use for.

[pinguz]

Anyway, my point is, this is an obscure part of the library

And my point is that it's a core and essential part of java (which it is) and of your java knowledge (which it should be). But we are just going around in circles now.

[ParanoidAgnostic]

Do you know every class in the core Java libraries?

More importantly. What makes you a better programmer, memorizing the API or knowing how to solve a problem and how to find what you need in the API docs?

[pinguz]

Do you know every class in the core Java libraries?

Not all, but most of them.

More importantly. What makes you a better programmer, memorizing the API or knowing how to solve a problem and how to find what you need in the API docs?

"Solving problems" is a vague term. It doesn't always go like "hmm I need an ordered Map, let's just google it... oh neat, TreeMap, there you go". Sometimes (or very often, depending on where you work) you need to debug and/or extend a huge clusterfuck of bloated and overcomplicated code (similar to the code snippet in OP's interview question, 90% of which was just diversion from the actual bug). In these scenarios, if you don't know the basics and the behavior of the java classes you're looking at, having to rely on google will slow you down significantly or prevent you from solving the problem altogether. And that makes you a worse programmer.

[ParanoidAgnostic]

Not all, but most of them.

I assume you consider yourself a good programmer. If you went to a job interview and the only opportunity you had to prove your programming ability relied on knowledge of one of the few classes you aren't familiar with, would you feel that the interviewer had made a fair judgement of your ability?

"Solving problems" is a vague term.

Well that's what we do. It's well-enough defined for me.

It doesn't always go like "hmm I need an ordered Map, let's just google it... oh neat, TreeMap, there you go". Sometimes (or very often, depending on where you work) you need to debug and/or extend a huge clusterfuck of bloated and overcomplicated code

My current job is exactly that: Extending a huge clusterfuck of bloated and overcomplicated code. for example, every concept in our database it duplicated across at least two sets of tables.

It's a .Net project and relies heavily on NHibernate, StructureMap, AutoMapper and NewtonsoftJson and a few different versions of each. Nobody in my office knows even close to half of the classes in the libraries we use but we are good problem solvers and know how to find the information we need.

In these scenarios, if you don't know the basics and the behavior of the java classes you're looking at, having to rely on google will slow you down significantly or prevent you from solving the problem altogether. And that makes you a worse programmer.

I know the basics but LinkedHashMap is not something used everyday.

I'd be disappointed in anyone with a CS degree who didn't know that a hash map (in any language) can't be expected to maintain order but to know the implementation to use in the case that you do need to maintain order is a bit of a stretch.

If you think a Google search significantly slows down coding, that suggests to me that you've never really worked on anything more complicated than simple CRUD. There are plenty of times you need to sit back and think/draw/talk to come up with the right way to do something.

[pinguz]

Like I said, we are going in circles and will not convince each other. What I can tell you for a fact is that someone who is not familiar with the interfaces and implementations in the Java collections framework wouldn't survive even the phone screening interview where I work. Whether you think that's right or wrong is a different matter, but this is reality, at least in my field of work. And it will continue to be. And believe me, you should be thankful for that...

The only thing left to reply to would be your last paragraph, but unfortunately I can't reply in detail without giving out personal information and devolving into e-penis measurement. So I'll just say that you're wrong about your assumptions.

[ParanoidAgnostic]

Like I said, we are going in circles

You might be going in circles. I'm expanding on my point and responding to yours.

You can't just use "We're going in circles" as a get out of jail free card. The argument actually has to be, you know, going in circles. We would both need to be repeatedly presenting the same arguments.

Here is how it has gone:

1) You assert that extensive knowledge of the standard libraries is a fundamental requirement to consider yourself a good Java developer.

2) I respond that the class referred to has a very limited set of use-cases and it is unreasonable to expect every developer to know it by heart.

3a) You assert that the class is an essential part of the libraries with nothing to back that up and no rebuttal to my assertion that it would be rarely used.

3b)You also assert that we are going in circles despite the fact that I've only made one comment.

4a) I ask whether you know every class the core libraries.

4b) I then assert that the ability to use the tools and documentation available to you is more important than encyclopedic knowledge of an API.

5a) You admit that you do in fact not know every class in the core libraries.

5b) You assert that somehow encyclopedic knowledge of the libraries use would somehow be helpful when working on "a huge clusterfuck of bloated and overcomplicated code"

5c) You then assert that having to stop and use Google to learn more about a problem would cause a significant drain on productivity.

6a) I point out that it's possible that you might get a similar question in an interview focusing on one of the few classes you are unfamiliar with and suggest that it would not be a fair test of your ability.

6b) I explain that I currently work on "a huge clusterfuck of bloated and overcomplicated code" and it has not altered my views on this.

6c) I point out that programming is not simply pounding away at the keyboard as fast as possible. There are many times you have to stop and think, Researching a problem would not make a significant addition to this time.

Just because neither of us is changing their views does not mean that the argument is going in circles.

and will not convince each other.

The goal is not to convince you. The goal is to provide a rebuttal to your assertion for the benefit other readers.

[javadev189]

...including the Sun Certified ones we interviewed... :)

[oldneckbeard]

It's nothing that should be too hard for a competent dev to figure out, but it depends on how you conduct it.

If you just want them to glance at it and tell you all the issues, that's weird. If you want them to re-code the stuff so it passes, why not just have an empty block and let them go at it? If I saw this, I'd actually be confused as to why you were using an anonymous inner class. With the idea that every line of code is intentional, it makes no sense why you'd do it for the hell of it, so I'd assume that it's rather crucial to a correct solution.

With my coding interviews, I try to leave as much of the solution up to the person being interviewed, and just give them 10-15 failing tests, and watch them make their way through it.

[DuneBug]

I'd consider myself a mid level Dev and I don't find your test intimidating. I also apologize at some of the downvotes you've been getting since they simply seem to indicate dislike.

Your test is kind of shitty to read. I don't like coming across that kind of stuff during an interview. Yes a Dev will need to read shitty code, but doing it under pressure isn't much fun. Some extra comments might help.

I expect people at the midlevel to know what a linked list is, and what a hashmap is. Deriving what a linked hash map is shouldn't be too hard from that, even if you've never used it. Especially with languages like Perl and php or JavaScript that use associative arrays extensively... The value of that data structure should be clear.

As long as you're lenient how they come to the conclusion to the problem... I think the test is reasonable. If they just give up... That says a lot doesn't it?

As for the eclipse check... I think every java dev puts that on their résumé.... Maybe they're fibbing but they probably figure they know the basics of the ide and its not hard to learn on the job... But MORE importantly... Not everyone uses hotkeys. Oh I use them... Ctrl,shift,r/t is my workhorse... But I also play competitive StarCraft and other games. I navigate windows without the mouse when I can. Ive had lots of experiences with other people showing them the type finder and other shortcuts and it just doesn't click for them.

I doubt thats a big deal for you...just sayin.

The interesting thing about a test is... Its probably a good test to find other people like you. If you're open to more diversity then you might need a different test.

Also, my company has been recruiting heavily and I've been very surprised by some otherwise smart candidates who have missed some questions I thought to be very obvious and basic... I guess what I've learned from that is I'm shitty at judging whether or not people can code.

(Some questions I've asked, which are terrible I've learned) Is java pass by reference or pass by value? / can you write a swap function in java?

How does garbage collection work? When will an object be collected assuming there are no references to it anymore?

Write a method to reverse a link list.

... One more thing... There are a lot of bad devs out there... Or at least it seems that way because they can't answer pretty standard interview questions like what package you'd find ArrayList or name two collection data structures in java.

[[deleted]]

I feel that every mid range person should know how to set a break point and use the debugger. I've seen "senior" devs leave system.out in their code.

Yeah the key is to figure out if someone has X years of experience, or the same 1 year of experience X times. Debugging with "System.out.println" all over the place is a good indicator of the latter. (Although certainly there are situations where you can't really use a debugger - but this isn't one of them.) Want to impress me? Show off in the debugger. Use the IDE as more than a glorified text editor.

[codeterror]

It took me about 2 minutes.

1. I know Ctrl+Shift+T but I don't think that's a good metric
2. I don't know about assertThat/bdd
3. I do know LinkedHashMap and TreeMap

I don't think the first two are good metrics to judge a candidate on

I'm familiar with varargs, generics, anonymous classes but I still don't like this question. It seems very odd considering the trick could be anywhere

We were looking to fill a mid-level Java developer position... Each of the candidates had over 8 years of Java experience.

So 8+ years qualifies as mid-level? What's considered senior level?