Всем привет!

Я Борис и я 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 интервью.

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

Мой первый Game Jam за 10 лет 🎮

10 лет назад я последний раз участвовал в хакатоне. Тогда мы с командой сделали VR-приложение для детейлинга автомобилей и заняли первое место. Это был невероятный опыт, но с тех пор я полностью углубился в работу, и времени на Game Jam у меня просто не находилось.

Последний год желание вернуться к этому формату не покидало меня. Но то работа, то визовые вопросы мешали воспринимать это всерьёз. И вот на этой неделе звёзды сошлись — я ушёл в отпуск и решил: почему бы не провести его, создавая игры?

🔘 Я выбрал -1 Button Game Jam! Его концепция показалась мне очень интересной: разработать игру, где всё управление происходит через одну кнопку.

Я решил участвовать в одиночку. После большого количества общения на основной работе мне захотелось побыть наедине с идеями и полностью реализовать свой творческий потенциал. И знаете что? Мне это чертовски понравилось!

🌟 За эти несколько дней я понял несколько важных вещей:
1️⃣ Несмотря на то, что я сейчас редко пишу код, я до сих пор отлично помню, как разрабатывать игры, и делаю это очень быстро, что меня радует
2️⃣ Разрабатывать проект полностью самостоятельно — невероятное ощущение, когда ты принимаешь все решения сам.
3️⃣ Теперь я чётко понимаю, на что стоит тратить время, а что является второстепенным. Это позволяет работать эффективнее и не закапываться в детали.

Сегодня я отправил свой проект в релиз! Знакомьтесь, Dome Defence:
👉 https://romanchikov.itch.io/dome-defence

🔥 Как проходила разработка?
На старте нам предложили три темы для Jam:

1. Dome
2. Agreement
3. Bugs

Так как я работал один, бреиншторм с командой был невозможен, поэтому мне помог ChatGPT. Я сразу решил отказаться от очевидных идей вроде экшенов и аркад, потому что 90% игр на таких мероприятиях создаются именно в этом жанре. В итоге у меня осталось несколько основных концепций:
1️⃣ Пазл, где нужно менять цвет объекта нажатием кнопки.
2️⃣ Пазл с механикой изменения гравитации.
3️⃣ Idle-игра или кликер.

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

💻 Вот как прошли четыре дня разработки:

Первый день: генерировал идеи, создал проект, добавил все необходимые ассеты, настроил графику и сделал логику движения врагов.
Второй день: закончил всю основную механику — всю логику врагов, юнитов, базы, прокачки и так далее.
Третий день: занимался балансом волн, добавлением контента, созданием различных типов врагов, прокачки и мелкой полировкой.
Четвёртый день: дал своим друзьям игру на тесты, исправил найденные баги, довёл до ума финальные детали и оформил страницу проекта на itch.io.
На всю разработку ушло около 40–50 часов.

💡 Какие планы дальше?
Победа? 😅 Ну, конечно, было бы приятно, но в этом Game Jam нет призового фонда и наград. Поэтому я хочу адаптировать игру для мобильных платформ, найти издателя и протестировать её на реальном рынке.

Вот так прошли мои игровые каникулы. А вы уже поиграли в Dome defence? Как вам? Делитесь в комментариях! 💬

✅ Live coding — что это и как его пройти?

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

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

Кроме того, такая практика помогает оценить:

* Умение создавать прототипы с нуля
* Скорость и эффективность работы

⚡ Почему мы выбрали live coding

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

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

1. Перед началом интервью мы просим кандидата скачать заранее подготовленный тестовый проект, чтобы не тратить время на настройку.
2. На интервью я трачу 10-15 минут на вводную часть.
3. Затем даю кандидату задание, рассчитанное на 2 часа.

Правила:

1. Можно гуглить и использовать AI.
2. Разрешено использовать и добавлять любые ассеты.
3. Код может быть «грязным» — архитектура и качество не оцениваются.

Критерии оценки:

1. Финальное качество игры. Игра не должна содержать багов, анимации и игровые элементы должны выглядеть «sочно». Мы оцениваем продукт глазами игрока, а не разработчика.
2. Скорость работы. Оценивается, сколько заданий кандидат успевает выполнить и как быстро. Также фиксируем, на что он тратит больше времени.
3. Навыки. Как кандидат пишет код, пользуется ли AI и горячими клавишами, какие плагины редактора применяет, как быстро ориентируется в Unity.

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

1. Низкое качество проекта. Нет анимаций, плавных переходов, игровых «фишек».
2. Чрезмерное использование ChatGPT. Особенно там, где быстрее написать код вручную.
3. Ненужные задачи. Написание «чистого» кода, рефакторинг, уборка проекта.
4. Хаотичность. Переход от одного задания к другому без завершения текущего.

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

🚀 Напишите в комментариях проходили ли вы собеседование в формате live coding и понравлся ли вам такой формат?

Хотел поделиться с вами радостной новостью!
Вышла моя статья на хабре

Прочитать ее можно по ссылке
Как пройти собеседование на Unity-разработчика: мнение лида

Мой дебют на Хабре прошел с максимально "успешно"
Карма понижена до -2, а рейнтинг понижен до -6

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

Я перевел статью в режим черновика и она будет временно не доступна до тех пор, пока я не сделаю работу над ошибками

Отредактировал статью и сделал ее публичной
Как пройти собеседование на Unity-разработчика: мнение лида

Основный контент и смысл остался тот же. Я не менял советы или важные пункты
Что поменял:
* Добавил пояснение и ремарки к некоторым пунктам, которые вызвали вопросы
* Сильно дополнил процесс связанный с Live coding, добавил больше деталей и нюансов. Постарался ответить на вопрос, почему 2 часа это нормально
* Добавил часть P.S. для тех, кто мог не правильно понять мой основный посыл

Пойду ставить свечку за мой рейтинг!

🎮 Что должен уметь разработчик игр?

💬 Ответ: то, что требует от него компания

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

Например, как бы вы ответили на вопрос:
Должен ли Unity-разработчик уметь писать шейдеры?
Свои ответы оставляйте в комментариях, а мы продолжаем 👇


Я работаю лидом в аутсорсинговой и аутстафинговой компании, специализирующейся на разработке игр в Unity. Наши проекты — от прототипов до сложных мультиплеерных игр на этапе liveops. В команде более 10 Unity-разработчиков, и их навыки сильно различаются: кто-то хорош в архитектуре, а кто-то — в создании прототипов.

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


А теперь важный вопрос:
Какими компетенциями должен обладать Unity-разработчик?

Вот расширенный список навыков, которые пригодятся в работе

(50%) означает, что 50% проектов в нашей компании, а также в проектах, которых я принимал участие требовали наличие этого навыка.
Проценты несут ознакомительный характер и отражают мой опыт. Опыт вашей компании будет отличатся. Вы можете менять или объединять пункты исходя из специфики вашей
* - помечены темы, которые мы спрашиваем на собеседовании

🎯 Знание движка Unity* (100%)
Базовые знания Unity: MonoBehaviour, Корутины, отличие Update от FixedUpdate, NavMesh, Animator, Поиск пути, Опыт написание кастомного редактора,

🎯 Unity 3d* (70%)
Что такое Mesh и из чего состоит 3d модель, Оптимизация 3d игр, скелетная анимация

🎯 Unity 2d* (30%)
Понимание Sprite и Sprite Atlas, Скелетная анимация в 2d, В чем основное отличие Unity 2d проектов от Unity 3d

🎯 Physics* (20%)
Теоретическое знание кинематики

🎯 Unity UI* (80%)
Canvas, Layout group, как верстать адаптивный интерфейс, Safe Area
Оптимизация и производительность

🎯 Шейдеры и графика* (5%)
Какие есть пространства в Unity, Shaderlab, Shader graph, Renderer Pipelines, Post Processing, Draw calls

🎯 Оптимизация и профайлинг* (70%)
Big O notation, Profiler, Deep profiling, Frame debugger, Memory profiling, Profiling on device

🎯 Архитектура* (100%)
Паттерны, SOLID, Реактивное программирование, MV* шаблоны, организация данных

🎯 C#* (100%)
Тут много всего. Некоторые темы: ООП, абстрактный класс и интерфейс, атрибуты, Reflection, GC

🎯 Assets* (90%)
Zenject, VContainer, UniRx, Odin, UniTask, Addressables

🎯 Разработка под PC (5%)
Управление джойстиком, Особенности реализации под конкретную платформу (Steam, Epic games)

🎯 Разработка под мобильные платформы* (85%)
Реклама, Аналитика, Конфиги, БД, Пуш уведомления

🎯 Разработка под Web (10%)
Ограничение под WebGL, особенности реализации под конкретную платформу (Yandex игры, Telegram и т. п.)

🎯 AR/VR (0%)
Особенности управление в VR. Asset VRTK, платформа Oculus

🎯 Сетевая разработка* (50%)
Rest API, Сокеты, Мультиплеерные игры, Photon, SaaS

🎯 ECS (0%)
Понимание ECS архитектуры, LeoECS, Morpeh, Entitas, DOTS, другие реализации

Разработка под PC, AR/VR, Web имеют маленький процент, так как большинство наших заказов это мобильные игры
Архитектура имеет 100%, так как она нужна везде, но для прототипов не критична. Кандидат с хорошим знанием архитектуры просто сделает прототип качественнее
ECS имеет 0% так как у нас нет проектов с таким архитектурным подходом

💡 Буду очень признателен, если вы заполните форму (1 мин) о навыках на вашем проекте