Сколько проектов нужно в резюме junior backend-разработчика?

Хватит двух-трёх, но один должен быть заметно глубже остальных. Флагман это сервис с базой, миграциями, авторизацией, тестами и деплоем в Docker, его вы разбираете на интервью полчаса. Остальные показывают широту: фоновые задачи, интеграция с внешним API, телеграм-бот. Десять мелких репозиториев без деплоя работают против вас.

Достаточно ли CRUD-приложения для резюме джуна?

Голого CRUD недостаточно: он показывает только то, что вы прочитали документацию фреймворка. Проектом он становится, когда вокруг появляется инженерная обвязка: миграции, индексы под реальные запросы, авторизация с ролями, валидация входных данных, внятные коды ошибок, логи и тесты. Разговор на собеседовании пойдёт именно про обвязку, а не про сами эндпоинты.

Нужен ли Docker и деплой в пет-проекте backend-разработчика?

Да, и это самый дешёвый способ выделиться. Backend без развёртывания нанимающий проверить не может, а Dockerfile с docker-compose показывает, что вы понимаете, из чего состоит запуск сервиса: приложение, база, миграции, переменные окружения. Достаточно поднять проект на недорогом VPS или в бесплатном облаке и дать ссылку на работающие эндпоинты или Swagger.

Какой язык и стек выбрать для backend-проекта в 2026 году?

Тот, что чаще встречается в вакансиях, куда вы собираетесь откликаться. В российских джуновых бэкенд-вакансиях преобладают Python (Django, FastAPI), Java (Spring Boot), Go и Node.js с NestJS. Выберите один и сделайте на нём флагманский проект целиком. Это сильнее, чем четыре учебных репозитория на четырёх языках.

Считается ли телеграм-бот серьёзным проектом для backend?

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

Проекты в резюме junior backend: какие собрать

Портфолио junior backend выглядит почти всегда одинаково: два-три CRUD-сервиса на разных фреймворках, каждый набор эндпоинтов над одной таблицей. Написано обычно нормально. Беда в другом: такой проект молчит про то, что занимает тимлида. Что человек сделает, когда база начнёт тормозить, внешний сервис перестанет отвечать, а два запроса придут одновременно. Ниже про проекты, которые на эти вопросы отвечают.

Что тимлид ищет в бэкенд-проекте

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

Схема данных. Есть ли миграции, продуманы ли связи и индексы, или всё создаётся через create_all при старте.
Границы и валидация. Что происходит с кривым запросом: понятная ошибка с кодом или пятисотка со стектрейсом.
Поведение при отказах. Внешний API упал, база недоступна, задача выполнилась дважды. Предусмотрено ли это хоть где-нибудь.
Тесты. Хотя бы на ключевую бизнес-логику. Одно их наличие уже выделяет джуна из потока.
Запуск. Dockerfile, docker-compose, .env.example, README с командами. Проект, который не поднимается за пять минут, не смотрят.

Про общие критерии (какой проект считается сильным и сколько их нужно) есть отдельная статья: пет-проекты в резюме. Дальше идеи именно под бэкенд.

7 проектов, которые работают в резюме junior backend

1. API с ролями и правами доступа

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

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

2. Сервис с фоновыми задачами и очередью

Всё, что не должно выполняться внутри HTTP-запроса: рассылка уведомлений, генерация отчёта, обработка загруженного файла. Очередь берите родную для стека, Celery, RQ, BullMQ.

Вы показываете, что понимаете, зачем тяжёлое выносят из запроса, что такое ретраи и идемпотентность, как отдать статус задачи и её результат. В джуновых портфолио встречается редко, в продакшене есть почти везде.

3. Интеграция с внешним API и защита от его отказов

Агрегатор чего угодно: цены, курсы, вакансии, погода по нескольким городам. Интересна не сама интеграция, а то, что вы предусмотрели: таймауты, ретраи с backoff, кеширование ответов, поведение сервиса, когда источник лежит.

Фраза «при недоступности источника отдаём данные из кеша и логируем деградацию» звучит на интервью как опыт, а не как учёба.

4. Телеграм-бот с базой, расписанием и живыми пользователями

Формат зря недооценивают. Бот с подписками, PostgreSQL, планировщиком и обработкой падений это полноценный бэкенд-сервис, у которого вдобавок есть настоящие пользователи, а значит и цифра для резюме.

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

5. Сервис загрузки и обработки файлов

Пользователь загружает изображение, CSV или PDF, сервис его валидирует, обрабатывает в фоне и отдаёт результат по ссылке.

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

6. Небольшой этюд про производительность

Один сервис, одна тяжёлая ручка. Вы снимаете метрики нагрузочным тестом, находите узкое место, добавляете индекс и кеш, снимаете метрики снова и кладёте в README таблицу «было / стало».

Так в резюме появляется честная цифра: «сократил время ответа ручки каталога с 800 до 90 мс». Такие строчки дочитывают. И за ними стоит привычка измерять, а не угадывать.

7. Проект с полноценной инфраструктурной обвязкой

Это не отдельная идея, а уровень исполнения любой из предыдущих. docker-compose с приложением, базой и миграциями, CI на GitHub Actions с прогоном тестов, линтер, .env.example, документация Swagger.

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

Проверь, попадают ли твои проекты в вакансию

Вставь резюме и вакансию junior backend: phew покажет, какие требования закрыты твоими проектами, а какие нет и что дописать. Первые проверки бесплатны.

Проверить

Чего в бэкенд-проектах быть не должно

Голый CRUD без обвязки. Пять эндпоинтов над одной таблицей это упражнение по документации фреймворка.
Секреты в репозитории. Реальный ключ или пароль в коммите отпугивает мгновенно, а находят такое быстро. Что ещё портит впечатление, собрано в статье про красные флаги в резюме.
Кафка и микросервисы «для солидности». Пять микросервисов там, где хватало одного, читаются не как масштаб, а как вопрос «зачем?», на который нет ответа.
База, поднятая руками. Нет миграций и docker-compose, значит проект не запустят.
Проект без ссылки и без README. Проверить нельзя, значит не считается. Как оформить репозиторий до отклика, разобрано в материале про GitHub для джуна.

Как описать бэкенд-проект в резюме

Технологии сами по себе ничего не значат, их перечисляют все. Значение имеет то, что вы с ними сделали.

Было:

Сервис бронирования на FastAPI. PostgreSQL, Docker, JWT-авторизация.

Стало:

Сервис бронирования переговорок (Python, FastAPI, PostgreSQL, Celery, Docker) Демо · Swagger · GitHub Роли пользователь/менеджер/админ, JWT с refresh, проверка прав на уровне репозитория. Напоминания о встречах уходят фоновой задачей в Celery, с ретраями и защитой от повторной отправки. Пересечения броней ловятся constraint'ом на уровне БД, ключевая логика покрыта тестами (pytest). Поднимается одной командой: docker-compose с приложением, базой и миграциями Alembic.

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

Как выбрать, что делать следующим

Не пишите проект «вообще». Откройте 5-7 вакансий junior backend, куда реально хотите откликнуться, и выпишите повторяющееся: стек, база, очереди, Docker, тесты, тип задач. Дальше сравните со своим портфолио. То, что встречается в вакансиях чаще всего и не закрыто ни одним проектом, и есть тема следующего.

Часто выясняется, что проект нужное умение закрывает, но в резюме об этом не написано ни слова, и совпадения не видит ни ATS, ни человек. Тогда быстрее переформулировать описание, чем писать новый сервис. Логика разобрана в статье про то, как адаптировать резюме под вакансию.

Коротко: проекты в резюме junior backend

Хватит двух-трёх проектов, один флагманский: база, миграции, тесты, деплой.
Тимлид смотрит на схему данных, валидацию, поведение при отказах, тесты и лёгкость запуска.
Рабочие форматы: API с ролями, сервис с очередью, интеграция с внешним API, телеграм-бот, обработка файлов, этюд с кешем и замерами.
Голый CRUD, секреты в репозитории и микросервисы «для солидности» портят впечатление.
Docker, docker-compose и README с командами это самый дешёвый способ выделиться.
Описывайте решениями и цифрами: «было 800 мс, стало 90 мс» дочитывают.
Тему следующего проекта берите из требований целевых вакансий, а не из рейтингов технологий.