Java questions: Urgent

[Chris Uppal]

My own (rather limited) experience of interviewing is that candidates
who can't answer questions like Adam's tend not to understand the
basics of anything. I don't know about Adam's questions /specifically/
(though they seem reasonable to me), but in general easy-but-low-level
questions seem quite good at exposing the programmers who have learned
by rote, or have been subjected to "task-oriented" education.

[...]

I think the question is how easy and how low-level the questions must
be. Personally, in 4 1/2 years of Java:

- I have never used System.identityHashCode()

Understandable. They didn't even get around to adding to Java until after it
had been out for a while (though I don't consider /that/ understandable ;-)

- I have never used Object.hashCode()

You have never used a java.util.HashTable or java.util.HashSet ? Or do you
just mean that you've never had to write something which /used/ the hash code
(which would be perfectly reasonable).

- I might have even never implemented a hashCode() method

But you know how to do it, and why and when you must do it. What's more,
you, /need/ to know these things, whether you've had occasion to use them or
not -- a requirement to implement equals() or put instances of a custom class
into a HashSet is routine.

- I might have never looked at the performance of a hash map (I think I
did, but I'm not sure)

There might
be jobs where questions like these are extremely important, and you
really have to know it, but I don't think this is the usual case.
Knowledge of the concepts and attitude are the most important thing; [...]

Well, I agree with the last sentence (as trimmed), but not the first. Or
rather, whether the first is true or not, my experience is that people who /do/
have an understanding (rather than a rote-learned collection of unrelated
facts, and code idioms) /do/ also know these very basic and fundamental things.
There are lots of other basic and fundamental things, some of them may be more
important, but -- since you have to know /all/ of the basics -- probing /any/
of them is a good test (if suitably interpreted). And, since I think that
anyone with real understanding will quickly and naturally get all the
basics, I think that testing any of them is an informative test of whether
the candidate has (and wants) real understanding.

BTW, my answer to "Lion-O" talks about some of these things from a slightly
different angle.

-- chris

 

[Andrea Desole]

You have never used a java.util.HashTable or java.util.HashSet ? Or do you
just mean that you've never had to write something which /used/ the hash code
(which would be perfectly reasonable).

There might be a misunderstanding here. I was talking about the
implementation itself of Object.hashCode(); this is how I understood the
question. In other words (quoting from the JDK documentation), I
wouldn't immediately know, although I might be able to guess, that:

As much as is reasonably practical, the hashCode method defined by class
Object does return distinct integers for distinct objects. (This is
typically implemented by converting the internal address of the object
into an integer, but this implementation technique is not required by
the JavaTM programming language.)

But you know how to do it, and why and when you must do it. What's more,
you, /need/ to know these things, whether you've had occasion to use them or
not -- a requirement to implement equals() or put instances of a custom class
into a HashSet is routine.

Absolutely. But what I mean is that I might have to look at the
documentation. For example, I'm not sure I remember correctly the
conditions an implementation of hashCode() has to fulfill. It is a very
important thing if you have to implement it, but I could fail if asked,
since I don't do it very often

Well, I agree with the last sentence (as trimmed), but not the first. Or
rather, whether the first is true or not, my experience is that people who /do/
have an understanding (rather than a rote-learned collection of unrelated
facts, and code idioms) /do/ also know these very basic and fundamental things.
There are lots of other basic and fundamental things, some of them may be more
important, but -- since you have to know /all/ of the basics -- probing /any/
of them is a good test (if suitably interpreted). And, since I think that
anyone with real understanding will quickly and naturally get all the
basics, I think that testing any of them is an informative test of whether
the candidate has (and wants) real understanding.

Of course. If you know and understand the concepts the tool (in this
case Java) you use is based on, you also know the basics, plus a number
of other things that are related more specifically to your work. As I
said, the question is more what "basics" means, but I understand from
your comments about hashCode() that my opinion might not be much different.

BTW, my answer to "Lion-O" talks about some of these things from a slightly
different angle.

I'll look at it

 

[Monique Y. Mudama]

BTW, if you aren't yet able to answer these yourself, please don't
take it personally ;-) You've said that you're a beginner here, and
everyone has to start somewhere.

I'm not a beginner here, and I'm still not sure I would be able to
answer all of these particular questions from memory. Javadocs are my
friend.

As one of my CS profs said, "If you don't use this stuff very often,
you may not remember it, but you'll be able to look it up and
understand it. If you use it often, you'll remember it." He was
talking about his discrete math course, but I think it applies equally
to the current discussion.

That being said, I can't come up with a decent set of questions at the
moment that would lead me to hire or reject a particular candidate.
So maybe they're good questions, or as good as they get.

 

[Andrea Desole]

Q What does Object.hashCode() do?
A Gives you an integer that can be used to locate objects in hashed collections
like HashSet or HashMap.
Since HashSet and HashMap are important utility classes, I would expect anyone
to have at least some experience with them. More on this below.

I'm still not sure this is the real meaning of the question

Q What does String.hashCode() do?
A It gives you a number to use as a hash code which depends only on the
characters in the String.
It may seem surprising that this is something I regard as basic understanding,
So basic that I would /require/ someone to know it or be able to work out the
answer. The logic is as follows:
Strings are absolutely central to Java programming.
There are some basic facts about Strings that everyone
/has/ to know.
One of those facts is that you shouldn't compare Strings
using ==. You must (nearly always) use the equals()
method, which overrides the Object.equals() method to
compare the two strings character-by-character.
Therefore (see below) Strings must also provide their
own override of hashCode() too, which is compatible with equals(). (To use
the technical term; you are not requred to know the jargon ;-)
To be compatible with equals() requires that the hashCode()
only depend on the characters in the String.
Therefore that's what String.hashCode() does.
(A more knowledgeable programmer might know more, but anyone should be able to
answer that much -- at least if they weren't too nervous to think.)

Valid. But my first answer would just be "it gives you the hash code of
the string". I wouldn't probably get that the intention is to talk about
the relationship between equals() and hashCode(), or between equals() and ==

Q Can you override String.hashCode()?
A No.
If the answer was because String.hashCode() was declared final then it's not
something I would regard as particularly indicative -- it would just be one of
those facts that you either know or don't know. But the actual reason is that
the String class /itself/ is final, and /that/ is one of the basic facts about
Strings that I think everyone should know (another such fact is that Strings
are immutable).

Okay, it would be nice to know how strings work, but are you sure it's
so important to know that a string is final and immutable? I find it
hard to think that someone might want to subclass a string, not to
mention overriding hashCode(). In any case it would be pretty easy to
find out by compiling the code; also, the documentation clearly says it,
and it also says that string buffers support mutable strings, giving you
a solution.
My first answer would probably be "why should I?"

Q What does System.identiyHashCode() do?
A It tells you a hash code for an object that only depends on /which/ object
it is. So that it is compatible with ==, in the same way as hashCode() is
expected to be compatible with equals().
To be honest, I wouldn't call this question as relevant as the others. I can
easily imagine someone being moderately competent and never having come across
the need for hashing based on identity. OTOH, even a moderate curiosity about
the java.util package would lead a programmer to discover these things -- and
java.util is one of the packages that I would expect /any/ Java programmer to
be curious about.

True, and this method is also in a very important class. But there a lot
of things to look at. It's easy to miss something.
I think I have never heard of this method, and to be honest I can't
imagine a situation when I would need it.

It's true that you should be able to discuss at least a few of these
questions; you should know what equals() is, and hashCode(), and a
string. But I still doubt these are the most important questions to be
asked.

 

[Monique Y. Mudama]

Q What does System.identiyHashCode() do?
A It tells you a hash code for an object that only depends on /which/ object
it is. So that it is compatible with ==, in the same way as hashCode() is
expected to be compatible with equals().

Actually, it gives you a compiler error ...

(Sorry, couldn't resist)

 

[Lasse Reichstein Nielsen]

1. The time complexity of HashMap is O(1) -- it's constant. (Read "big-oh of
one.")

That goes for all single element operations. Multi-element operations
like addAll will ofcourse take more.

The complexity is probably only amortized constant. When you add the
n'th element and the capacity is increased, all elements are
reordered, which could potentially take time linear in the size. As
long as the increment grows enough with the size (just a fixed size
increment), the time taken for a sequence of adds to an empty set will
always be linear in the number of elmeents added.


/L

 

[Roedy Green]

To be compatible with equals() requires that the hashCode()
only depend on the characters in the String.

HashCode, equals, compare and compareTo have a logical "contract"
they must fulfil, a set of rules about consistency. You can't just use
arbitrary code inside them, or else collections and sorts will fail.

These rules will be familiar to anyone who has studied mathematics,
especially group and ring theory. HashCode need not be unique. Equals
is permitted to consider objects with different fields equal.

See the Javadoc or the more informal explanations in the Java
glossary.

 

[Roedy Green]

- I have never used Object.hashCode()
- I might have even never implemented a hashCode() method

you have never looked up something by a pair of strings?

 

[Lion-O]

I somewhat cannot fully place that, since Java is so extensive (from my

That's a reasonable attitude, but I think that Adam's questions are a bit
more subtle than you might think. I'll try to give answers to them (not the
best possible answers, just acceptable ones), to say why those answers must
be true, why I would expect almost any Java programmer to be able to answer
them correctly, and why I think they do probe some aspects of real
understanding.

Great, thanks a lot for the effort.

BTW, if you aren't yet able to answer these yourself, please don't take it
personally ;-) You've said that you're a beginner here, and everyone has to
start somewhere.

Which is the main reason I "butted" in a bit.. A lot of questions like these
which adress "more advanced yet basic" issues can be very valuable information
/ pointers for beginners. IMO ofcourse... I already jotted down a few topics
which others deemed "basic knowledge for Java programmers" in order to read up
on them at a later time. Rest assured that I looked these up myself as well
before responding to it. So no worries, no offense what so ever. I welcome all
the input I can get.

Q What does Object.hashCode() do?

A Gives you an integer that can be used to locate objects in hashed
collections like HashSet or HashMap. Since HashSet and HashMap are important
utility classes, I would expect anyone to have at least some experience with
them. More on this below.

Well, this is one of those topics I mentioned earlier which ended up on my todo
to have a closer look see at a later time.

Q What does String.hashCode() do?

A It gives you a number to use as a hash code which depends only on the
characters in the String.

Hmm, I'm pleased I got that part close enough. Even though I have to admit not
to have worked with hashes yet, so I don't know much right now on their
specific uses.

It may seem surprising that this is something I regard as basic
understanding, So basic that I would /require/ someone to know it or be able
to work out the answer. The logic is as follows:

---<Cut: String.equals() vs. ==

Therefore (see below) Strings must also provide their own override of
hashCode() too, which is compatible with equals(). (To use the technical
term; you are not requred to know the jargon ;-)

To be compatible with equals() requires that the hashCode() only depend
on the characters in the String. Therefore that's what String.hashCode()
does.

Well, I have to admit not having looked at it from this perspective, it makes
good sense to me though. I think I follow your logic here quite well, it does
clearly lay it out as to why you could *reason* to come to the right answer.
Very interesting indeed, I really appreciate the input here.

(A more knowledgeable programmer might know more, but anyone should be able
to answer that much -- at least if they weren't too nervous to think.)


Q Can you override String.hashCode()?
A No.

But the actual reason is that the String class /itself/ is final, and /that/
is one of the basic facts about Strings that I think everyone should know
(another such fact is that Strings are immutable).

Yes, I can relate and agree to this one. Its also something the tutorials
almost start with (if not soon after the basic history). I think, but not sure
from mind, that one of the tutorials I followed even used the String class to
demonstrate the final state.

Q What does System.identiyHashCode() do?
System.identifyHashCode()

OTOH, even a moderate curiosity about the java.util package would lead a
programmer to discover these things -- and java.util is one of the packages
that I would expect /any/ Java programmer to be curious about.

That too is something I can relate to. Its why one of the first things I
started with was looking, skimming, reading and trying out the things I found
in the Javadoc API references. Since most of the tutorials quickly tell you
that java.lang and java.util are always loaded it becomes quite clear that
having a little familiarity with them might be very usefull It is also one
of those fields I still lack experience though.


I'm not going into your comments regarding the the need to understand equals()
and hashCode() and their relationship simply because I don't have that kind of
experience yet and I feel it would be ridiculous for me to comment. Still, I do
see and understand your reasoning a lot better now and have to agree on the
part that you should be able to find certain answers through reasoning.

But -- as I've said -- my experience is that people tend either to have the
kinds of minds, experience, and training, that emphasise /understanding/ and
therefore naturally cover all the basics, or they have missed out badly
somewhere. And in the latter case, I would not care to employ them.

*nod*. Thanks again for your very diverse reply on this.

 

[Adam Maass]

Actually, it gives you a compiler error ...

(Sorry, couldn't resist)

LOL. My fat-fingered bad-o.

-- Adam Maass

 

[Adam Maass]

I've been interviewing for a new job recently (tons of jobs out there
these days; it looks like Silicon Valley is finally coming alive again),
and my favorite line of technical questions went like this:


What does System.identiyHashCode() do?
What does Object.hashCode() do?
What does String.hashCode() do?
Can you override String.hashCode()?
Why (or why not)?

My answers, from memory from about two weeks ago:


System.identityHashCode() gives an integer identifier for an object based on
that object's identity. Object.hashCode() delegates to
System.identityHashCode(). String.hashCode() overrides Object.hashCode() to
provide a hashCode based on the content of the char[] the String represents.
One cannot override String.hashCode() as String is final; this is one of the
pre-conditions for making a class "immutible."


-- Adam Maass

 

[Andrea Desole]

you have never looked up something by a pair of strings?

you mean a key made by two strings? I remember me implementing a
hashCode() somewhere, but I don't remember for what (I think it was two
integers), so I'm not sure I did. I would say that most of the times the
key is a number or a single string, like an id or a name.

 

[Adam Maass]

Okay, it would be nice to know how strings work, but are you sure it's so
important to know that a string is final and immutable?

The immutability of Java's String class is one of the points that sets Java
apart from other languages and platforms. IMHO, a candidate that hasn't run
into issues with the immutability of String doesn't know enough Java to
merit further consideration. Plus points to a candidate that knows how
String's immutability is achieved.

Now, having said that, there are other lines of questioning that would also
reveal whether the candidate understands String's immutability -- but I
really liked the question about overriding String's hashCode(), because it
is surprisingly subtle.

I find it hard to think that someone might want to subclass a string, not
to mention overriding hashCode(). In any case it would be pretty easy to
find out by compiling the code; also, the documentation clearly says it,
and it also says that string buffers support mutable strings, giving you a
solution.
My first answer would probably be "why should I?"

And that would be a perfectly valid response. If I were posing the
questions, I'd probably insist that you give me a yes-or-no answer. If you
couldn't without a reason to subclass String, I'd try to come up with a
reason that works for you.

Perhaps you want Strings that only represents integers.
Or that only accept upper-case letters.

And as part of the contract on this special subclass of String, you also
want to override hashCode...

 

[Andrea Desole]

The immutability of Java's String class is one of the points that sets Java
apart from other languages and platforms. IMHO, a candidate that hasn't run
into issues with the immutability of String doesn't know enough Java to
merit further consideration. Plus points to a candidate that knows how
String's immutability is achieved.

that's true. A fairly complex piece of code that doesn't modify strings
is very unlikely. I'm still not sure this is really important, but I
understand the argument

And that would be a perfectly valid response. If I were posing the
questions, I'd probably insist that you give me a yes-or-no answer. If you
couldn't without a reason to subclass String, I'd try to come up with a
reason that works for you.

Perhaps you want Strings that only represents integers.
Or that only accept upper-case letters.

Now that I'm thinking about it, it might be possible to come up with a
good reason to implement a string subclass (although not to override
hashCode(), but it doesn't really matter). Good point.

 

[Roedy Green]

you mean a key made by two strings?

first name and last name,
directory and filename
car model and year

when you have a hierarchy, you can intern the higher level strings to
shrink the size of the lookup table. This is how the Replicator works.

 

[Chris Uppal]

Andrea Desole wrote:

[me:]

Q What does Object.hashCode() do?
A Gives you an integer that can be used to locate objects in hashed
collections like HashSet or HashMap.

[...]
I'm still not sure this is the real meaning of the question

Well, that the way /I/ interpreted it. If the interviewer, or the interviewee,
interprets it differently then it's up to one or the other to say so.

But if I asked this question and got a disquisition on advanced JVM
implementation techniques then I'd be quite happy, even though that wouldn't be
what I'd expected ;-)

Q What does String.hashCode() do?

[...]
Valid. But my first answer would just be "it gives you the hash code of
the string".

I'd laugh and say "...and ?".

I wouldn't probably get that the intention is to talk about
the relationship between equals() and hashCode(), or between equals() and
==

Then it's my job, as an interviewer, to prompt you a bit. "Why is it different
from Object.hashCode() ? What is the difference ? Do you know anything about
how it works ?"

Q Can you override String.hashCode()?

[...]
Okay, it would be nice to know how strings work, but are you sure it's
so important to know that a string is final and immutable?

I would say so, yes. Mutability is a fundamentally important concept in OO
(and programming generally). And if anyone knows anything about immutable
objects, then they surely know about String. Declaring a class final is also
an important Java concept (not as important as immutability, though there is
some overlap), and again, if anyone knows about final at all then I'd expect
them to know that String is final. Also -- looking at it the other round --
String is a fundamentally important class in Java, so I'd expect a candidate to
be pretty well acquainted with it, certainly not to the point of having
memorised all those little methods, but I'd expect them to all the important
characteristics.

It's true that you should be able to discuss at least a few of these
questions; you should know what equals() is, and hashCode(), and a
string. But I still doubt these are the most important questions to be
asked.

The point I'm trying to make is not that these are the most important topics to
cover -- there are obviously going to be much more /relevant/ questions to ask
("Tell me about your experience of Tomcat/Log4j/whatever", "When did you last
attempt to murder another member of your team ?, "Will you have sex with me ?",
etc..). The point of /these/ questions is to look for symptoms of a lack of
understanding[*]. Sort of like a doctor asking if you have spots: he doesn't
care very much about the spots themselves (they're /your/ problem), but the
answer will help him do what /he/ cares about -- which is to work out what's
wrong with you. Whether these /specific/ questions do that and, if they do,
whether they do it well, are both debatable, but I think the idea is sound.

([*] Note: understanding != knowledge)

-- chris

 

[Roedy Green]

The point I'm trying to make is not that these are the most important topics to
cover -- there are obviously going to be much more /relevant/ questions to ask
("Tell me about your experience of Tomcat/Log4j/whatever",

Gordon Shrum was a "hard boiled" executive who ran BC Hydro for many
years. When someone went into his office with a proposal, he would
probe with a few extremely detailed questions, a bit like poking pike
into a haystack. After 5 or 6 of these probings coming out clean he
would assume the entire project was sound.

It drove the employees crazy with fear. They never knew where he was
going to strike.

 

[Thomas Hawtin]

System.identityHashCode() gives an integer identifier for an object based on
that object's identity. Object.hashCode() delegates to

"identifier
"n : a symbol that establishes the identity of the one bearing it"
-- WordNet (r) 2.0

The values returned by System.identityHashCode are not unique (even
within a single instance of a 32-bit JVM, with objects existing at the
same time). You cannot, therefore use identityHashCode alone to
establish the identity of an object.

System.identityHashCode does not give indentifiers.

Tom Hawtin

 

[Adam Maass]

"identifier
"n : a symbol that establishes the identity of the one bearing it"
-- WordNet (r) 2.0

The values returned by System.identityHashCode are not unique (even within
a single instance of a 32-bit JVM, with objects existing at the same
time). You cannot, therefore use identityHashCode alone to establish the
identity of an object.

System.identityHashCode does not give indentifiers.

Well, yes. I meant "identifier, as far as is possible with a 32-bit value."
Of course, I didn't write that the first time, did I? LOL.

-- Adam Maass