How to identify a programmer good at multi-threaded programming?

Question

Should there be any preconditions to be fulfilled by a team if the team were to be assigned a task that would involve a good deal of multi-threaded coding?

What would you look for?

Answer 1

Get the team over to the coffee room for drinks, make sure there's only 1 spoon available.

Bonus: whoever stirs their coffee before the others have put sugar in, loses.

---

(seriously, ask them, and see who knows about object members with shared objects between 2 threads, and other shared resources. Ask them how to prevent this, then ask them how to make your MT app perform without putting locks everywhere. Ask them about deadlocks. If they don't know the answers, they're not experienced enough for you, or need to read up on the subject and have good design reviews of the code once they start).

Answer 2

Threading is often so intricate and so implementation specific that I think the only valid way to assess this would be to set them a mock task (in the desired architecture) and "have at it". Something that involves competing readers/writers/workers - and UI if needed.

Of course... you also need to have somebody qualified to assess their efforts...

You could also talk about overall principles, but I'm not sure that covers it. As an example, just yesterday in the C# area there was a lot of confusion about some subtle issues that involved the memory-model, the language spec and the clr spec. You can't assess that type of detail in vague terms; it has to be very specific to the problem.

Equally, the tools / approaches change per framework. OCAML / F# etc has very different threading code to Java/C# - and even that changes per version (see Parallel Extensions/TPL vs things like ReaderWriterLockSlim in 3.5 vs ReaderWriterLock in 2.0)