Как идентифицировать программиста, хорошего в многопоточном программировании?

Question

Как идентифицировать программиста, хорошего в многопоточном программировании?

Тот последний был довольно хорош. Я просто настроил бы его немного:

my @arr;
my @uniqarr;

foreach my $var ( @arr ){
  if ( ! grep( /$var/, @uniqarr ) ){
     push( @uniqarr, $var );
  }
}

я думаю, что это - вероятно, самый читаемый способ сделать это.

7

multithreading language-agnostic

задан ire_and_curses 4 August 2009 в 09:28

9 ответов

Другие вопросы по тегам:

multithreading language-agnostic

Похожие вопросы:

score 11 · Answer 1

Отведите команду в кофейню, чтобы выпить, убедитесь, что в ней есть только 1 ложка.

Бонус: тот, кто помешивает кофе до того, как другие добавят сахар, проигрывает.

(серьезно, спросите их, и посмотрите, кто знает о членах объектов с общими объектами между двумя потоками и другими общими ресурсами. Спросите их, как предотвратить это, затем спросите их, как заставить ваше приложение MT работать, не устанавливая повсюду блокировки. Спросите их о взаимоблокировках. Если они не знают ответов, значит, у них недостаточно опыта для вас, или им нужно прочитать эту тему и получить хороший анализ дизайна кода, как только они начнут работать).

score 2 · 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)

score 1 · Answer 3

A team would require at least one person who is experienced with this. Especially an architect (if you have this role) should be experienced. To check: normally it is visibile in peoples resume (if external). Otherwise, just ask some open questions. Like : how would you tackle synchronisation betweeen two tasks I'd be interested in : * attitude * process (i.e. it's a good sign if people have some relevant questions) and then you can still throw in a why do you think this is a good solution?

Of course you'd still need someone who can judge the correctness of their answers, as several correct solutions are possible.

score 1 · Answer 4

I'd look for some damn good programamers.

In addition, more important even than that, is to have a team that can think about the architecture of whatever you're working on. In complex systems you've got to have a workable design to start with - you just can't make it up as you go along and hope for the best.

score 1 · Answer 5

Give them a broken multi threaded problem and get them to fix it.

Ask them:

What is transactional memory?
Why do people hate shared state concurrency?
What is a livelock?
What are actors?
Whats the deal with those dining philosophers?
How do you structure complex multithreaded apps?
Why only 1 UI thread?
What is a mutex? What is a semaphore?
Whats a reader writer lock, and why would you use it?
When is it time to create a new thread?
What are green threads, what are fibers?

The tricky thing is to find an expert in the field you will need an expert to start off with.

score 0 · Answer 6

Interesting question... Maybe you could take a real multithreading-related bug from production code and let them fix it. Ideally from a system they'd be working with. Perhaps break it down to the multithreading aspects so they don't have to learn the whole system.

score 0 · Answer 7

Я бы нанял людей, имеющих опыт реализации приложений MT на интересующих вас архитектурах, используя используемые вами языки. Я знаю, что это кажется бессердечным, и что каждый должен где-то начать изучать новую технологию, но я достаточно эгоистичен, чтобы не желать, чтобы они делали это в моих проектах!

score 0 · Answer 8

Ищите функциональных программистов. Часто лучший способ избежать проблем с многопоточностью - это не гарантировать, что они не возникнут, а убедиться, что они не могут произойти: вместо того, чтобы делать побочные эффекты потокобезопасными, не используйте побочные эффекты. Именно это и делает функциональное программирование. Ваши функциональные программисты воплотят эту идею в свой нефункциональный код.

score 0 · Answer 9

Попросите их объяснить концепцию «видимости» в Java. Это настолько сложно, что вы можете исправить это только после серьезного предыдущего воздействия.