Log of Alprog

Как я проводил собесы?
#light

Что ж, давайте я вам расскажу, как я проводил собесы, когда был большой начальник в маленькой студии. Речь про Dark Crystal Games, где я был лид-кодер и ещё формально технический директор. Напомню, что там мы писали тактическую РПГ Encased на Unity.

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

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

Он же сам проводил второй этап, который представлял из себя что-то среднее между первичным скринингом и культурным интервью. Надо сказать, что как любая восточноевропейская студия, мы не особо много внимания уделяли софт-скилам. Вся софтскилловая часть у нас по сути сводилась к ответу самим себе на вопрос: «хочется работать совместно с этим кренделем, или ну его нафиг?». Ну ещё, конечно, любовь к Fallout и релевантным играм давала бонус. Но на этом всё. Я не говорю, что это супер правильно — на западе, например, софтскиллы даже важнее хардов — но рассказываю, как есть.

Далее у нас было два технических этапа: техническое интервью и тестовое задание. Тут уже подключался я. Кому-то мы давали оба этапа; но кому-то только одно, если видно, что кандидат годный и нет смысла гонять дополнительно. Иногда мы начинали с интервью, иногда — с тестового. Строгой формулы, как мы это решали, не было: руководствовались по ситуации. Например, если в портфолио дофига примеров кода, то тестовое не просили. А если чувак с явно хорошей теоретической базой, но мало опыта в геймдеве, то такого посылали сперва на тестовое.

Тестовое я придумал в самом начале проекта и мы его использовали до самого конца. Нужно было сделать 3D-леталку на самолётике от третьего лица. Требовалось реализовать только управление (повороты, ускорение), выпускаемые ракеты, врагов-мишени и интерфейс в виде индикаторов расстояния до них. Разрешалось делать на кубиках или бесплатных ассетах, красота не оценивалась. Я когда-то писал такое на хакатоне, поэтому к тестовому прилагалось видео, как это может выглядеть.

Изначально я написал, что задача рассчитана на 3 вечера (из расчёта 6-9 часов), но на деле большинство кандидатов делали за 2-3 часа. В поздних версиях мы также начали делать приписку, что нельзя использовать юнити-корутины и ригидбоди, чтобы кандидаты хотя бы реализовали работу с DeltaTime и проверками расстояния, а то совсем порой оценивать было нечего.

Оценивали мы наличие кодстайла и здравого смысла. То есть достаточно было не натворить какой-то лютой дичи, чтобы пройти. Под дичью я имею в виду магические константы, нейминг транслитом, баги и тому подобное. Оценивали мы толпой прямо в канале code в слаке. Делали это в домашней атмосфере, не снимая токсичные тапки. Что тоже не очень профессионально, потому что любопытные сотрудники могли проскролить чат достаточно далеко и почитать не всегда супер-политкорректные формулировки. Благо, это могли видеть только прошедшие кандидаты.

Наконец последний этап (который обычно был до тестового) — это техническое интервью. Я неоднократно упоминал статью «интервью глазами пострадавшего», как свой ориентир по собеседованиям. Собственно, я им и руководствовался, но занизил планочку, как мог, под современные реалии.

www.tgoop.com/logofalprog/205

1.6K viewsDec 8, 2022 at 00:43

Как я проводил собесы?
#light

Что ж, давайте я вам расскажу, как я проводил собесы, когда был большой начальник в маленькой студии. Речь про Dark Crystal Games, где я был лид-кодер и ещё формально технический директор. Напомню, что там мы писали тактическую РПГ Encased на Unity.

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

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

Он же сам проводил второй этап, который представлял из себя что-то среднее между первичным скринингом и культурным интервью. Надо сказать, что как любая восточноевропейская студия, мы не особо много внимания уделяли софт-скилам. Вся софтскилловая часть у нас по сути сводилась к ответу самим себе на вопрос: «хочется работать совместно с этим кренделем, или ну его нафиг?». Ну ещё, конечно, любовь к Fallout и релевантным играм давала бонус. Но на этом всё. Я не говорю, что это супер правильно — на западе, например, софтскиллы даже важнее хардов — но рассказываю, как есть.

Далее у нас было два технических этапа: техническое интервью и тестовое задание. Тут уже подключался я. Кому-то мы давали оба этапа; но кому-то только одно, если видно, что кандидат годный и нет смысла гонять дополнительно. Иногда мы начинали с интервью, иногда — с тестового. Строгой формулы, как мы это решали, не было: руководствовались по ситуации. Например, если в портфолио дофига примеров кода, то тестовое не просили. А если чувак с явно хорошей теоретической базой, но мало опыта в геймдеве, то такого посылали сперва на тестовое.

Тестовое я придумал в самом начале проекта и мы его использовали до самого конца. Нужно было сделать 3D-леталку на самолётике от третьего лица. Требовалось реализовать только управление (повороты, ускорение), выпускаемые ракеты, врагов-мишени и интерфейс в виде индикаторов расстояния до них. Разрешалось делать на кубиках или бесплатных ассетах, красота не оценивалась. Я когда-то писал такое на хакатоне, поэтому к тестовому прилагалось видео, как это может выглядеть.

Изначально я написал, что задача рассчитана на 3 вечера (из расчёта 6-9 часов), но на деле большинство кандидатов делали за 2-3 часа. В поздних версиях мы также начали делать приписку, что нельзя использовать юнити-корутины и ригидбоди, чтобы кандидаты хотя бы реализовали работу с DeltaTime и проверками расстояния, а то совсем порой оценивать было нечего.

Оценивали мы наличие кодстайла и здравого смысла. То есть достаточно было не натворить какой-то лютой дичи, чтобы пройти. Под дичью я имею в виду магические константы, нейминг транслитом, баги и тому подобное. Оценивали мы толпой прямо в канале code в слаке. Делали это в домашней атмосфере, не снимая токсичные тапки. Что тоже не очень профессионально, потому что любопытные сотрудники могли проскролить чат достаточно далеко и почитать не всегда супер-политкорректные формулировки. Благо, это могли видеть только прошедшие кандидаты.

Наконец последний этап (который обычно был до тестового) — это техническое интервью. Я неоднократно упоминал статью «интервью глазами пострадавшего», как свой ориентир по собеседованиям. Собственно, я им и руководствовался, но занизил планочку, как мог, под современные реалии.

BY Log of Alprog