Stupid Programmer Interviews

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.

Stupid Programmer Interviews

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.

The Art of Multiprocessor Programming Book Review

I don't remember why I started to subscribe to the Java concurrency-interest list. I find that overall, it is an excellent mailing list.
There was a post at one point about the Dante Inferno's problem. It triggered my attention, so I decided to buy the book the post was referring to, The Art of Multiprocessor Programming by M Herlihy and N. Shavit.

The books starts with the basics, and is very didactic in its approach. I enjoyed to learn how locks work and how to build them almost out of nothing. The progression is good, starting with a half broken but simple lock and evolving to the more standard algorithm, like the Bakery Lock algorithm. The algorithms are extremely well explained. Later it explains the differences between spin locks (Bakery for example) and blocking locks, while presenting new algorithms for blocking locks.

What is described in the many chapters is mainly how to write the javax.concurrency.utils library, why, and what to add to it.

Here are the main subjects I found interesting even if they are not always well presented:

• Bitonic networks: I had not read about it before and I found the subject fascinating. Go and click on the link if you don't know what I am talking about.
  
• Skip Lists: while I found the subject to be very interesting, I found the skip lists were not presented in a very clear manner. I find the wikipedia page about Skip Lists and the original paper much better to understand skip lists. Fortunately the authors talk about how to make it more concurrent friendly, and that part is well explained.
• Software transactional memory: I have the same opinion than with skip list, except the wikipedia page is very short on details, and the book does give much more details. We feel it is the end of the book and the authors took less time to present it an easily understandable manner. One need to read the chapter several times or to have read before about it to really understand.
  

I like books that make me learn new concepts. In The Art of Multiprocessor Programming, there are plenty of concepts, ideas I had never heard about before, even though most of it is probably well known to specialists in the field. So even if some rare subjects could be presented better, I recommend that book to anybody interested in concurrent programming.

The Art of Multiprocessor Programming Book Review

I don't remember why I started to subscribe to the Java concurrency-interest list. I find that overall, it is an excellent mailing list.
There was a post at one point about the Dante Inferno's problem. It triggered my attention, so I decided to buy the book the post was referring to, The Art of Multiprocessor Programming by M Herlihy and N. Shavit.

The books starts with the basics, and is very didactic in its approach. I enjoyed to learn how locks work and how to build them almost out of nothing. The progression is good, starting with a half broken but simple lock and evolving to the more standard algorithm, like the Bakery Lock algorithm. The algorithms are extremely well explained. Later it explains the differences between spin locks (Bakery for example) and blocking locks, while presenting new algorithms for blocking locks.

What is described in the many chapters is mainly how to write the javax.concurrency.utils library, why, and what to add to it.

Here are the main subjects I found interesting even if they are not always well presented:

• Bitonic networks: I had not read about it before and I found the subject fascinating. Go and click on the link if you don't know what I am talking about.
  
• Skip Lists: while I found the subject to be very interesting, I found the skip lists were not presented in a very clear manner. I find the wikipedia page about Skip Lists and the original paper much better to understand skip lists. Fortunately the authors talk about how to make it more concurrent friendly, and that part is well explained.
• Software transactional memory: I have the same opinion than with skip list, except the wikipedia page is very short on details, and the book does give much more details. We feel it is the end of the book and the authors took less time to present it an easily understandable manner. One need to read the chapter several times or to have read before about it to really understand.
  

I like books that make me learn new concepts. In The Art of Multiprocessor Programming, there are plenty of concepts, ideas I had never heard about before, even though most of it is probably well known to specialists in the field. So even if some rare subjects could be presented better, I recommend that book to anybody interested in concurrent programming.