Всем привет!

Я Борис и я Unity tech дед (ну, или tech lead 😉)

Ну что ж, ребятки, усаживайтесь поудобнее — расскажу вам сказочку про умного и хитрого разработчика по имени Борис. Давным-давно, в далеком 2012 году, когда компьютеры были большими, а игры — еще больше, жил-был в Москве молодой парень Борис. И вот однажды открыл он для себя волшебный мир Unity, и с тех пор его жизнь изменилась навсегда.

Учился Борис много, внучата, не жалел ни времени, ни сил. Сначала овладел он мудростью программирования в МГТУ им. Н. Э. Баумана, а потом отправился за еще большей наукой — изучать e-commerce в Высшей школе экономики. И стал он не просто программистом, а настоящим волшебником Unity!

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

Но и это не конец его истории. Однажды Борис открыл двери в волшебную компанию DataSakura. Поработал он там некоторое время, отрастил бороду и стал дедом. И стали к нему приходить внучата за советами разными: «Дедушка Борис, а сколько времени нужно, чтобы сделать этот проект? А как лучше построить архитектуру?» И так дедушка Борис стал вести команду молодых мастеров, обучая их мудрости кода и заботясь, чтобы проекты работали гладко, быстро и без сбоев. Даже когда появлялись сложные задачи, Борис всегда находил решение и вел свою команду вперед!

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

Вот так и стал дед Борис настоящим волшебником программирования!


А теперь серьезно:

Я, конечно, не дед — мне 30 лет, но в Unity и геймдеве я уже давно. В 2012 году я впервые познакомился с Unity, а в 2014 устроился на свою первую работу в этой сфере

За 12 лет я создал сотни проектов и участвовал в ещё большем их числе. Только за последний год я так или иначе был задействован более чем в 20 проектах. Вот некоторые из них:
1. EvoPop (Android, IOS)
2. PPNards (Android, IOS)

Также я занимаюсь разработкой собственных игр, которые можно найти в Google Play

О чём я тут пишу:
1. О взгляде на разработку игр и геймдев с точки зрения бизнеса и менеджмента.
2. О технических советах по разработке в Unity.
3. О своих проектах и историях — в том числе, как я стал «дедом».

Как эффективно проходить собеседования? Часть 1. Введение

За три года в роли лида я просмотрел более 500 кандидатов на позиции мидла и сеньора, провел свыше 100 собеседований и нанял более 20 Unity-разработчиков. За это время у меня накопился значительный опыт в оценке кандидатов — я заметил множество «зеленых» и «красных» флагов, которые помогают определить подходящих людей

В этом посте я кратко расскажу о нетехнической стороне прохождения собеседований:

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

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

Около 20% кандидатов приукрашивают резюме, и хотя это часто выявляется в ходе собеседования, иногда ошибки обнаруживаются только после найма, когда кандидат не проходит испытательный срок. Пример из практики: один кандидат успешно прошел все этапы, и ушел с текущего места работы к нам, но через пару недель на работе стало понятно, что у него нет заявленного опыта. Это обернулось потерей времени и денег для компании и проблемами для кандидата, он остался без работы. Итог: никто не остался в выигрыше.


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

1. Отправка резюме
2. Интервью с HR
3. Code Review / тестовое задание
4. Технические собеседования
5. Интервью с тимлидом

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


Первые шаги: отправка резюме

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

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


Интервью с HR
Этот этап — знакомство компании с вами и наоборот. Основные причины, по которым HR может отклонить вас:

Объективное несоответствие вакансии (например, опыт на Python, когда требуется Unity).
Недостаточный уровень английского. У нас, например, для сеньоров требуется уровень B2.
Неуместные soft skills — например, односложные ответы или использование грубых выражений.


А в следующей части я расскажу вам про code review

💡Как пройти Code Review? Советы 1–5

Как эффективно проходить собеседования? Часть 2

Как понять уровень hard skills кандидата?
Первый этап технического интервью — это проверка кода

💻 Code Review: взгляд изнутри
Когда я провожу ревью:

* На один проект уходит около 30 минут
* За день просматриваю до 10 кандидатов
* Оцениваю по трем критериям: код-стиль, архитектура, complexity (сложность кода)
* 95% проектов я не открываю в Unity
* Если отказ, то всегда даю обратную связь


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

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

* Потеря времени. Ревьюеру нужно потратить 5 минут из отведённых 30, чтобы скачать и разархивировать проект
* Проблемы с доступом. Часто архивы защищены, и ревьюеру приходится запрашивать доступ
* Вопросы к навыкам. А умеете ли вы вообще пользоваться Git?


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

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


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

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

Что включить:
* Краткое описание проекта
* Архитектуру и структуру
* Особенности, которые вы хотите подчеркнуть
* Гифку с примером геймплея
* Ссылку на сборку (опционально)


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

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

Почему ссылка на Git профиль это плохо
* Чаще всего я выбираю самый последний проект, но он может быть слабым
* Если первые 2 проекта сложные или не подходят под критерии я запрашиваю тестовое
* Косвено, по названиям, других проектах я ищу ваши слабости, что бы за них зацепиться


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

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

* Zenject (Extenject)
* VContainer
* UniRx (R3)
* UniTask

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

Следующие советы — в следующем посте! 🚀

Какой из советов вы уже применяете? Делитесь опытом в комментариях! 👇

💡Как пройти Code Review? Советы 6–10

Как эффективно проходить собеседования? Часть 2

✏️ Совет 6: Соблюдайте код-стиль
Покажите, что умеете писать чистый код. Я рекомендую:

* Код-конвенции Microsoft
* Гайд Unity: Code Style Tips
* Если работаете в Rider, настройте подсказки Code Style для упрощения работы

🏗️ Совет 7: Архитектура имеет значение
Покажите своё мастерство! 😎

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

🔍 Совет 8: Упрощайте complexity
Чем проще понять код, тем лучше:

Подробнее про complexity: здесь
Также есть книжка Роберта Мартина "Чистый код"

✂️ Совет 9: Не переусердствуйте с комментариями
Код должен быть понятным без комментариев.

Советы:
* Не используйте summary. Они уместны в публичных методах в библиотеках
* Разбейте сложные части на методы или классы.
* Используйте понятные названия перменных и методов

💪 Совет 10: Не расстраивайтесь при отказе
Отказ — это шанс для роста! 📚

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


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

Был ли какой-то совет для вас полезен? Делитесь в комментариях! 👇

💡 Как пройти техническое собеседование?
Как эффективно проходить собеседования? Часть 3

Техническое собеседование – это момент истины. Его цель – понять, хватит ли ваших навыков для проекта. Как подготовиться и пройти его максимально успешно?

Предыстория
Я работаю лидом в компании Datasakura, которая уже более 5 лет занимается игровым аутсорсингом и аутстаффингом. За это время я разработал авторскую методологию оценки кандидатов, которая показывает отличные результаты: 90% нанятых сотрудников соответствуют оценкам, данным на собеседовании. В этом посте я коротко коснусь этой методологии, а в будущем сделаю отдельный разбор всех её деталей.

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

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

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

Unity 3D/2D
Physics
UI
Shaders
Оптимизация
Архитектура
C#
Assets/SDK
Network

💡 Важно: если вы активно помогаете интервьюеру разобраться в ваших знаниях, это большой плюс!

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


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

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

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

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

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

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

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

💬 Делитесь своими впечатлениями от собеседований в комментариях! А в следующем посте я подробно расскажу о том как проходить live coding интервью.

📌 Подписывайтесь на канал, чтобы не пропустить новые советы!