• IT-компании

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

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

1. Отвечая на общие вопросы помните, что интервьюер может ничего не знать о том, о чем вы говорите .
Бывает, что в самом начале интервью интервьюер задает общие вопросы - например «Расскажите о проекте Х, над котором вы работали в У» (список проектов берется из резюме) или «Расскажите про самую любимую технологию» или еще что-нибудь такое. Отвечая на этот вопрос очень важно помнить, что вы рассказываете о проекте не себе, а интервьюеру - и ваша задача, чтобы интервьюер вас понял.
Не надо предполагать, что интервьюер очень умный и все знает - он, вероятно, действительно умный, но точно знает далеко не все. И то, что для вас может быть очевидным потому, что вы этим занимались пару лет кряду, для интервьюера может быть совершенно новой областью. И поэтому не стесняйтесь начать с самых основ и время от времени интересуйтесь, понимает ли вас интервьюер.

2. Не гуглите во время интервью.
Бывает такое, что интервьюер задает вопрос, ответ на который вы смутно помните, и если бы только одним глазком взглянуть в википедию… Так вот - не надо этого делать. Стук клавиш обычно довольно неплохо слышен через телефон и ответ, который зачитывается из википедии без особого понимания - тоже довольно несложно отличить. Стоит ли говорить, какое впечатление оставляет у интервьюера такой кандидат?

3. Не врите в резюме.
Есть вещи, которые проверить относительно легко - знание какой-то технологии, например. И вещи, которые проверить сложно - например, если кандидат написал, что он в top 100 на topcoder (это такой сайт, где проводятся соревнования по программированию). Лично я этого на уровне «А под каким ником вы там числитесь?» никогда не проверяю, но от кандидата, который в top 100 на топкодере я жду, что простые вещи он напишет не приходя в сознание (я уже интервьюировала олимпиадников - и по моему опыту так и происходит). И если вдруг окажется, что кандидат пишет код медленно, с кучей ошибок - то это, скорее всего, значит, что либо он очень плохо себя чувствует, либо в резюме он указал неверную информацию.
Конечно, в компетенцию интервьюера не входит оценивать состояние кандидата, но я обязательно упомяну об этом несоответствии в своем отзыве.

4. Не пытайтесь «уболтать» интервьюера.
Если интервьюер задал вопрос - например, «Какая сложность у сортировки пузырьком?» - а вы не помните, то ли это O(N^2), то ли O(N), то ли O(NlogN), то ни в коем случае не надо маскировать свое незнание под кучей фраз, которые вы надеетесь что интервьюер примет за правильный ответ. Интервьюер очень внимательно вас слушает и замечает все попытки невзначай увести его от вопроса, на который кандидат не знает ответа. Лучше просто признаться, что вы точно не помните и подумать вслух - скорее всего вы придете к правильному ответу и так.

5. Говорите и объясняйте. Но не слишком много.
Бывают две крайности - кандидат, который молчит и почти ничего не говорит и даже на вопрос вроде «Расскажите мне, что вы думаете о Х, какие у Х достоинства и недостатки» умудряется ответить максимум одним предложением. И кандидат, который говорит и объясняет все вплоть до последней запятой - «Вот тут я ставлю запятую, потому, что таков синтаксис языка». И первый, и второй тип кандидатов очень сложно интервьюировать - из одних приходится тянуть ответы клещами, а других постоянно обрывать на полуслове.
Объяснений должно быть в самый раз - чтобы интервьюер понял суть, но при этом не чувствовал, что кандидат постоянно хочет сорваться в объяснение тривиальных основ.

6. Тестируйте код сами.
Во время интервью вы написали какой-то код, который по вашему мнению правильный. В этот момент важно этот код протестировать не дожидаясь, пока интервьюер вам скажет «А теперь давайте протестируем код на простом примере 123». Во время тестирования очень важно проверить так называемые corner cases - например, null, пустые строки и массивы, отрицательные числа, ноль - и еще более важно удостовериться, что код действительно работает на простых примерах. Потому что кандидат, который тестирует код, но при этом во время тестирования не замечает очень грубую ошибку, обычно не производит самого лучшего впечатления.

7. Не пытайтесь угодить интервьюеру.
В фильме «Bad teacher» есть один момент - один из главных героев спрашивает другого об акулах:
1: Что вы думаете об акулах?
2: О, акулы это такие ужасные рыбы, я слышал что они едят людей…
1: Но некоторые из них никого не едят, и очень даже милые…
2: О да, это ужасно, что люди истребляют акул, ведь акулы - это вымирающий вид и Бог создал их такими. Они - прекрасные создания…
1: Но ведь они едят людей…
2: Да, да, это ужасно, целые семьи бывают разрушены из-за акул…

Я не помню точно, но суть примерно такая. Так вот, не надо вести «разговор об акулах» с интервьюером. Интервьюер задает вопрос, чтобы узнать, что кандидат думает о том или ином аспекте, а не чтобы услышать, что кандидат с ним в любом случае согласен.

8. Постарайтесь убрать все, что будет мешать вам четко говорить.
Это может показаться очевидным, но я все-таки упомяну - не надо жевать жевачку во время интервью. И кушать тоже не надо. Если у вас есть пирсинг в языке, который имеет обыкновение издавать цокающий звук когда вы говорите, то на время интервью его тоже лучше достать.

Ну и самое главное - вопрос, который интервьюер себе сознательно или подсознательно задает это «Хотел бы я работать в одной команде с этим человеком?». И ответ на этот вопрос складывается не только из знаний и умений кандидата, но и из способности ясно и четко излагать свои мысли, способности слушать и еще многих других мелочей.

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

Диалог из жизни:

Кандидат: Мы должны выполнять операцию «А» до тех пор, пока не выполнится условие «Б».
Я: Отличный план. Давай его реализуем.

Кандидат пишет цикл в стиле for each. Хотя очевидно . Если кандидат прошел этот уровень, он рано или поздно станет хорошим программистом. Но 70% соискателей отваливаются здесь.

Богдан Гусев, СТО

Исправим это досадное неразумение.

while (bool offer == false){

Правило 0

Если вы собеседуетесь на роль java-девелопера, необходимо хорошо знать java и смежные технологии

//Без комментариев.

Правило 1

Подготовьтесь к собеседованию заранее

Заранее выясните у рекрутера все возможные подробности о проекте.

Поищите в гугле вопросы, которые обычно задаются на собеседованиях. Что-то из них точно попадется.

Александр Питц, Project Manager

Правило 2

Не врите в резюме

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

Резюме, наполненное ключевыми словами, о которых вы не имеете должного представления, перечеркивает ваши шансы получить оффер.

Правило 3

Соотнесите свои ценности с ценностями компании

Каждая компания имеет свои ценности. Один коллектив ценит dedication и нацеленность на результат, и как следствие, не брезгует сверхурочной работой. Другой - новшества в работе, и готов изучать и применять инновации каждые пару месяцев. Третий - надежность и стабильность: проверенные технологии, преданных людей, которые не оставят компанию, если вдруг пропадут печеньки.

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

Правило 4

Развивайте коммуникационные навыки

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

Правило 5

Совершенствуйте свой английский

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

Немного мотивации: уровень английского и зарплата у киевских Java и.NET мидлов и сеньоров с опытом 3-5 лет соотносится .

Правило 6

Покажите увлеченность своей профессией

По мнению Богдана Гусева, о том, что вы получаете удовольствие от своей деятельности, может говорить наличие Open Source проектов, участие в тематических конференциях, владение фишками текстового редактора или IDE. И, конечно, интерес к деталям дальнейшей работы. Программисты, которые относятся к своему делу равнодушно, не пользуются высоким спросом у работодателей.

Правило 7

Покажите интеллект и абстрактное мышление

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

Если позиция плохо определена, то проверяется общая эрудиция и интеллект, а также способность мыслить структурно и находить решения.

Очень важно показать умение пользоваться своими знаниями. Если вы знаете подходы и методы решения задач и умеете добывать недостающую информацию, то справитесь и с полученными задачами.

Правило 8

Демонстрируйте желание получать новые знания

Иногда кандидат говорит: «Я изучил технологию X и хочу работать только с ней. Зачем мне изучать технологию Y, если я знаю X?» Шансы такого кандидата на оффер резко снижаются. Технологии - это всего лишь инструменты. Через какое-то время X станет неактуальной, а вместе с ней - и сам специалист, который владеет только ею.

Максим Ковтун, Solution Architect

Правило 9

Покажите ориентированность на результат

Я оцениваю:
- умение пойти на компромисс со своими «религиозными убеждениями» (например, если того требует релиз, использовать «hot fix», а не подходить к решению фундаментально);
- умение настоять на своем, когда это необходимо;
- и еще важнее - умение держать правильный баланс между двумя пунктами выше.

Андрей Мудрый, Project Manager

Правило 10

Не говорите «не знаю»

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

Если не поняли, о чем речь, задайте уточняющий вопрос.

Если вопрос конкретный, и вы не уверенны в ответе, то стоит признаться в этом и обязательно высказать предположения, опираясь на свой опыт. Объясните ход ваших мыслей. Если вопрос открытый, то в нем нет единого правильного ответа.

Худшим ответом будет молчание или «я не знаю». Надо постараться решить поставленную задачу, как бы глупо ни выглядело ваше решение. Даже самый наивный ответ лучше, чем ничего. Два или три варианта ответа - это вообще замечательно. Приправьте эти ответы соображениями по поводу их применимости и дополнительными вопросами для уточнения задачи - и будет отлично.

Алексей Колупаев, СТО

Правило 11

Не стесняйтесь обучаться даже на собеседовании

Невозможно знать всё. Однажды я работал на проекте, где требовались знания довольно специфического стека технологий и картографии. Как показал опыт, немногие программисты могут перевести классическую запись координат из WGS84 в десятичное представление. В таких случаях хорошим ответом на собеседовании я считаю вопрос: «Можно заглянуть в гугл?»

Артем Полюхович, CTO

Правило 12

Думайте над тем, что говорите в ответ

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

Хорошо, если кандидат пытается «вывести» правильный ответ на вопрос. Не гадает, а применяет имеющийся багаж знаний, а также логику, сообразительность, находчивость и умение быстро принимать решения под давлением. Такое качество очень полезно в условиях гибкого подхода к разработке, когда заказчику требуется быстрое решение проблемы, иногда даже во время онлайн-конференции.

Сергей Чирков, Project Manager

Правило 13

Признавайте допущенные ошибки

Способность анализировать и признавать свои ошибки говорит о том, что вы будете заинтересованы как в собственном профессиональном развитии, так и в результате конкретной работы.

Правило 14

Не портите свою репутацию

Испортить мнение о вас может неосторожный ответ на вопрос «Почему вы ушли с такой-то компании?», неорганизованность, опоздание на собеседование без предупреждения, отказ решить тестовое задание.

Правило 15

Выстраивайте с интервьюером партнерские отношения

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

Алексей Колупаев, СТО

Правило 16

Ведите себя корректно

«Корректно» значит вежливо, уважительно. Надменность, заискивания или лесть по отношению к интервьюеру только испортят впечатления. Юмор тоже уместен не всегда.

Можно выделить несколько провальных стереотипов поведения:

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

Последний легко определяется по следующему диалогу:
Я: Возьмите на собеседование свой ноутбук
Кандидат: А зачем?

После такого диалога сразу видно, что кандидат считает, что главное в работе программиста - это разговоры о крутых технология на кухне. Он не знает, что программировать на знакомой клавиатуре гораздо проще, чем на чужой. Следовательно, проводит за ней мало времени. Интересно, как проходит его рабочий день?"

Богдан Гусев, СТО

Правило 17

Будьте адекватным:)

Адекватность - это достаточно широкое понятие. В первую очередь оно включает реакцию на сложные ситуации. Что делает человек, сталкиваясь с непонятным участком кода, сложным алгоритмом? Как он поведет себя с коллегами, когда ему от них что-нибудь понадобится (или понадобиться им)? Что он делает, если возникает конфликт интересов? А если на него поставят невыполнимую или трудновыполнимую задачу?

Артем Полюхович, CTO

Правило 18

Будьте оптимистом

Позитивный настрой - очень полезное качество. Гораздо приятнее работать с человеком, который умеет замечать положительные моменты в жизни, в работе, во всем.

Правило 19

Feel free

Собеседование - это дискуссия между двумя равными специалистами. Таким образом, скованность - скорее минус, чем плюс. Она помешает вам проявить себя на должном уровне.

Но слишком большая самоуверенность - это тоже минус. Монолог на 20 минут без остановок может послужить поводом для отказа.

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

Правило 20

Если провалили, учитесь на ошибках

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

Александр Кагановский, СТО

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

Для чего мы проводим собеседование? Мы хотим найти кандидата, который бы подходил под наши требования «подходящего» разработчика. Но поскольку мы не можем взять человека и посадить его на три недели за решение наших текущих задач, мы придумываем некую модель, соответствие которой означает, что кандидат нам подходит.

При этом «модели» используются самые разные. В гугле когда-то считали, что человек, который сможет ответить на вопрос: сколько шариков для гольфа влезет в багажник Lexus LS470 является хорошим программистом и сможет успешно решать их задачи. Майкрософт когда-то использовал похожий подход (вспомните «Чтобы сделал мистер Фейнман» Эрика Липперта), а сейчас они садят кандидата за стол и просят его покодить. Очевидно, что эта модель также не совершенна, ведь она не соответствует реальному миру, ведь мы никогда не кодим на работе, когда от этого зависит наша судьба, а наш начальник при этом заглядывает в код через наше левое плечо.

В отечественном аутсорсе применяется несколько иной подход. У нас считается, что если человек хорошо разбирается с некоторой технологией, то он достаточно разумен и талантлив, чтобы решать «замечательные» задачи их корпоративных клиентов.

ПРИМЕЧАНИЕ
Помимо отечественного аутсорса подобные тип собеседований активно используется и в некоторых компаниях в США. Например, в Нью Йорке большинство собеседований очень напоминают киевские;)

Кого мы хотим найти?

Прежде чем решить, как же нам подобрать правильных людей (и отсеять «неправильных») нужно определиться с тем, кого же мы ищем.

Проблема здесь в том, что к отечественному аутсорсу (который составляет существенную часть нашего рынка труда) не применимы те же самые критерии, что и к мировым гигантам, типа МС-а, Фейсбука или Гугла. Главное отличие между этими мирами в том, что аусорсу нужно не столько высочайшее качество, сколько большее количество при вменяемом качестве. И хотя требования к разработчикам в аутсорсе может быть и недотягивают до гугловских, тем не менее они достаточно высокие и наши программисты обычно превосходят в техническом плане многих представителей заказчика.

Так что планка в наши компании несколько ниже, ключевые критерии совпадают: нам нужно найти человека, который умеет думать, решать задачи и доводить дело до конца (кстати, именно умение довести дело до конца Бертран Мейер считает самой полезной чертой разработчика, о чем он поведал в своем недавнем интервью).

ПРИМЕЧАНИЕ
Я тут здорово все упростил, поскольку процесс отбора существенно сложнее. Как минимум нужно учитывать человеческие качества, ведь даже rock star разработчику стоит отказать, если из-за него развалится вся команда.

Техническое собеседование

На рынке существует множество способов определения таланта разработчика: начиная от задач на бредо логику, типа квадратных и круглых люков, заканчивая решением олимпиадных задач на клочке бумаги.

Отечественный аутсорс при отборе уделяют максимальное внимание конкретным техническим навыкам: знаниям языков программирования, технологий и платформ. Можно сколько угодно спорить, насколько коррелируют знания языка C# с умением решать рабочие задачи и насколько этот подход лучше/хуже альтернативных вариантов. Как по мне, значительно важнее не то, какие вопросы вы задаете и какие знания проверяете, а то, как вы слушаете ответы и каким образом их анализируете.

Не зависимо от задаваемых вопросов и типе технического собеседования, есть ряд простых советов, которым разумно следовать.

Узнайте, как человек думает

Капитан подсказывает, что наиболее эффективными являются не те вопросы, на которые кандидат знает ответ, а вопросы, ответ на который заранее не известен . На практике мы довольно часто решаем задачи, с которыми не сталкивались ранее, поэтому важно понять ход мыслей и рассуждения кандидата при ответе на вопрос, ответ на который ему заранее не известен.

Например, вполне нормальным попросить реализовать StringBuilder самостоятельно или спросить о том, как он реализован в.NET. При этом значительно интереснее обсуждать этот вопрос, когда кандидат не знает решения. Тут можно затронуть компромиссы между эффективностью реализации методов Append и ToString , подумать о выборе структуры данных и т.п..

СОВЕТ
Очень полезно обсуждать задачи, суть которых хорошо известна кандидату, но которые он не решал на практике. Это немного выведет кандидата из зоны комфорта и будет показывать не его способность запоминать факты, а его способность думать и принимать решения.

Никаких вопросов из "тестов"

Из первого совета вытекает второй совет о том, чего делать никогда не нужно. Не нужно задавать вопросы, ответы на которые легко гуглятся, и главное, нельзя трактовать ответы по принципу тестов: "ответил/не ответил", без продолжения обсуждения.

Меня всегда очень беспокоит, когда на собеседовании задается вопрос следующего вида: "Скажите, а какой тип возвращаемого значения должен быть у перегруженного оператора = в С++? Ссылка или константная ссылка?". Особенно печально, когда ответ на этот вопрос просто записывается на бумажке и интервьюер переходит к следующему подобному вопросу.

На самом деле, сам вопрос не так и плох, но тут важно понять, почему кандидат выбирает тот или иной вариант, и как изменяется его мнение в зависимости от дополнительных наводящих вопросов. Здесь легко можно подтолкнуть к определенной ситуации, с которой кандидат не сталкивался, что, опять-таки, покажет его способность анализа и выбора подходящего решения.

Сосредоточьтесь на фундаментальных вещах

Есть некоторые позиции, которые требуют очень глубокой экспертизы в определенной области. Бывает, что команде нужен эксперт по WCF, WPF или ASP.NET, который должен знать технологию очень глубоко и тогда на собеседовании придется гонять кандидата по всем дебрям. Во всех других случаях значительно полезнее сосредоточиться на фундаментальных вопросах, даже если они и привязаны к конкретной технологии.

Обычно под фундаментальными вещами я понимаю ключевые концепции: основы типов в.NET, основы сборки мусора и проблемы управления ресурсами; основы языка C# типа делегатов, событий, замыканий. Фундаментальные вещи из области проектирования, типа cohesion & coupling, проблемы наследования/агрегации, опасностей изменяемости и т.п; паттерны проектирования, отношение к ним и их роль в арсенале разработчика. Основы алгоритмов, можно в привязке к платформе ("Что будет если метод GetHashCode будет всегда возвращать 42?") и т.п.

Даже в контексте конкретной технологии можно найти достаточно общие вопросы, и не мучить мелкими частностями. Нам важно определить кругозор и фундамент, а не проверить, какая у человека память.

Определите свой уровень по шкале от 1 до 10

Я уже несколько лет пользуюсь подходом, подсмотренным когда-то у Эрика Липперта и в качестве первого вопроса собеседования задаю следующий: "Определите, пожалуйста свой уровень знания языка C# по шкале от 1 до 10, где 1 – это уровень моей мамы, преподавателя математики, а 10 – уровень автора языка C# – Андерса Хейлсберга.".

Это довольно распространенный вопрос, но для меня он не самодостаточен (хотя бывает любопытно услышать от синьера, что его уровень ниже 6 или выше 8). После этого вопроса я всегда задаю второй: "Ок, ваш уровень 8, а какие именно знания перевели вас с уровня 7 на уровень 8?".

Польза такого подхода в том, что можно узнать следующее: (1) чем человек интересуется и интересуется ли чем-то вообще, и (2) можно пропустить ряд простых тем, если кандидат говорит о недавнем изучении каких-то продвинутых вещей. Так, если кандидат говорит, что он узнал о сегментах в GC и Card Table, о реализации обобщений, деревьях выражений, о проблемах изменяемых значимых типах или о генерации IL-кода, то вполне можно пропустить базовые вопросы, типа разницы между ссылочными и значимыми типами и углубиться в более серьезные подробности.

К тому же такой вопрос позволит оценить человеческие качества: насколько кандидат уверен в себе и насколько он адекватно оценивает свои знания, насколько сильно он отстаивает знания в тех областях, в которых он считает себя экспертом и т.п.

ПРИМЕЧАНИЕ
Не так давно на rsdn было обсуждение этого вопроса: "Как вы оцениваете... по 10ти бальной шкале?" , в котором я также принял участие .

Тяните за ниточку

Я очень редко провожу собеседование по бумажке. Обычно происходит следующее: берется несколько ключевых вопросов (таких себе "якорей"), на основе которых строится все обсуждение. Ответ на вопрос n зачастую дает почву для вопроса n+1, который в свою очередь дает почву для следующих вопросов.

Обычно даже невинный вопрос, типа, а зачем нужен интерфейс IDisposable приводик к обсуждению управляемых и неуправляемых ресурсов, Dispose-паттерна, откуда легко перейти к обсуждению стандартов кодирования (поскольку все эти вещи описаны в Framework Design Guideline).

Аналогично, невинный вопрос, типа "А атомарна ли операция i++, где i – это System.Int32?" может послужить хорошим началом разговора, поскольку наверняка даст почву к другим темам, таким как неизменяемость и многопоточность, проблеме гонок, вопросам об атомик операциях и многим другим.

Именно поэтому мне нравится сверх простая задача следующего вида: