Is there some resource for challenging multi-threading problems? Would like to pose these to interviewees if possible. Tired of asking the same wait-notify questions that everyone gets right these days, but can't visualise a real scenario where multi-threading was employed.
+5
A:
Java Concurrency In Practice. I like to know if candidate understand data race, CAS, Michael Scott Queue and other concurrent data structures and how concurrent thread safety is important with growing number of cores.
Chandra Patni
2010-01-03 07:54:35
+6
A:
The problem is that concurrent programming is a difficult topic. If you (the interviewer) are not fully on top of it, it will be difficult for you to tell if the interviewee knows his/her stuff. It is very easy to come up with solutions to concurrency problems that have subtle flaws. Conversely, it is unfair on a candidate if you reject him because you think his answers are wrong when they are actually right.
Stephen C
2010-01-03 09:09:31
A:
I got one in a interview recently. Get the candidate to write a Servlet that implements an accurate in memory hit counter indexed by URL (to serve a javascript style hit counter on a number of web page). Try it for yourself, it's not as easy as it sounds. The solution is a cut down implementation of the Memoizer pattern from Concurrency in Practice.
Michael Barker
2010-01-03 09:37:02
That sounds like a StackOverflow question on its own. What are the issues? Could you not use a ConcurrentHashMap and some AtomicLongs? (I'm assuming not clustered).
jamie mccrindle
2010-01-03 10:35:37
That's basically it. If you implement it, it looks similar to the Memoizer, but without the FutureTask. However it's surprisingly tricky to do in the midst of an interview.
Michael Barker
2010-01-03 11:58:13
A:
As multithreading is hard (as others have pointed out) I would suggest having this in an actual programming session where the potential employee is given a programming problem preferrably based on something that has actually happened along with one of your experienced programmers so you can actually SEE how the problem was attempted solved, and the experienced programmer can evaluate what happened.
Must not be too complex, but complex enough that your expereinced programmer get enough information.
Thorbjørn Ravn Andersen
2010-01-03 11:44:28
+1
A:
Well, if you want to have fun with the poor sap, ask him about Dekker's Algorithm (and Peterson's variation thereof). If you're feeling nasty, ask him if he has ever used either one on real multiprocessor hardware.
If you feel extra-nasty, ask him to show you a technique suitable for lock-free true concurrent single-reader single-writer unidirectional communications, between two processors with shared memory, in which the only atomic operations are single-word reads and writes. There is no read-modify-write instruction, on either side, and the processor architectures need not be the same. (Yes, such a technique exists.)
John R. Strohm
2010-01-03 12:20:54
+1
A:
I wouldn't ask too specific/detailed questions. But the above mentioned book 'Concurrency in practice' is a good helper. Just go there chapter-wise and read out the pin-points, e.g.:
- Explain difference between mutable/immutable
- What does it mean to share data in concurrency setup
- What problems do you solve with concurrency
- etc.
manuel aldana
2010-01-03 13:36:50