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

Перед откликом почти каждый джун упирается в один и тот же вопрос: что положить в портфолио, чтобы это посмотрели. Ответ неприятный. Большинство проектов в резюме junior frontend не смотрят, потому что заранее понятно, что там внутри. Todo-лист, погода по API, калькулятор, клон Netflix. Их видели сотни раз, и они ничего не говорят о главном для нанимающего: справится ли человек с задачей из его бэклога. Ниже про проекты, которые на этот вопрос отвечают.

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

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

• Работа с реальными данными. Есть ли загрузка, ошибка, пустое состояние, повторный запрос. В приложении, где данные лежат массивом в коде, этих состояний нет, а на работе они займут половину времени.
• Состояние сложнее одного useState. Корзина, фильтры, форма с зависимыми полями, кеш запросов. Здесь джуны и ломаются на боевых задачах.
• Готовность к продакшену. Проект открывается по ссылке, не разъезжается на телефоне, не отдаёт белый экран при ошибке сети.
• Следы решений. Почему такая структура папок, почему эта библиотека, почему компонент разбит так. По ним видно разработчика, а не человека, который повторял за видео.

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

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

Идеи идут от простого к сложному. Делать все не надо: выберите один как флагман и два поменьше.

1. Каталог с фильтрами, поиском и состоянием в URL

Предметка любая: вакансии, книги, рецепты, объявления. Важен не сам список, а то, что состояние фильтров живёт в URL. Ссылку можно скопировать и переслать, кнопка «назад» работает как ожидается, при перезагрузке ничего не теряется.

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

2. Дашборд с графиками на живых данных

Берёте открытый API (курсы валют, статистика погоды, публичные датасеты) и строите экран с несколькими графиками, переключением периода и агрегацией.

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

3. Форма-мастер в несколько шагов с валидацией

Заявка, анкета, оформление заказа. Три-четыре шага, зависимые поля, валидация на каждом, черновик в localStorage, возврат назад без потери данных.

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

4. Приложение с авторизацией и личным кабинетом

Регистрация, вход, защищённые маршруты, обновление токена, выход по истечении сессии. Бэкенд можно не писать: подойдёт Supabase, Firebase или готовый auth-провайдер.

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

5. Оффлайн-приложение (PWA) с локальным хранилищем

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

Интерфейс тут простой, а начинка заметно выше среднего портфолио: service worker, IndexedDB, разрешение конфликтов данных, установка на телефон.

6. Расширение для браузера

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

Вы показываете, что умеете читать документацию нестандартного API, работать с ограничениями среды, собирать и публиковать. Встречается такое редко, поэтому на фоне сотни todo-листов расширение запоминают.

7. Клон известного интерфейса, но честный

Клоны ругают, и заслуженно: собранный по видео клон ничего не доказывает. Другое дело, если вы взяли только визуальную часть как ТЗ, а остальное сделали сами: свой стек, свои данные, своя архитектура. Тогда в резюме это звучит как «каталог фильмов с интерфейсом, вдохновлённым Кинопоиском», и спокойно защищается на интервью.

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

• Три проекта на трёх разных фреймворках. Читается как «нигде не задержался». Лучше два на одном стеке и один эксперимент.
• Только вёрстка макетов. Свёрстанный лендинг это базовый навык. Если хотите его показать, показывайте через измеримое: адаптив, Lighthouse, работу с клавиатуры.
• Стек «на вырост». Redux Toolkit, Next.js и микрофронтенды на приложении из двух экранов вызывают вопрос «зачем?», а ответить на него сложно.
• Проект без ссылки. Не задеплоено, считайте, не существует. GitHub Pages, Vercel и Netlify закрывают это за пятнадцать минут.
• Пустой README. Хотя бы что это делает и как запустить. Что ещё должно быть в репозитории до отклика, разобрали в статье про GitHub для джуна.

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

Описание проекта отвечает на вопрос «что вы умеете», а не пересказывает содержимое. Сравните.

Было:

Интернет-магазин на React. Есть каталог, корзина, оформление заказа.

Стало:

Каталог вакансий с фильтрами (React, TypeScript, TanStack Query, Vite) Демо · GitHub Фильтры и поиск живут в URL: ссылка на выборку шарится, «назад» работает корректно. Бесконечный скролл с кешированием запросов, обработаны загрузка, ошибка сети и пустая выдача. Разбил на фиче-слои, покрыл логику фильтров тестами, задеплоил на Vercel.

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

И ещё про порядок: флагманский проект ставьте первым, всегда. Рекрутер читает полторы строки блока и решает, читать ли дальше.

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

Универсального портфолио не бывает. Одной команде важны формы и таблицы, другой анимация и скорость. Перед откликом сделайте скучное упражнение: выпишите из 5-7 целевых вакансий все технологии и типы задач, посчитайте, что повторяется чаще всего, и проверьте, что хотя бы один ваш проект это закрывает. Если ни один не закрывает, вот вам тема следующего.

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

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

• Нужны три проекта: один флагманский с деплоем и авторизацией, два поддерживающих.
• Ценится не идея, а работа с реальными данными, нетривиальное состояние и готовность к продакшену.
• Рабочие форматы: каталог с фильтрами в URL, дашборд на живом API, многошаговая форма, приложение с авторизацией, PWA, расширение браузера.
• Todo-лист, калькулятор и клон по видеоуроку не считаются, их видели сотни раз.
• Один стек в двух проектах лучше, чем три фреймворка по одному разу.
• Описывайте проект результатом и решениями, а не составом экранов. Флагман ставьте первым.
• Перед откликом сверяйте проекты с требованиями целевых вакансий, а не с рейтингами технологий.