 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2006Java questions: Urgent
Hi All, I was asked following questions in my interview so, I would appreciate that if anyone of u would answer them: 1, how fast is hash map? explain in terms of time complexity? 2.how would u group multile statements as one transaction in JDBC? 3.how woould map inheritance to DB schema? 4.Which method do u overide in hashmap?something related to keys? I may not be explaining it correctly. Thanks! >1, how fast is hash map? explain in terms of time complexity? It depends on how relatively full it is. If you keep it less that 3/4 full your chains will be short and it wont' take any more time to look up in a big list as a small. But if you let it approach 100% full, then chains can get very long. In the most pathological case when all your hashes are equal the lookup time is proportional to N, the size of the list since all item are one one chain. See http://mindprod.com/jgloss/hashcode.html  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>1, how fast is hash map? explain in terms of time complexity? > [quoted text clipped - 6 lines] > > See http://mindprod.com/jgloss/hashcode.html Isn't the textbook answer an order 0? Then as collisions develop . . . -- LTP :) On Mon, 30 Jan 2006 21:28:51 -0700, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >Isn't the textbook answer an order 0? no. It is somewhere between 0 and n depending on how ineptly you set it up. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Isn't the textbook answer an order 0? You mean O(1)? > Then as collisions develop . . . Supposedly it remains O(1), with lumps. I haven't done or seen the mathematics to check that. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >4.Which method do u overide in hashmap?something related to keys? I may >not be explaining it correctly. you don't override methods in HashMap. You override Object.HashCode SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > I was asked following questions in my interview so, I would appreciate > that if anyone of u would answer them: So why is it urgent? > 1, how fast is hash map? explain in terms of time complexity? > 2.how would u group multile statements as one transaction in JDBC? > 3.how woould map inheritance to DB schema? > 4.Which method do u overide in hashmap?something related to keys? I may > not be explaining it correctly. 4. is probably asking which methods from Object would you override when writing a class designed to be used as a key for a HashMap. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ It is urgent so that I don't repeat same mistakes in my next interviews. >It is urgent so that I don't repeat same mistakes in my next interviews. You wont get the same questions. You should have answered "hashCode and equals" SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. You asked 2.how would u group multile statements as one transaction in JDBC? This may help if your browser supports Java : http://javalessons.com/cgi-bin/adv/java-j2ee-jdbc.cgi?subject=jdbc&1cd=jdb&sid=ao789 In the Lesson Viewer lookup the paragraph that starts with :'If you want a couple of update statements', etc.. this applies to the source code lines 59-71 --- Paul Hamaker, SEMM http://javalessons.com > Hi All, > [quoted text clipped - 6 lines] > 4.Which method do u overide in hashmap?something related to keys? I may > not be explaining it correctly. Indeed, very common interview questions. I feel almost as bad answering these as I would doing someone's homework, but for the benefit of the group: 1. The time complexity of HashMap is O(1) -- it's constant. (Read "big-oh of one.") 2. Grouping multiple statements in JDBC: Connection cnxn... cnxn.setAutoCommit(false); // do a bunch of stuff with Statements and/or PreparedStatements and/or CallableStatements cnxn.commit(); 3. Mapping inheritence to a DB schema. There are several (many) strategies for doing this, and trying to summarize here is only going to lead to confusion. Try reading the Hibernate documentation on subclassing, and understanding the many different ways Hibernate supports for mapping subclasses. 4. What do you need to do to make a class you write usable as a key in a HashMap? You must override both hashCode() and equals(). hashCode() should be implemented to provide as near a unique number based on the values of the fields of the object as is reasonably efficient to compute. If equals() returns "true" on an object, hashCode() on the two objects must return the same integer. > 2. Grouping multiple statements in JDBC: > [quoted text clipped - 6 lines] > > cnxn.commit(); When I skimmed through the questions, I read that as referring to batch. Auto-commit off is just automatically assumed reflex. > 3. Mapping inheritence to a DB schema. > > There are several (many) strategies for doing this, and trying to summarize > here is only going to lead to confusion. Try reading the Hibernate > documentation on subclassing, and understanding the many different ways > Hibernate supports for mapping subclasses. The three common ways: o Everything in one table with a concrete class id which indirectly indicates which fields are valid (the constraints are a nightmare...). o A table per concrete class. Base class columns are repeated throughout. Not so good with auto-identity columns. PostgreSQL's INHERIT comes in useful. o A table per extension. All objects are represented in the base class table. Subclasses each have their own table with their private fields and a primary key that is a foreign key linking back to the base table. Again, not so good with auto-identity columns. Lots of joins, but not necessarily too bad in terms of performance. Martin Fowler's Patterns of Enterprise Architecture has a section on this sort of thing. > 4. What do you need to do to make a class you write usable as a key in a > HashMap? [quoted text clipped - 4 lines] > returns "true" on an object, hashCode() on the two objects must return the > same integer. Or nothing at all if the identity behaviour is required... Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > 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 SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > Hi All, > [quoted text clipped - 6 lines] > 4.Which method do u overide in hashmap?something related to keys? I may > not be explaining it correctly. 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)? -- 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 [quoted text clipped - 5 lines] > Can you override String.hashCode()? > Why (or why not)? The problem with questions like these, IMHO, is that these issues don't generally affect most development and seem adequately covered by the Javadoc. I'd be more concerned that the candidate knows when to use synchronization, when to leave it off for efficiency, when to use each kind of container class, and so on. >> 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), [quoted text clipped - 11 lines] > synchronization, when to leave it off for efficiency, when to use each > kind of container class, and so on. I definitely disagree. (That is, if the questions are asked in-person and the candidate is not allowed to use the javadocs.) These issues can affect development -- if you're doing certain things. This line of questions pretty rapidly establishes the depth of the candidate's fluency with: * The libraries * The concepts of inheritence, overloading, and polymorphism * The concepts of value-based classes, final classes, and immutibility. All without picking on anything but classes present in java.lang! Of course, synchronization and the collections framework should also be probed during a technical interview... -- Adam Maass >>> What does System.identiyHashCode() do? >>> What does Object.hashCode() do? >>> What does String.hashCode() do? >>> Can you override String.hashCode()? >>> Why (or why not)? >> The problem with questions like these, IMHO, is that these issues don't >> generally affect most development and seem adequately covered by the >> Javadoc. I'd be more concerned that the candidate knows when to use >> synchronization, when to leave it off for efficiency, when to use each kind >> of container class, and so on. > I definitely disagree. (That is, if the questions are asked in-person and the > candidate is not allowed to use the javadocs.) These issues can affect > development -- if you're doing certain things. Being new on the platform I can relate to many of the described situations (and its becoming clear that I still have a lot to learn) but I can't help wonder about something here... You state that your line of questioning will help give the questioner insight to the understanding of some basics like: > * The libraries > * The concepts of inheritence, overloading, and polymorphism > * The concepts of value-based classes, final classes, and immutibility. But doesn't it also implying that the person in question needs to know certain libraries and their inner workings from mind ? I somewhat cannot fully place that, since Java is so extensive (from my point of view at least) that I find it rather hard to be able and grasp the meaning / inner workings of certain classes / methods without the Javadoc API specs. I can't help wonder if focussing on understanding rather than knowledge isn't a big issue here as well. For example, I might have used 'String.hashCode' a few times now and thus know from mind that its returning an hash code (which is a little obvious) yet don't know 'String' well enough to know from mind about its final state. But I do know that 'final' means it can't be overridden. Wouldn't you rule out some people who might have a certain potential here? Unless ofcourse you'd allow answers like "I have no idea if it can it, but if its final it cannot". I can't help wonder if a question in the likes of "When can you override a method and when not?" would point out a more global understanding since now you're asking about the 'why' instead of focussing on a single entity which people may or may not know from mind. SignatureGroetjes, Peter .\\ PGP/GPG key: http://www.catslair.org/pubkey.asc This line of questions pretty > rapidly establishes the depth of the candidate's fluency with: > [quoted text clipped - 8 lines] > > -- Adam Maass SignatureGroetjes, Peter .\\ PGP/GPG key: http://www.catslair.org/pubkey.asc > But doesn't it also implying that the person in question needs to know > certain libraries and their inner workings from mind ? I somewhat cannot > fully place that, since Java is so extensive (from my point of view at > least) that I find it rather hard to be able and grasp the meaning / > inner workings of certain classes / methods without the Javadoc API specs. 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. 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. It's easier to take the questions out of order. 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. 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.) 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). 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. One assumption that I've made in the above is that you are expected to know about the relationship between hashCode() and equals(). The reason for that is simply that I would expect any programmer to have used the hashed collections, I would expect any programmer to have had some experience of creating their own classes, and I would consider it extraordinary if that programmer had never had to put instances of his or her classes into a collection nor ever had to compare them for equality. These are basic skills. And in order to do these things, you need to understand equals() and hashCode() and the relationship between them. Obviously those questions don't cover all the basics. There are probably other (equally small) sets of questions that would probe a selection of basics that I'd prefer. 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. -- chris > 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. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > 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 [quoted text clipped - 17 lines] > (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. [quoted text clipped - 4 lines] > 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 [quoted text clipped - 6 lines] > 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. > 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... > 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 [quoted text clipped - 3 lines] > 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. [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 On Thu, 2 Feb 2006 11:59:36 -0000, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : >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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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) Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html >> Q What does System.identiyHashCode() do? >> A It tells you a hash code for an object that only depends on /which/ [quoted text clipped - 6 lines] > > (Sorry, couldn't resist) LOL. My fat-fingered bad-o. -- Adam Maass On Wed, 1 Feb 2006 16:37:55 -0000, "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly quoted someone who said : > 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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >> I somewhat cannot fully place that, since Java is so extensive (from my >> point of view at least) that I find it rather hard to be able and grasp the >> meaning / inner workings of certain classes / methods without the Javadoc >> API specs. > 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. SignatureGroetjes, Peter .\\ PGP/GPG key: http://www.catslair.org/pubkey.asc > > What does System.identiyHashCode() do? > > What does Object.hashCode() do? [quoted text clipped - 7 lines] > synchronization, when to leave it off for efficiency, when to use each > kind of container class, and so on. 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. Precisely the ones who will not have the (very moderate) understanding necessary to handle the kinds of issues you mention. -- chris > 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 [quoted text clipped - 3 lines] > "task-oriented" education. Precisely the ones who will not have the (very > moderate) understanding necessary to handle the kinds of issues you mention. 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() - I have never used Object.hashCode() - I might have even never implemented a hashCode() method - I might have never looked at the performance of a hash map (I think I did, but I'm not sure) Still: - I know what hashCode() does - I would probably be able to find out the faster algorithm I guess I can now assume that I wouldn't be hired everywhere, but I would say that there are a lot of things you never really use, and you never look at them, or you look at them and then you forget. 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; I personally prefer someone who doesn't know how fast a hash map is but writes his code with comments, just to make an example. One of the best developers I have met didn't even know what design patterns were. And, of the questions I have seen, the one I appreciate most is the question about inheritance-DB mapping. Although it's not really Java related > > 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 >> - 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). 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.) >> - 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. 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/ [quoted text clipped - 6 lines] > 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 On Wed, 01 Feb 2006 16:35:07 +0100, Andrea Desole <news@desole.demon.NOSPAMPLEASE.nl> wrote, quoted or indirectly quoted someone who said : >- 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? SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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. On Thu, 02 Feb 2006 10:15:03 +0100, Andrea Desole <news@desole.demon.NOSPAMPLEASE.nl> wrote, quoted or indirectly quoted someone who said : >> you have never looked up something by a pair of strings? > >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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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), [quoted text clipped - 5 lines] > 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 > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> System.identityHashCode() gives an integer identifier for an object based >> on that object's identity. Object.hashCode() delegates to [quoted text clipped - 9 lines] > > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.