Какие концепции параллельного программирования менеджеры по найму ожидают от разработчиков?

Question

Когда я нанимаю разработчиков на общие позиции разработки веб-приложений среднего и старшего уровня, я обычно ожидаю от них понимания основных концепций параллельного программирования, таких как жизнеспособность и безопасность, условия гонки, синхронизация потоков и взаимоблокировки. Я не уверен, стоит ли рассматривать такие темы, как разветвление / объединение, ожидание / уведомление, упорядочение блокировок, основы модели памяти (только основы) и т. Д., Чтобы они были частью того, что должен знать каждый достаточно опытный разработчик, или же это темы это больше для полуспециалистов (то есть разработчиков, которые приняли сознательное решение знать больше, чем средний разработчик о параллельном программировании).

Мне было бы интересно услышать ваши мысли.

Answer 1

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

В дополнение к перечисленным соображениям я бы также рассмотрел последствия для ресурсов и различные издержки использования процессов, потоков и волокон. В некоторых контекстах, например В мобильных устройствах чрезмерная многопоточность может иметь серьезные последствия для производительности. Это может привести к проблемам с переносимостью многопоточного кода.

Полагаю, если бы я брал интервью у кандидата в этой ситуации, я бы работал с реальным примером, а не с более общими темами, которые можно дословно процитировать из учебника. Я говорю это, выполнив немало многопоточной работы сам и вспоминая, как сильно я облажался первые пару раз. Многие могут говорить, разговаривать ...;)

Answer 2

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

Answer 3

Я часто беру интервью у людей на позиции, связанные с параллелизмом, и ищу три общих аспекта:

1. Общее понимание основных понятий, подобных тем, которые вы перечисляете (не зависит от языка)
2. Специфическое понимание библиотек и примитивов параллелизма Java (специфично для работы, которую они будут выполнять)
3. Способность разумным способом разработать решение для параллельной проблемы.

Я считаю № 1 требованием (для моих должностей). Я считаю, что №2 приятно иметь. Если они понимают это и могут описать его в терминах pthreads или какой-либо другой библиотеки, изучать новейшие библиотеки параллелизма Java не составляет особого труда (концепции - сложная часть). И № 3, как правило, отделяет найма от, возможно, найма.

По вашему вопросу, я бы не думал, что fork / join известен почти любому, особенно если кто-то претендует на должность разработчика веб-приложения. Я хотел бы, чтобы разработчики имели опыт работы с некоторыми (но не со всеми) этими темами. Большинство разработчиков, с которыми я беседовал, вообще не использовали библиотеки параллелизма Java 5+, но обычно они могут описывать такие вещи, как гонка данных или тупик.

Answer 4

Реальный вопрос:

Какое значение имеет код, который они будут разрабатывать?

Вы должны знать, какие концепции должна знать должность разработчика, которую вы нанимаете, чтобы иметь возможность работать над проектами, за которые они будут отвечать.

Как и во всем в мире программирования. Дьявол кроется в деталях, и вы не можете знать все. Вы ожидаете, что они будут знать Perl, если вы нанимаете на должность Java?

Кроме того, параллелизм на данном этапе, хотя и хорошо описан в обобщенной теории, сильно зависит от реализации и платформы. Параллелизм в Perl на AIX не является той же игрой, что и параллелизм в приложении C ++ Winforms. У них может быть вся теория в мире под их поясом, но если это требуется для работы, тогда они должны иметь глубокое знание платформы, на которой они, как ожидают, также будут использовать это.