GitHub для джуна: что должно быть в профиле

Резюме джуна почти всегда заканчивается ссылкой на GitHub — и по этой ссылке тимлид идёт за главным доказательством: код у человека настоящий или это только слова. Проблема в том, что чаще всего по ссылке его встречает пустой профиль с одним форком чужого репозитория и коммитами «fix» и «asdf». Такой GitHub не помогает, а вредит: наниматель шёл убеждаться, а получил повод сомневаться. Разберём, что должно быть в профиле джуна до первого отклика, как оформить репозитории и README и почему иногда лучше не давать ссылку вовсе, чем вести на пустоту.

Почему GitHub для джуна важнее, чем для мидла

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

Тимлид открывает профиль, чтобы ответить на вопросы, которые резюме не закрывает: доводит ли человек проекты до конца, как он структурирует код, пишет ли понятные коммиты, разбирается ли в git вообще. Это ближе к реальной работе, чем любой список навыков. Поэтому GitHub — не «плюсик», а часть связки резюме + код + сопроводительное, где слабое звено рушит всю цепочку. Как эта связка работает целиком, разобрали в статье почему джуна не берут на работу.

Что должно быть в профиле до отклика

Профиль читают как ещё одно резюме — по первому экрану. Вот что на нём должно быть.

1. Заполненная «шапка» профиля

• Настоящее имя (или узнаваемый ник), а не user8837462.
• Короткое био: «Junior backend-разработчик, Python/FastAPI» — одна строка, чтобы было ясно, кто вы.
• Ссылка на резюме, сайт-визитку или хотя бы telegram.
• Аватар — любой нейтральный, а не серая заглушка. Мелочь, но профиль с заглушкой выглядит брошенным.

2. Два-три закреплённых проекта (pinned)

GitHub позволяет закрепить репозитории вверху профиля — используйте это. Закрепите 2–3 своих лучших проекта, чтобы тимлид сразу увидел главное, а не искал среди учебных форков. Про то, какие проекты в принципе стоит показывать, а какие только вредят, — отдельный разбор про пет-проекты в резюме. Здесь важно одно: закреплённое — это витрина, туда идёт только доведённое до ума.

3. README в каждом показываемом проекте

README — первое, что открывают после кода, и часто вместо кода. Минимальный рабочий README:

• что делает проект — одно-два предложения по-человечески;
• стек — на чём написано;
• как запустить — команды, чтобы проект поднялся с нуля;
• ссылка на демо, если развёрнуто;
• скриншот или гифка для проектов с интерфейсом.

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

4. Чистая история коммитов

Коммиты — это то, как вы работаете, в миниатюре. fix, fix2, asdf, финал_финал кричат о том, что человек не привык к аккуратной работе. Осмысленные сообщения — add JWT auth, fix race condition in price parser — показывают обратное. Не нужно идеала: достаточно, чтобы по истории было видно логику, а не хаос.

Чего в профиле быть не должно

Эти вещи отпугивают быстрее, чем пустота:

• Десятки форков чужих репозиториев без своих изменений — создают шум и прячут ваши настоящие проекты. Форки, в которые вы не коммитили, лучше убрать из вида.
• Пустые репозитории «test», «test2», «project» — сигнал «начинаю и бросаю».
• Закоммиченные node_modules, .env, ключи и пароли — грубая ошибка гигиены; секрет в истории коммитов тимлид замечает сразу, и это серьёзный минус.
• Только учебные проекты, один в один как у потока — про то, как не выглядеть выпускником потока, в статье про резюме после курсов.
• Код без единого коммита за год рядом со ссылкой «активно ищу работу» — противоречие, которое замечают.

Про зелёную сетку и опенсорс

Два частых вопроса джунов.

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

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

Если показывать пока нечего

Честный сценарий: профиль пустой, сильных проектов ещё нет. Тогда не давайте ссылку на GitHub в резюме — пустой профиль вредит больше, чем его отсутствие. Вместо этого потратьте неделю-две на то, чтобы собрать 2–3 нормальных проекта, довести их до деплоя и написать README. Это вложение окупается: ссылка на живой GitHub закрывает отсутствие коммерческого опыта убедительнее любых слов в резюме. Как собрать резюме, пока проекты в работе, — в статье про резюме программиста без опыта.

Перед откликом: собрать всё вместе

GitHub — одно из трёх звеньев. Перед волной откликов проверьте, что они не противоречат друг другу:

• Резюме — ссылка на GitHub ведёт на заполненный профиль, стек в резюме совпадает с тем, что в проектах (чек-лист проверки резюме).
• Сопроводительное — здесь можно прямо сослаться на конкретный репозиторий под стек вакансии (как написать письмо).
• Ожидания по откликам — держите реалистичную рамку (сколько откликов нужно джуну).

Когда резюме, GitHub и письмо говорят одно и то же и подтверждают друг друга, отклик джуна перестаёт быть «ещё одним из потока».

Коротко: GitHub для джуна

• Для джуна GitHub — главное доказательство, что код настоящий; тимлид почти всегда идёт по ссылке.
• В профиле: заполненная шапка, 2–3 закреплённых своих проекта, README в каждом, чистые коммиты.
• README: что делает, стек, как запустить, ссылка на демо, скриншот.
• Убрать: форки без правок, пустые «test»-репо, закоммиченные node_modules и секреты.
• Зелёная сетка почти не считается; принятые PR в опенсорс — сильный сигнал.
• Показывать нечего — не давайте ссылку на пустой профиль, сначала соберите 2–3 проекта.
• Резюме, GitHub и сопроводительное должны совпадать и подтверждать друг друга.

FAQ

Обязательно ли джуну иметь GitHub?

Практически да. Для джуна без коммерческого опыта GitHub — главное доказательство, что код настоящий, а не только слова в резюме. Тимлид почти всегда открывает профиль по ссылке из резюме, чтобы посмотреть, как вы пишете. Резюме без ссылки на код заставляет верить на слово, а с сильным GitHub — проверять и убеждаться. Отсутствие профиля не запрещает отклик, но лишает вас самого весомого аргумента.

Что должно быть в GitHub-профиле джуна?

Минимум: 2–3 закреплённых (pinned) собственных проекта с понятными README, чистой историей коммитов и, в идеале, ссылкой на развёрнутое демо. Заполненный профиль — имя, короткое био, ссылка на резюме или сайт. Не нужно: десятки форков, пустые репозитории «для теста», закоммиченные node_modules и секреты. Профиль читают как ещё одно резюме — по первому экрану.

Вредит ли пустой или заброшенный GitHub?

Да, ссылка на слабый профиль вредит сильнее, чем её отсутствие. Тимлид идёт по ссылке за доказательством, а находит один форк чужого репозитория и коммиты «fix», «asdf», «lesson 5» — и это подтверждает опасение, что за резюме нет реального кода. Если показать пока нечего, лучше не давать ссылку, а сначала собрать 2–3 нормальных проекта, чем вести на пустоту.

Считается ли для работодателя зелёная сетка контрибьюшенов?

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

Нужно ли джуну контрибьютить в опенсорс?

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