I have read a blog post a few days ago about someone thinking a good programmer interview question was:
How does a hash table work?
While it is a very interesting question, I doubt many programmers (even relatively good ones) can answer that question. If I look back and think of all the employees in all the companies I have known, I can count on one hand people that can answer that question. I can think of 3 or 4 I met in one company, and maybe another 1 or 2 in different companies.
And I don't think anyone would have been able to go deeper in the details like mentioning closed-addressed vs open-addressed possible implementations.
I am so negative, because a question about some important details of the inner working of the Java HashMap was raised at work a week ago. I was the only one (because I had read several times about hash tables) to be aware that the "equals" method of the key object was called every time you do a table.get(xxx) or a table.put(xxx, yyy). Others thought only the hashCode() method was used.
This kind of interview question creates a high bias towards people coming straight out of school if they have Hashtable in their program. For people with more experience, it is highly likely if they ever read about it that they forgot the details (and maybe more than the details).
This can seem shocking as hash tables are used almost everywhere these days, but it's a reality.
And I don't think anyone would have been able to go deeper in the details like mentioning closed-addressed vs open-addressed possible implementations.
I am so negative, because a question about some important details of the inner working of the Java HashMap was raised at work a week ago. I was the only one (because I had read several times about hash tables) to be aware that the "equals" method of the key object was called every time you do a table.get(xxx) or a table.put(xxx, yyy). Others thought only the hashCode() method was used.
This kind of interview question creates a high bias towards people coming straight out of school if they have Hashtable in their program. For people with more experience, it is highly likely if they ever read about it that they forgot the details (and maybe more than the details).
This can seem shocking as hash tables are used almost everywhere these days, but it's a reality.
I ask this question, but only go as far as wanting to know how equals/hashCode interact, and that it is internally structured as buckets. This is my only algorithms question, and a light one at that, since I find it practical compared to tree operations.
ReplyDeleteI began asking it because, as I cleaned up caches during performance work, I was surprised at how badly most were done. Some had hard coded hashCodes, making them O(n). Others contained unbounded lists which caused production failures. Some would lock the entire map when making a database call to populate it, thus blocking all threads that might just read other entries.
So its very practical. The lack of understanding how it works means developers will get lucky by using core types that have equals/hashCode defined. Not knowing isn't a rejection, just a danger sign.
Asking a programmer how hash tables work is like asking a brain surgeon what AIDS stands for. It's not really relevant to their job, but a sign of something wrong if they don't know. Hashes aren't that rocket science.
ReplyDeleteIf you don't know that, it's fair to assume you don't know much about computer science fundamentals.
Yes, I'm biased as I asked that question. It's amazing what *most* people answer.
In my experience, people who can explain hashes aren't necessarily great. And people who can't, are always bad.
Better to ask that *and* other questions.
Any java developer who does not know why you have to overwrite hashCode AND equals should go back to school. This is fundamental stuff! Without this knowledge its just not possible to use it correctly. It's like not knowing that an int can overflow.
ReplyDeleteto Martin: Some people know that they have to override equals() and hashCode() but don't know why they have to.
ReplyDeleteIn reality, equals() is much more important than hashCode() to get right to have a correct code. hashCode() is more about performance.
I agree with other comments saying it is a pretty basic question, and it can lead to disastrous bugs. But it is still a relatively uncommon knowledge. I'd rather ask about more basic stuff than algorithms, things more important for everyday work (like basic OO stuff, basic Java stuff).
It's an absolutely fundamental question. What is also fundamental is knowing what the runtime analysis of a HashMap is, expressed in "big-O" notation. If they don't know when or why they need to use a HashMap, they don't know how to code, period.
ReplyDeleteI don't mind being asked "why would you use a hashtable/map" and "what does it do", but to be asked to implement it right there on the spot during an interview... WAY out of line. You can explain to some extent, but like the original poster said.. unless you are right out of school, you've generally long forgotten all the details. I use Hashtables (or maps) where applicable and I know when to use them, but I don't necessarily know all the internal workings of it. I don't think I am a bad programmer because I don't know the full details of it. That's why I have JavaDocs, google, and in some cases, peers to talk to. The Java API is a massive library of classes, and even much larger base of methods. To remember them, and all there internal workings is impossible. To know the "basics" of what to use in the language is plenty good enough. That said, there are those that will use them incorrectly, not clean up appropriately, etc. I've found that hashtables and lists are a common reason applications consume memory and dont release it.
ReplyDeleteTo my taste, asking how a Hashtable works has the same value as asking if every persistent entity that must be used inside a persistent Set should implement the equals() and hashCode() methods.
ReplyDeleteLooking at the Set javadoc, it seems it should. In reality, it is not needed, and in fact it can be dangerous. The answer only tells if you had the need to use it, but it says absolutely nothing about your overall quality.
90% of the HashMaps I have seen used String as key. You are asking about something specific to your case.
It's like asking what a http error 200 means.
Everyone gets so hung up about this "fundamental question" that no one really stops to think "Ok, he may not know this, but surely since the answer is only one fucking google search away, we might at least ask him about a real problem we've encountered, and how he would address it."
ReplyDeleteUltimately, are you interested in an interview as a means to feel better about yourself, or an interview as a means to finding someone good?
I've seen many amazing programmers get turned away from jobs because of idiotic questions like this. Do you want book-smart people who know everything, or street-smart people who can find out?