GitHub соискателя должен за полминуты ответить на три вопроса: кто вы, с каким стеком работаете и какой проект открыть первым. Для этого нужны заполненный профиль с фото и коротким описанием, README профиля, 3–6 закреплённых репозиториев с понятными README, демо и инструкцией по запуску, аккуратный код с тестами и осмысленная история коммитов. Пустой профиль или набор брошенных учебных проектов лучше не указывать в резюме вовсе.
Кто и как смотрит ваш GitHub
Профиль открывают двое, и смотрят они по-разному.
- Рекрутер тратит на первый просмотр от 30 секунд до минуты. Он сверяет имя с резюме, смотрит описание, стек, закреплённые проекты и активность.
- Тимлид или технический интервьюер выделяет 2–3 минуты на проект: открывает README, структуру папок, пару файлов с кодом, тесты и историю коммитов. Часто это единственная возможность увидеть ваш код до собеседования.
GitHub в своём руководстве для соискателей тоже исходит из того, что нанимающий менеджер тратит на проект всего пару минут. Поэтому главное — ясность и порядок, количество репозиториев вторично.
Учитывайте, что большая часть коммерческой разработки идёт в приватных репозиториях, и работодатели это понимают. Публичный GitHub дополняет резюме, а для джунов и разработчиков без открытого опыта часто становится главным доказательством навыков.
Профиль: что заполнить
Имя и фамилия. Как в резюме, чтобы профиль легко было сопоставить с кандидатом. Никнейм — нейтральный, без шуток.
Фото. Лицо крупным планом на спокойном фоне. Аватар-картинка не запрещён, но фото вызывает больше доверия.
Био. Одна-две строки: роль, стек и что ищете. Например: «Backend-разработчик на Python. FastAPI, PostgreSQL, Docker. Открыт к удалённой работе».
Локация и часовой пояс. Для удалённых вакансий это важный фильтр.
Контакты. Публичный email (лучше отдельный от того, что привязан к аккаунту), ссылки на сайт-портфолио, LinkedIn или Telegram.
Статус. В профиле можно поставить статус — например, «Ищу работу» с эмодзи.
README профиля
Если создать публичный репозиторий с именем, совпадающим с вашим логином, его README будет показан вверху профиля. Это главная витрина.
Что включить:
- короткое приветствие и специализацию;
- стек: языки, фреймворки, инструменты — коротким списком;
- 2–4 лучших проекта с одной строкой описания и ссылкой;
- опыт и достижения, которые не видны в репозиториях: коммерческие проекты под NDA, публикации, выступления, сертификаты;
- как с вами связаться.
Чего избегать: десятков бейджей технологий, анимированных счётчиков и виджетов статистики, которые занимают экран и ничего не сообщают о навыках. Один аккуратный экран текста работает лучше.
Закреплённые репозитории
GitHub позволяет закрепить до шести репозиториев или gist. Пока вы ничего не закрепили, профиль показывает самые популярные репозитории — часто случайные.
Как выбрать:
- 3–4 сильных проекта лучше шести случайных. GitHub рекомендует 3–5, авторы гайдов для соискателей советуют начинать с 2–3 лучших.
- Проекты под целевую вакансию. Ищете работу во фронтенде — закрепите интерфейсы с демо, в бэкенде — API с тестами и документацией.
- Сочетание своих проектов и вклада в open source. Свой проект показывает самостоятельность, pull request в чужую библиотеку — умение работать в команде и с чужим кодом.
- Только законченное. Амбициозный, но брошенный на середине проект вызывает больше вопросов, чем маленький, но доведённый до конца.
Учебные проекты по курсу закреплять можно, если вы их доработали и они отличаются от тысяч одинаковых копий. Добавьте свою функцию, тесты, деплой.
README проекта
README — первое, что видит тимлид. Если он не понял, что делает проект и как его запустить, до кода он может не дойти.
Структура, которая работает:
- Название и одна строка о том, что делает проект и для кого.
- Демо: ссылка на работающую версию, скриншоты или GIF. Для консольных утилит — запись терминала.
- Возможности: 3–6 пунктов.
- Стек и причины ключевых решений: почему PostgreSQL, а не MongoDB, почему такая архитектура.
- Запуск: команды для локального старта, лучше через
docker compose up, и пример.env.example. - Тесты: как их запустить.
- Архитектура: схема или короткое описание модулей.
- Что можно улучшить: честный список ограничений показывает зрелость.
Заполните и блок About справа: описание, ссылку на демо и темы (topics) — технологии и ключевые слова. Так репозиторий проще найти через поиск GitHub.
Код, коммиты и инженерная культура
Чистота кода. Единый стиль, линтер и форматтер, понятные имена файлов и функций. Уберите отладочные выводы, закомментированные куски и функции с пометкой «удалить потом».
Тесты и CI. Даже несколько тестов и простой workflow в GitHub Actions, который их запускает, выделяют проект среди пет-проектов. Зелёная галочка у последнего коммита — сигнал, что код работает.
Коммиты. Сообщения вида «fix», «update» или один огромный коммит со всем проектом говорят о небрежности. Пишите, что и зачем изменилось. Удобный формат — Conventional Commits: feat: добавить фильтр по дате, fix: исправить пагинацию.
Pull request и issues. Даже в личном проекте можно вести задачи в issues и вливать изменения через pull request с описанием. Это показывает, как вы будете работать в команде.
Зависимости. Держите их в актуальном состоянии; Dependabot может сам открывать pull request с обновлениями.
Секреты. Никогда не храните ключи API, пароли и токены в репозитории. Используйте переменные окружения и .env в .gitignore. Если ключ уже попал в историю коммитов, удаления файла недостаточно: отзовите ключ и выпустите новый.
Активность и график вкладов
График вкладов (contribution graph) по умолчанию показывает только публичную активность. Если вы много работаете в приватных репозиториях, включите в настройках профиля отображение приватных вкладов: на графике появятся отметки без названий репозиториев и деталей.
Регулярная активность выглядит лучше, чем всплеск коммитов за неделю до поиска работы. Искусственно «озеленять» график пустыми коммитами не стоит: опытный интервьюер увидит это за секунды.
GitHub и ИИ-инструменты
Сгенерировать шаблонный проект сейчас может кто угодно, поэтому количество кода стало слабым сигналом. Сильнее работают:
- осмысленная архитектура и объяснение решений в README;
- тесты, CI и аккуратные pull request;
- история коммитов, в которой видно, как проект развивался;
- описание ограничений и компромиссов.
Если вы работаете с ИИ-ассистентами, это можно показать как навык: файл правил для агента (например, AGENTS.md или CLAUDE.md) с командами сборки и стилем кода, тесты, которые проверяют сгенерированный код, честный раздел в README о том, как использовался ИИ. Главное — уметь объяснить на собеседовании любую строку в репозитории. Вакансии, где ценят такую работу с ИИ, собраны в разделах разработка и вайбкодинг.
Что выложить, если показывать нечего
- Пет-проект с реальной задачей: бот, парсер, сервис для себя или знакомых. Один продуманный проект ценнее десятка случайных.
- Вклад в open source: исправления в документации, задачи с меткой
good first issue, мелкие баги в библиотеках, которыми пользуетесь. - Воспроизводимые примеры: небольшие репозитории, которые показывают решение типовой задачи из вашей области.
- Проекты под роль:
- фронтенд — интерфейс с демо на GitHub Pages или Vercel;
- бэкенд — API с документацией OpenAPI, тестами и docker-compose;
- данные и ML — воспроизводимый пайплайн и ноутбук с выводами, а не только сырой ноутбук;
- мобильная разработка — скриншоты, видео и сборка в релизах.
Типичные ошибки
| Ошибка | Чем вредит | Как исправить |
|---|---|---|
| Пустой профиль без фото и описания | Непонятно, кто вы и что умеете | Заполнить имя, фото, био, README профиля |
| README из одной строки | Тимлид не поймёт, что делает проект | Описание, демо, запуск, стек |
| Закреплены форки и брошенные проекты | Создают впечатление незаконченности | Закрепить 3–6 законченных проектов |
| Коммиты «fix», «update» | Сигнал о небрежности | Писать, что и зачем изменилось |
| Ключи и пароли в коде | Риск и красный флаг для работодателя | Переменные окружения, отзыв ключей |
| Копии курсовых проектов без доработок | Ничем не выделяются | Добавить свою функциональность, тесты, деплой |
| Виджеты и бейджи на весь экран | Отвлекают от сути | Оставить текст и ссылки на проекты |
Особенности для России
В мае 2026 года пользователи из России сообщали о сбоях доступа к GitHub. Роскомнадзор заявил, что сервис не ограничен, но часть рекрутеров и интервьюеров в российских компаниях могла сталкиваться с медленной загрузкой. Чтобы не потерять просмотр, можно держать зеркало ключевых проектов на GitLab или российских платформах вроде GitVerse, GitFlic и SourceCraft и указать в резюме обе ссылки.
Где указать GitHub: в поле «Обо мне» и в описании опыта на hh.ru, в профиле на Хабр Карьере, в сопроводительном письме. Собрать резюме со ссылками на проекты поможет конструктор резюме.
Частые вопросы
Стоит ли указывать GitHub в резюме, если там мало проектов?
Да, если там есть хотя бы 1–2 законченных проекта с README. Если профиль пустой или в нём только брошенные учебные репозитории, лучше сначала навести порядок.
Важны ли звёзды и подписчики?
Для большинства вакансий нет. Звёзды показывают популярность проекта, а работодатель оценивает качество кода, документации и процесс работы.
Можно ли закреплять форки?
Можно, если в форке есть ваши заметные изменения или он связан с вашим pull request в оригинальный проект. Форк без изменений лучше не закреплять.
Что делать, если весь опыт под NDA?
Опишите в README профиля типы задач и стек без деталей, включите отображение приватных вкладов и сделайте 1–2 небольших публичных проекта, похожих по технологиям на рабочие задачи.
Нужен ли GitHub дизайнерам, аналитикам и тестировщикам?
Для аналитиков данных и QA-инженеров — да: SQL-запросы, ноутбуки, автотесты хорошо смотрятся в репозиториях. Дизайнерам чаще нужен сайт-портфолио, но GitHub Pages подходит и для него.
Можно ли удалить старые неудачные репозитории?
Да, или сделать их приватными либо архивировать. Публичными стоит оставлять проекты, за которые вам не стыдно на собеседовании.