Нужны ли Unity разработчику проекты на гитхабе

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

в первый раз сеньор из 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 самых, на мой взгляд, интересных!