Привет, читатель! Вот уже три года я провожу собеседования на позиции Unity-разработчиков. За это время я просмотрел более 500 кандидатов на позиции мидла и сеньора, провёл свыше 100 интервью и нанял более 20 Unity-разработчиков. Этот опыт помог мне выявить множество "зелёных" и "красных" флагов, которые помогают определить подходящих кандидатов.

Эта статья будет полезна всем Unity-разработчикам — от Junior до Senior, а также лидам, которые проводят собеседования.

Об авторе

Меня зовут Борис, я Tech Lead в компании, занимающейся игровым аутсорсингом и аутстаффингом. Я пришёл в компанию вторым разработчиком и стал лидом, а сейчас у нас 15 разработчиков, и все они прошли собеседование со мной

Я получил техническую базу в МГТУ им. Баумана по направлению "Компьютерные системы и сети" и менеджерскую — в НИУ ВШЭ по направлению "E-commerce". У меня 12 лет опыта работы в Unity, более 200 выпущенных проектов — от прототипов до игр с десятками миллионов скачиваний.

Также я веду блог в Telegram, где делюсь советами для Unity-разработчиков.

Цель собеседования

Основная цель — заключить взаимовыгодное партнёрство между компанией и кандидатом.

Важно понимать: собеседование — это не экзамен, а интервьюеры — не экзаменаторы. Вы нужны компании так же, как компания нужна вам.

Основные ошибки кандидатов

1. Сильное преувеличение опыта. На испытательном сроке может выясниться, что ваши навыки не соответствуют заявленным

2. Отсутствие вопросов о компании. Это создаёт впечатление, что кандидат не заинтересован в сотрудничестве

Пример из практики: один кандидат успешно прошёл все этапы, ушёл с текущего места работы, но через пару недель стало ясно, что у него нет заявленного опыта. В итоге: мы расстались, а он остался без работы. Никто не выиграл.

Этапы собеседования

1. Отправка резюме

2. Интервью с HR

3. Code Review / тестовое задание

4. Техническое интервью / live coding

5. Интервью с тимлидом

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

Резюме (CV)

Рекомендации:

• Сделайте чёткое и профессионально оформленное CV.

• Поддерживайте свой профиль в LinkedIn на высоком уровне.

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

Интервью с HR

На этом этапе HR знакомится с вами, а вы — с компанией.

Причины отказа:

1. Несоответствие вакансии (например, опыт на Python, а требуется Unity).

2. Недостаточный уровень английского (у нас, например, требуется уровень B2 для сеньоров).

3. Неуместные soft skills (например, односложные ответы или грубость).

Code review / тестовое задание

Этот этап — первичная оценка ваших hard skills

Когда достаточно готового примера кода, а когда необходимо выполнить тестовое задание?

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

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

Взгляд на code review глазами ревьювера

• На code review одного кандидата я выделяю около 30 минут.

• Провожу code review дважды в неделю и могу просмотреть до 10 кандидатов за день.

• Оцениваю по трём ключевым критериям: код-стиль, архитектура, complexity (сложность кода).

• 95% проектов я даже не открываю в Unity.

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

А теперь несколько советов, как правильно проходить code review

Совет 1: Присылайте ссылку на GitLab или GitHub

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

• Потеря времени. Ревьюеру нужно потратить 5 минут из отведённых 30, чтобы скачать и разархивировать проект.

• Проблемы с доступом. Часто архивы защищены, и ревьюеру приходится запрашивать доступ.

• Вопросы к навыкам. А умеете ли вы вообще пользоваться Git?

Создать репозиторий и залить проект в Google Drive, занимает одинаковое время, а неудобств значительно меньше

Совет 2: Присылайте готовый проект, а не набор скриптов

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

И вот почему это важно:

• Нельзя оценить структуру проекта.

• Часто нарушены принципы SOLID, а скрипты перегружены ответственностями.

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

Многие кандидаты говорят, что их код под NDA, поэтому присылают 2 скрипта из готового проекта. Если у вас такая же ситуация, потратьте полдня или день и сделайте проект специально для code review. Вы можете выполнить тестовое задание для компании, а затем использовать этот проект как пример своего кода.

Совет 3: Оформляйте README

README — это ваша визитная карточка. Только 5% кандидатов его делают.

Что включить:

• Краткое описание проекта

• Архитектуру и структуру

• Особенности, которые вы хотите подчеркнуть

• Гифку с примером геймплея

• Ссылку на сборку (опционально)

Вот ссылка на мой тестовый проект: https://github.com/romanchikovboris/Tower-Defence

Совет 4: Присылайте ссылку на проект, а не на Git профиль

Ссылка на профиль с множеством проектов усложняет ревью.

И вот почему ссылка на Git профиль это плохо:

• Чаще всего я выбираю самый последний проект, но он может быть слабым.

• Если первые 2 проекта сложные или не подходят под критерии, я запрашиваю тестовое.

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

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

Совет 5: Используйте общепринятые фреймворки

Самописные фреймворки — это изобретение велосипеда, в котором ревьюеру ещё нужно разобраться.

Используйте готовые решения:

• Zenject (Extenject)

• VContainer

• UniRx (R3)

• UniTask

Исключение — если вас попросили не использовать сторонние фреймворки. Лучше для таких случаев иметь отдельный проект в репозитории.

Совет 6: Соблюдайте код-стиль

Покажите, что умеете писать чистый код.

Я рекомендую:

• Код-конвенцию Microsoft

• Гайд Unity: Code Style Tips

• Если работаете в Rider, настройте подсказки Code Style для упрощения работы

Совет 7: Архитектура имеет значение

Покажите своё мастерство! ?

Проект можно немного "усложнить", чтобы лучше показать навыки. Иначе зачем это все нужно? Следуйте принципам SOLID, KISS, DRY. Использовать их в реальных проектах — это отдельный холивар, но показать владение ими нужно.

• Не используйте Singleton. Это сразу отказ. Почему? Потому что его знают все, а создать архитектуру без него умеет не каждый.

Совет 8: Упрощайте complexity

Если очень просто, то complexity — это то, насколько ваш код легко прочитать и понять.

Чем проще понять код, тем лучше:

• Подробнее про complexity: здесь

• Также есть книжка Роберта Мартина "Чистый код"

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

Совет 9: Не переусердствуйте с комментариями

Код должен быть понятным без комментариев.

Советы:

• Не используйте summary. Они уместны в публичных методах в библиотеках.

• Разбейте сложные части на методы или классы (уменьшайте code complexity).

• Используйте понятные названия переменных и методов.

Помните, переизбыток комментариев мешает пониманию кода, а не упрощает его.

Совет 10: Не расстраивайтесь при отказе

Отказ — это шанс для роста!

Не расстраивайтесь при отказе: это всегда неприятно, но отказ — не конец, а возможность для роста. Воспринимайте обратную связь конструктивно, работайте над ошибками и возвращайтесь сильнее.

Кстати, вот пример моего тестового проекта: GitHub

Техническое интервью

Техническое интервью – это момент истины. Его цель – понять ваши теоретические знания и навыки.

Об оценке кандидатов

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

• Выделено 10 категорий знаний для Unity разработчика.

• Каждая категория оценивается от 0% до 100%.

• У каждого проекта есть свои “веса” для категории.

• По завершению собеседования рассчитывается взвешенная оценка, на основе которой принимается решение.

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

Я выделяю следующие категории в оценке:

• Unity 3D - как хорошо кандидат владеет UnityEngine в 3D пространстве.

• Unity 2D - как хорошо кандидат владеет UnityEngine в 2D пространстве.

• Physics - как хорошо кандидат владеет физикой в Unity, а также школьные знания кинематики.

• UI - умение верстать окна и их оптимизировать.

• Shaders - умение писать и редактировать шейдеры, преобразование пространств и т. д.

• Оптимизация - инструменты, которые делают код быстрее.

• Архитектура - паттерны, подходы (SOLID, KISS, DRY), особенности создания архитектуры в Unity.

• C# - в целом всё, что касается C#: от upcasting и сборки мусора до IEnumerator.

• Assets/SDK - рекламные, аналитические SDK, пуши, Remote config, Zenject (VContainer), UniTask, UniRx(R3).

• Network - Rect API, сокеты, мультиплеер, SaaS сервисы типа Playfab.

• ECS - умение работать с ECS архитектурой.

Небольшая ремарка

Я специально не привел список вопросов на собеседовании, потому что 80% вопросов, которые я задаю, являются открытыми, например: “Как ты сделаешь архитектуру движения юнитов для мультиплеерной RTS игры?”. На эти вопросы нет правильного ответа, а я оцениваю, как рассуждает кандидат и что знает.

Раньше я очень часто задавал типовые вопросы, например:

• Из чего состоит жизненный цикл MonoBehaviour?

• Как работает Vector3.Lerp()?

Но давайте будем реалистами. Все эти вопросы уже давно есть в интернете, и любой кандидат, который потратит немного времени на подготовку, на эти вопросы ответит легко. А с появлением AI-ассистентов такие вопросы вообще теряют смысл.

Из чего состоит техническое собеседование?

1. Рассказ кандидата о предыдущем опыте работы
   ⏱ 10–15 минут
   Перед собеседованием я уже изучаю CV кандидата, но прошу повторить информацию с фокусом на технические детали. Расскажите о своей роли, инструментах и задачах. Помните: чем больше деталей вы дадите, тем меньше будет технических вопросов.

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

2. Технические вопросы
   ⏱ 40–50 минут
   На этом этапе я оцениваю знания кандидата по ключевым навыкам, описанным выше.

   Совет: Никогда не отвечайте на вопрос: “Я не знаю”. Попробуйте порассуждать и подумать логически. Даже если вы не ответите правильно, то рассуждения принесут вам несколько десятков процентов, а это явно лучше 0.

3. Вопросы кандидата
   ⏱ 5 минут
   Если у вас есть вопросы о работе, задавайте их – это показывает ваш интерес.

6 советов, как успешно пройти техническое интервью

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

2. Подробно отвечайте на вопросы.
   Вы пришли не «сдать экзамен», а показать свои сильные стороны. Не заставляйте вытягивать из вас информацию.

3. Отвечайте по делу.
   Не уходите в сторону от заданного вопроса. Это снижает доверие к вашим знаниям.

4. Не говорите “я не знаю”.
   Если вы не уверены, попробуйте рассуждать. Это лучше, чем просто признать незнание, и добавляет вам баллы.

5. Не используйте шпаргалки.
   «Подсматривание» легко заметить, и это вызовет дополнительные, сложные вопросы. Лучше честно показать свой уровень.

6. Спросите обратную связь.
   Вопрос «Как я себя показал?» может быть полезен, если компания обычно не даёт фидбэк. Это ваш шанс узнать, что подтянуть.

Live coding

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

Мы в компании стали очень часто сталкиваться с тем, что кандидаты, которые хорошо показали себя на собеседованиях, очень плохо справляются с прототипами, делают их медленно и некачественно. Эту проблему мы решили путём введения формата Live coding.

Как проходит live coding у нас?

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

1. Вводная часть
   ⏱ 10–15 минут
   Знакомство и объяснение задания.

2. Задание
   ⏱ 2 часа
   Кандидат пишет код и демонстрирует экран. Мы оцениваем:
   

   • Финальное качество игры.
     Игра не должна содержать багов, анимации и игровые элементы должны выглядеть «сочно». Мы оцениваем продукт глазами игрока, а не разработчика.

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

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

Правила:

• Можно гуглить и использовать AI.

• Разрешено использовать и добавлять любые ассеты.

• Код может быть «грязным» — архитектура и качество не оцениваются.

Красные флаги на собеседовании:

• Низкое качество проекта. Нет анимаций, плавных переходов, игровых «фишек».

• Чрезмерное использование ChatGPT, особенно там, где быстрее написать код вручную.

• Ненужные задачи: написание «чистого» кода, рефакторинг, уборка проекта.

• Хаотичность: переход от одного задания к другому без завершения текущего.

После завершения работы кандидат отправляет архив с проектом любым удобным способом. Затем я снимаю небольшое видео по заранее подготовленному сценарию, готовлю отчёт, где указываю сильные и слабые стороны и оценку от 0 до 100%. Видео с результатом прикладывается к отчёту, ссылка отправляется кандидату.

Заключение

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

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