На моем опыте, о котором можно больше почитать на канале, довольно большое количество собеседующих в той или иной степени заглядывает на гитхаб. Первые просто хотят убедиться, что у вас есть в наличии хоть какой‑то написанный вами (надеюсь) код. Вторые хотят побольше в этот код повникать, чтобы посильнее вас потеребонькать на техническом собеседовании. Уже не знаю для чего… для поднятия собственного эго, может быть. Или может хотят сбить с вас спесь вместе с денежными запросами) Хотя последняя категория собеседующих на моей практике попадалась всего два раза:

• в первый раз сеньор из gaijin полчаса докапывался до «можно тут написать ++i вместо i++, так считаю будет правильнее и на наносекунду быстрее» и прочая чушь про микро оптимизации (мы ведь только этим на работе и занимаемся, правда?)

• во второй раз затирали что в пет‑проекте про ИИ очень «слабо» организован слой работы с UI «ой, а почему у тебя хп бары там не поворачиваются на камеру, ты что не умеешь»

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

В преобладающем большинстве, когда видят мой гитхаб с 60+ репозиториями, решают не погружаться в эту свалку фриланса и полумертвых пет‑проектов. Так что это не для всех, но тоже как вариант))

В остальном достаточно одного небольшого проекта. Ему не надо быть красивым или даже ультра качественно написанным. Но в нем должно быть:

• отсутствие базовых ошибок и косяков, за которые прям зацепиться глаз. Никаких FindObjectOfType и десятков синглтонов, вызываемых из одного класса. Никаких бесполезных комментариев как по коду, так и «для себя на будущее». На самом деле, комментарии — довольно сложная тема, иногда они могут быть и нужны. Если интересно подробнее узнать, где их писать/не писать и как это делать, можно посмотреть у великого Сергея Немчинского. Для наших целей достаточно правила «любой комментарий может быть кодом». Если внутри метода есть сложная часть, которую захотелось прокомментировать, то вынесите ее в отдельный метод с нужным названием. И по аналогии с любым другим комментарием.

• соблюденный кодстайл. Нейминги, отступы, аккуратные небольшие легкочитаемые классы. Ревьюверы — тоже люди (звучит как лозунг для какого‑нибудь митинга), им приятнее будет читать хорошо оформленный код вместо мешанины из кривого нейминга

• только доделанный функционал, никаких костылей и заглушек для «на потом, когда руки дойдут»

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

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

• опыт написания целиком собственного играбельного решения и понимание, что не так уж это и сложно, сильно помогает ментально. Сразу сбрасывается этот губительный майндсет, мол «вот они то настоящие программисты, а я так... только по туториалам умею». И чем эта позиция будет актуальнее на момент собеседований, тем лучше)

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

О чем должен быть такой проект:

• Это должна быть небольшая, законченная игра. Не надо пытаться в одного делать новую GTA или Assassin»s creed. Оно и не получится, да и потенциальный лид, заглянувший в проект, увидит только человека который не может оценить свои силы и берет на себя слишком много.

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

• Скорее всего, ты не дизайнер, но постарайся сделать визуал не сильно всратым) Для UI возьми любой пак с понравившимися тебе спрайтами. Если кор часть в 3д, то также постарайся подобрать модели в одном стиле хотя бы. Поставь хоть какой‑нибудь свет на сцену

• Используй разумное количество популярных фреймворков. Затащи в проект DI (Zenject или VContainer), при необходимости, добавь UniRx. Для процедурных анимаций добавь в проект щепотку DoTween»а

• Знай и понимай каждое принятое на проекте решения. Чтобы на условный вопрос «а почему используешь MVP, а не MVVM» было хорошее объяснение вместо «ну мне показалось так лучше будет/ну он вроде проще/ну я за UniRx не шарю»

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

У себя на вместе с выходом этой статьи объявлю небольшой конкурс. Кидайте в комментарии сюда, а лучше к посту, анонсирующему эту статью на моем канале, свои пет‑проекты или тестовые. В зависимости от их количества и качества я в прямом эфире посмотрю 3–5 самых, на мой взгляд, интересных!