Как проходит типичное техническое собеседование Unity-разработчика

Привет! За свою карьеру я прошёл более 15 собеседований, и сейчас расскажу про наиболее частую структуру.

1. Самопрезентация

После короткого смолтока вас попросят рассказать о себе.
Это не просто формальность - по вашему рассказу формируется первое впечатление.

Расскажите:
• над какими проектами работали
• за что отвечали
• какие задачи решали и чем гордитесь

Совет: запишите рассказ на аудио и послушайте. Поймёт ли человек, который впервые вас видит, чем вы занимались и в чём ваша ценность? Можно отправить запись другу для проверки.

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

2. Технический блок

Здесь проверяют ваши знания по C# и Unity. Список тем зависит от компании, но чаще всего спрашивают:

1. Устройство памяти в C#. Отличия поведения ссылочных и значимых типов.
2. Garbage Collector - что это такое, как работает.
3. Отличия классов и структур. Ограничения структур. Boxing & Unboxing.
4. Коллекции и алгоритмы. Как "под капотом" работают стандартные коллекции, оценка сложности (Big O) операций с этими коллекциями (добавление, удаление, обращение). Могут затронуть популярные алгоритмы сортировки и обхода графа.
5. Асинхронность и многопоточность в C#
6. Блок Unity. Спрашивают что-то из перечисленного: Addressables / Оптимизации / Шейдеры и графический пайплайн / Сборка билда / Клиент-серверное взаимодействие / Unit тесты / Полезный стек - UniTask, Zenject, R3

Подсказка: читайте описание вакансии - по нему можно понять, на чём будет акцент.

3. Вопросы по процессам

В этом блоке собеседующие проверят ваши софт скиллы, используя вопросы о вашем поведении в команде.

Примеры вопросов:
• Как проводите code review?
• Как оцениваете время на выполнение задач?
• Что делаете, если ТЗ неполное?
• Как решаете конфликты?
• Что вас мотивирует в работе?
• Что делаете, если не успеваете в дедлайн?

4. Live-coding

Редкая практика, но бывает - примерно в 1 из 5 собеседований.
Вам дают задачу, вы демонстрируете экран и решаете её в реальном времени.

Примеры задач:
• Алгоритм нахождения матчей на match-3 поле;
• Обход графа;
• Проектирование - например, реализовать инвентарь или отревьюить код.

5. Ваши вопросы

Возможно, это будет неожиданностью - но по этому блоку вас продолжают оценивать.

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

Хорошие вопросы:
• Как проходит онбординг новых сотрудников?
• Как часто проводятся performance review и что учитывается?
• Какие направления развития у компании сейчас в приоритете?
• Есть ли менторство или обмен опытом внутри команды?
• Есть ли единые стандарты кодстайла и архитектуры?
• Как работаете с техдолгом - планово или “по ходу”?
• Используете ли собственные фреймворки / пайплайны?
• По каким метрикам оцениваете успех проекта - доход, удержание, отзывы игроков?
• Какие ближайшие планы на развитие проекта?

🚀 Пост Guru Unity: @Minerope

MV* паттерны в Unity: разложим по полочкам

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

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

Принцип, из которого выросли все MV*

Любой UI или игровой экран можно разложить на три слоя:

1. Бизнес-логика (Model) - хранит и обрабатывает данные.
Пример: здоровье персонажа, инвентарь, внутренняя экономика.

2. Презентация (View) - показывает игроку информацию.
Пример: полоска HP, надписи, окна, анимации.

3. Связующее звено (Controller / Presenter / ViewModel) - решает, когда и что обновить.

Главная идея MV* - разные причины для изменений должны быть в разных местах.

Так, если мы поменяем бизнес-логику, то не придётся изменять код UI.
И наоборот - сменили виджет отображения UI (с текстового поля со значением процентов на полоску здоровья с конкретными значениями) - вся игровая логика здоровья осталась нетронутой.

Пример без разделения:

public class Health : MonoBehaviour
{
    [SerializeField] private TMP_Text _text;
    [SerializeField] private Image _bar;

    private float _hp = 100;

    public void TakeDamage(float dmg)
    {
        _hp -= dmg;
        _text.SetText($"{_hp}");
        _bar.fillAmount = _hp / 100;
    }
}

Пока одна панель - всё ок.
Но потом приходит геймдизайнер и говорит:

“Добавь полоску над персонажем и окно статистики.”

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

Чтобы избежать постоянного переписывания UI кода, необходимо создать:

1. HealthModel, в которой будет находиться бизнес-логика
2. HealthView, который будет заниматься отображением (UI)
3. HealthPresenter, который связывает Model и View. Например, просто слушает события из Model и вызывает методы по обновлению View

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

Посмотреть изменённый код можно тут

Смысл, который стоит запомнить

MV* - паттерн не ради паттерна.
Он необходим, чтобы изолировать причины изменений и отображение изменений.

И когда завтра геймдизайнер захочет 3 разных шкалы HP, ты просто подключишь новые View — без изменения логики HP и переписывания старого кода View.

🚀 Пост Guru Unity: @Minerope

Структура кадра в Unity и почему это важно

Сегодня разберём благодаря каким операциям мы получаем картинку в юнити, что такое Performance Bottleneck и как эти знания помогут оптимизировать вашу игру.

Что такое кадр и как он формируется

Наверняка, каждый знаком с понятием FPS.
Если игра работает на 60 FPS - это 60 циклов формирования кадра в секунду.

Каждый кадр - это последовательность операций, где участвуют:
• CPU - выполняет код Unity и ваш код, готовит геометрию кадра.
• GPU - получает подготовленные данные и рендерит финальное изображение.

Загвоздка - CPU и GPU не могут работать параллельно

GPU не может начать раскрашивать картинку, геометрия которой ещё не подготовлена от CPU. И наоборот - CPU не может начать работать над следующим кадром, пока GPU не раскрасила прошлый.

Это видно на приложенной схеме - у CPU присутствует блок "Wait", так как GPU ещё занимается прошлым кадром. В это время CPU просто простаивает.

Такая ситуация называется Performance Bottleneck

Performance bottleneck - это компонент (CPU или GPU), который ограничивает FPS. У нас есть "затык" в одном из компонентов.

Неопытный разработчик захочет оптимизировать игру, не разберётся в "затыке" производительности и пойдёт оптимизировать CPU (код или геометрию сцены).
Если bottleneck в GPU - весь эффект оптимизаций будет в увеличении ожидания от CPU.

• Было: CPU — 10 мс работы + 10 мс ожидания GPU.
• Стало: CPU — 8 мс работы + 12 мс ожидания GPU.

CPU стал работать быстрее, но FPS не вырос, потому что настоящая проблема - GPU.
Если оптимизировать не тот компонент, результат будет нулевым.

Зачем это знать

Перед любыми оптимизациями нужно определить:

• упираетесь вы в CPU или в GPU,
• какое именно место внутри них тормозит: логика, физика, UI, рендер, память.

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

В следующих постах от Guru разберём работу с Profiler и научимся определять Performance Bottleneck

🚀 Пост Guru Unity: @Minerope

Как пользоваться Unity Profiler, чтобы реально оптимизировать игру

Привет! Сегодня разбираем инструмент, которого не должен бояться Unity разработчик — Unity Profiler. Если ты всё ещё смотришь на лаги через FPS - этот пост для тебя

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

1. Главное правило профилирования - профилировать на целевом устройстве

В Editor режиме профайлер врёт. Он профайлит сам себя - таким образом попадает лишняя информация.
Если игра на мобильные устройства - собирай проект на мобильное устройство и профилируй там.
Запускай Build на устройство с опцией Development Build и Autoconnect Profiler → Profiler запустится сам → смотри реальную картину.

2. Определяем что тормозит

Вспоминаем прошлый пост - мы не хотим терять время и оптимизировать то, что не нужно.

Переходишь в Profiler → Timeline и смотришь на две строки:

• CPU — пользовательский код, работа движка, события UI, GC
• GPU — рендер, шейдеры, batching, пост-процессинг

Если CPU забит - исправляем тяжёлые функции, GC.
Если GPU забит - смотрим рендеринг - draw calls, overdraw, тяжёлые шейдеры.

3. Разворачиваем стек вызовов

Поставив полоску Timeline'а на любое место - снизу будут выведен весь стек вызова функций в конкретном кадре.
Так, мы можем посмотреть какие из функций были тяжёлыми, и оптимизировать их.

Тут многих ждёт ловушка: профайлер показывает странные функии движка вроде:

• Gfx.WaitForPresent
• WaitForTargetFPS
• WaitForLastPresentation
• Semaphore.WaitForSignal

Это не значит что эти функции надо оптимизировать.

Например, Gfx.WaitForPresent - это момент, когда CPU ждёт GPU.
Что-то вроде: "Графическая подсистема не готова принять следующий кадр - подожди"

И это значит, что твой bottleneck - GPU и оптимизировать надо его.

Описание всех подобных функций можно найти в документации.

4. Используй Deep Profile

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

Минусы - из-за большого количества данных труднее ориентироваться и сильно нагружает устройство. Лагать игра на устройстве в таком режиме будет сильно.

Правило простое - если не получается понять проблему без режима Deep Profile - то включай.

5. Используй маркеры

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

ProfilerMarker marker = new ProfilerMarker("MyMethod");

void Update()
{
    marker.Begin();

    // твой код

    marker.End();
}

Таким образом, в профайлере будет виден вызов "MyMethod" на выделенный маркером промежуток

6. Итог - план оптимизации

Мой порядок действий:

1. Собрать приложение на целевое устройство
2. Развернуть стек вызовов в проблемном месте
3. Определить CPU или GPU bottleneck
4. Отделить системный код от своего
5. Исправить → снова прогнать → сравнить

🚀 Пост Guru Unity: @Minerope