Какие проекты класть в портфолио: три типа, которые работают

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

Обычный набор джуна выглядит так. Todo-лист из курса. Клон Твиттера, доведённый до половины. Бот, который присылает погоду. Три раза одно и то же по сути, и ни один из проектов не отвечает на вопрос, зачем звать этого человека на разговор.

Разберём, что кладут вместо.

Про оформление самого профиля есть отдельный разбор: портфолио на GitHub.

Сколько проектов нужно

Два. Максимум три.

Дальше срабатывает обратный эффект: чем длиннее список, тем очевиднее, что законченного среди них нет. Шесть закреплённых слотов на GitHub — не задание, которое надо выполнить целиком.

Один сильный проект лучше четырёх средних. Его откроют, а четыре средних просмотрят по названиям и закроют.

Тип первый: доведённый до конца

Самое редкое и самое ценное. Не «работает у меня локально», а поднимается одной командой, имеет тесты и написано, что делать, если упало.

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

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

Тип второй: с чужими грязными данными

Проект, где данные пришли извне и оказались кривыми. Открытое API с лимитами, выгрузка из госреестра, парсинг чужой страницы, файл от заказчика с пропусками и дублями.

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

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

Тип третий: скучный рабочий

Скрипт, который автоматизировал вам что-то реальное. Выгрузка отчёта, который вы собирали руками. Проверка ссылок на сайте. Синхронизация двух таблиц.

Такие проекты стесняются показывать, потому что они маленькие и не звучат. А читающий видит в них главное: человек заметил рутину и убрал её. Это ровно то поведение, за которое платят.

Размер тут не важен. Сто строк с внятным README сильнее клона соцсети на пять тысяч строк, брошенного на середине.

Чем плохи туториалы и клоны

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

Если проект из курса всё-таки хочется оставить, его надо изменить до неузнаваемости: другая предметная область, свои данные, добавленные функции, тесты. Тогда это уже ваш проект.

С клонами известных сервисов та же история плюс вторая беда: их не доделывают почти никогда. Клон Твиттера без ленты, без уведомлений и без деплоя выглядит как брошенная стройка.

Как выбрать проект под вакансию

Стек проекта важнее темы. Если в вакансии Postgres, очереди и докер, а у вас проект на файликах и sqlite — совпадения нет, каким бы интересным он ни был.

Рабочий способ: взять требования вакансии и сверить их со своим проектом построчно. Чего не хватает — добавить, если это день работы. Кэш на редисе, очередь, миграции, простой CI: каждое такое дополнение закрывает строчку из требований.

И один проект под роль лучше, чем портфолио «на все случаи». Аналитику показывают работу с данными, бэкендеру — сервис, тестировщику — тесты.

Как описать, чтобы открыли

В резюме проект стоит упоминать одной строкой с результатом, а не названием. Не «Pet-проект: сервис заметок», а «Сервис заметок с поиском по тексту: Postgres, очередь для индексации, разворачивается одной командой».

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

Что делать, если проектов нет вообще

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

Один такой проект за две недели даст больше, чем начатый и брошенный маркетплейс за три месяца.

А техническую часть собеседования готовят параллельно, потому что портфолио доводит только до разговора. В Сеньорчике собраны вопросы с реальных технических собеседований по одиннадцати ролям: вопрос с вариантами, сразу разбор и движок, который возвращает темы, где вы ошибаетесь. Десять минут в день в Telegram, начать можно бесплатно.