Я предлагаю рассматривать GitHub не как портфолио, а как витрину. Витрину, которую стоит чистить. Особенно если вы ищете работу, и особенно, если вы думаете, что она вам в этом помогает.

Безусловно наличие гитхаба в резюме – дополнительный плюс. За последние три года я просмотрел сотни GitHub-аккаунтов кандидатов. И в большинстве случаев это был цифровой мусор. Десятки странных репозиториев, в которых невероятно сложно найти что-то релевантное. Сломанные pet-проекты. Непонятные тестовые задания для той самой вакансии из далекого 2017 года. Туториалы без изменений. И, самое любимое, репозитории «на будущее», которое так и не наступило.

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

Спойлер: да, он реально влияет на ваше собеседование.

Сперва выведем главную максимум этого текста: GitHub ≠ круто. GitHub = риск

Техлиды, которые участвуют в отборе, всё чаще обращаются к гиту или запрашивают его у кандидатов. Почему? GitHub показывает:

• Как вы пишите и структурируете код;

• Как как вы оформляете проекты и пишете документацию;

• Умеете ли доводить проекты до конца;

• Что вы делали вне продакшена - это особенно важно для джунов (которым и без этого приходится несладко) и тех, кто хочет сменить стек;

• И вообще, развиваетесь ли вы — или делаете вид.

И вот вы, допустим, техлид, открываете гитхаб кандидата и видите: туториалы по Flask 2016 года, репозиторий «bot2-final», без README, а еще коммиты уровня «fff1»

GitHub, по сути, ваш публичный цифровой след. А значит и часть вашей самопрезентации.

Как убить карьеру через GitHub

Способ №1: Чужие проекты без доработки

Форкнуть чей-то туториал и даже не поменять название - это ни разу не портфолио, это максимум заглушка. И заглушка откровенно плохая.

Если я вижу awesome-nodejs-course-by-x, то понимаю: человек просто проходил урок. Без рефлексии, без модификации. Безусловно, он мог учиться хорошо, даже отлично, но проект этого, увы, не демонстрирует.

Ноль изменений. Одноразовые коммиты и как следствие нет смысла это изучать.

Но это может сыграть вам на руку, если в проекте проведен рефакторинг, добавлены свои фичи и сделан банальный readme с анализом.

Способ №2: Кладбище pet-проектов

Знаете, это типичная картина: 3 коммита в первый день, один в третий – и…. мертвая тишина.
Словно человек открыл Google Docs, создал документ, гордо озаглавив его «Моя книга» и забыл о нем.

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

Да, это не критично, так или иначе мы все бросаем начатое, однако если большая часть вашего гитхаба - старое кладбище заброшенных проектов – возникает резонный вопрос, а следом напрашивается вывод. Который точно не сыграет вам на руку.

Способ №3: Кривой код без документации

Репозиторий пустой. Нет описания, нет README, нет ни одной внятной инструкции. Что это за проект? Зачем он здесь?

Код не читабелен, нет внятной структуры, только устрашающий коммент «не трогать!1» А вишенкой на торте красуются названия уровня test1.py, temp.js.

Это неизбежно производит впечатление такого школьного проекта. И не потому, что это «непросто» или «непонятно», а банально, потому что небрежно.

Способ №4: Мусорные коммиты

fix

fix2

fix_final

fuck_this

Это не выдумка, это реальный git log одного из кандидатов на фронт. Вообще велик соблазн как-то так обозвать коммит, но важно помнить, что это не дневник страданий, а история разработки. Если даже в pet-проекте вы не можете внятно описать, что вы делаете – как вам доверить прод?

Способ №5: Перекос по технологиям

Перед нами кандидат, который претендует на роль backend разработчика на Go. В резюме и в сопроводительном письме указан GitHub. Но внутри лишь верстка, пара проектов (пусть и неплохих) на Vue и внезапно учебный pet-проект на Python.

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

Способ №6: Публичный трэш

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

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

Способ №7: Псевдоактивность

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

Помните, GitHub - это не scoreboard. Это зеркало. А его, как правило, обманывать бессмысленно.

Чистим GitHub вместе

Короткий план ревизии:

• Удалите или сделайте приватными мёртвые проекты;

• Оставьте 2–3 актуальных, реально рабочих репозитория;

• В каждом: README.md с описанием, стэком, зачем проект, как его запускать;

• Переименуйте проекты в понятные названия (telegram-bot-reminder, go-url-shortener и т.д.);

• Если есть старый, но полезный проект - задокументируйте его ретроспективно.

Вместо вывода

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

Не надо делать идеально. Достаточно — внятно.

Пусть ваш GitHub говорит: «Я умею доводить до ума», а не «Я всё ещё не удалил temp1-final‑fuckthis.py».

Еще больше карьерных советов можно найти в моем телеграм канале. Подписывайтесь!