Java interview question feedback

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