Я несколько раз участвовал в технических интервью с обеих сторон и заметил повторяющийся паттерн: кандидаты делают много pet-проектов, но работодатель не понимает, чем именно они сильны. Обычно проблема не в уровне кода, а в том, как проект оформлен и насколько он похож на реальную рабочую задачу.
1. Нет понятной цели проекта
В репозитории часто видно «еще один todo-app» без контекста. Интервьюеру сложно понять, что вы хотели показать: архитектуру, UX, работу с API или DevOps-практики. Добавьте в README короткий блок: проблема, для кого решение, какие ограничения учитывались. Это сразу делает проект осмысленным.
2. Отсутствует история инженерных решений
Код может быть аккуратным, но без объяснения ключевых решений он выглядит случайным. Почему выбрали такую структуру? Почему именно этот стек? Какие компромиссы приняли? Один файл `DECISIONS.md` или раздел в README с 3-5 пунктами резко повышает ценность проекта.
3. Проект нельзя быстро запустить
Если для запуска нужно читать весь репозиторий и вручную угадывать переменные окружения, большинство просто закроет вкладку. Минимум, который стоит сделать: команда установки, команда старта, пример `.env`, и короткая секция «как проверить, что все работает».
4. Нет тестов на ключевую логику
Необязательно покрывать 100% кода. Но если в проекте есть авторизация, валидация данных или расчет бизнес-правил, хотя бы базовые тесты должны быть. Они показывают, что вы думаете о надежности, а не только о демо-интерфейсе.
5. Пет-проект не доведен до финального вида
Частая ситуация: есть идея и половина реализации, но нет завершенности. Лучше один проект, где закрыт основной пользовательский сценарий, чем пять репозиториев «в процессе». Работодателю важно увидеть, что вы умеете доводить работу до результата.
Сильное портфолио - это не коллекция технологий, а доказательство того, что вы умеете решать задачи как инженер.
Перед откликом на вакансию проведите быстрый аудит: за 20 минут дайте коллеге ссылку на репозиторий и попросите запустить по README. Если у него появились вопросы уже на первом шаге, в этом и есть зона роста. После пары таких итераций ваш проект начинает работать как аргумент на собеседовании, а не как фон.
Еще один полезный прием - под каждую вакансию подбирать релевантный проект. Если ищете backend-роль, акцентируйте проект с API, схемой БД и тестами. Если целитесь во frontend, покажите работу с состоянием, доступностью и производительностью. Контекст вакансии сильно влияет на то, как читают ваш GitHub.
Текст: Алексей Орлов · Фото: редакционный архив блога