Первая работа во frontend
Pet-проекты для frontend-разработчика: идеи по уровням и как о них рассказать
Содержание
Pet-проекты для frontend нужны не для галочки в резюме, а чтобы на собеседовании было что разобрать: ваши решения, ошибки и компромиссы. Хватит двух-трёх проектов, если в каждом есть живые данные, состояние загрузки и ошибок, адаптивность и аккуратный README. Ниже идеи по уровням, обязательный минимум и план рассказа о проекте.
Зачем нужны pet-проекты, если есть учебные
Учебный проект из курса видели все, кто проверяет резюме. Его делали тысячи людей по одной инструкции. Он не говорит о вас ничего, кроме того, что вы дошли до конца курса.
Свой проект отвечает на другие вопросы. Умеете ли вы сами выбрать задачу. Можете ли довести её до рабочего состояния. Понимаете ли, почему сделали так, а не иначе. Именно это спрашивают на собеседовании junior без коммерческого опыта.
Есть и практическая польза. На проекте вы впервые встречаете вещи, которых нет в уроках: гонку запросов, кеширование, вёрстку под узкий экран, сборку и деплой. Эти темы потом всплывают в вопросах по React и браузеру, и отвечать на них становится проще.
Идеи pet-проектов по уровням
Уровень здесь не про грейд, а про то, где вы сейчас. Начинайте с первой строки и переходите к следующей, когда текущий проект работает и задеплоен.
| Уровень | Идея | Что в ней прокачать |
|---|---|---|
| Первый проект | Адаптивная страница по макету: лендинг, карточка товара, профиль | Семантика, Flexbox и Grid, доступность, вёрстка от узкого экрана |
| Первый проект | Виджет погоды или курса валют через открытое API | fetch, состояния загрузки и ошибки, работа с датами |
| Уверенная база | Каталог с фильтрами, поиском и пагинацией | Состояние в адресной строке, debounce поиска, пустые результаты |
| Уверенная база | Трекер привычек или расходов с хранением в браузере | Формы и валидация, localStorage, графики |
| Сильный junior | Канбан-доска с перетаскиванием и офлайн-режимом | Сложное состояние, оптимистичные обновления, тесты |
| Сильный junior | Личный кабинет с авторизацией и ролями на своём или открытом API | Маршрутизация, защита страниц, обработка 401 и 403 |
Как не сделать «ещё один todo»
Список задач сам по себе не плох. Плохо, когда он ничем не отличается от тысячи других. Чтобы проект выделялся, добавьте одну-две настоящие сложности и доведите их до конца.
- Реальные данные. Возьмите открытое API или свой небольшой сервер. Пустой массив в коде не показывает работу с сетью.
- Медленная сеть. Проверьте проект с замедлением в DevTools. Нужны скелетоны, блокировка повторной отправки, понятная ошибка.
- Краевые случаи. Пустой список, очень длинное название, сто тысяч строк, отключённый интернет.
- Своё решение. Например, отмена устаревших запросов при быстром вводе или виртуальный список для длинной ленты.
- Доступность. Форма проходится с клавиатуры, у кнопок есть подписи, контраст достаточный.
Одна такая сложность, решённая и описанная в README, весит больше, чем три одинаковых проекта. Если нужен пример, как формулировать решение, посмотрите разбор задач на собеседовании frontend: debounce и отмена запросов там разобраны с кодом.
Что должно быть в каждом проекте
- Живая ссылка. Проект открывается в браузере без установки. Бесплатного хостинга статики для этого хватает.
- README. Что это, зачем, стек, как запустить, какие решения приняты и что бы вы сделали дальше. Пять абзацев, не роман.
- История коммитов. Небольшие коммиты с понятными сообщениями. Один коммит «initial» на весь проект вызывает вопросы.
- TypeScript и линтер. Для современной вакансии это ожидаемая база, а не бонус.
- Хотя бы несколько тестов. Пара тестов на логику и один на компонент уже показывают, что вы знаете, зачем они нужны.
- Адаптивность. Проверьте ширину телефона. Интервьюер часто открывает ссылку именно с него.
Как упаковать проекты в целом, разобрано в статье про портфолио frontend-разработчика. Здесь важна сама начинка.
Как рассказать о проекте на собеседовании
О проекте спрашивают почти всегда, особенно если коммерческого опыта нет. Подготовьте рассказ на две минуты по простой схеме.
- Что за проект и какую задачу он решает. Одна фраза.
- Стек и почему именно он. «Так было в курсе» не ответ, а «нужна была типизация данных из API» ответ.
- Самая сложная часть и как вы её решили. Это центр рассказа.
- Что не получилось или что бы вы сделали иначе. Честность здесь ценится.
- Что дальше: какие улучшения вы видите.
«Сделал каталог книг на React и TypeScript с поиском по открытому API. Сложнее всего было с поиском: ответы приходили не по порядку, и на экране мелькали старые результаты. Добавил отмену прошлого запроса через AbortController. Сейчас бы вынес загрузку данных в отдельный слой с кешем, чтобы не грузить одно и то же при возврате назад.»
После рассказа будут уточнения: почему не использовали библиотеку, как устроено состояние, что будет при тысяче элементов. Общая структура рассказа о себе и опыте разобрана в гайде «Расскажите о себе», а истории о трудностях удобно строить по STAR из поведенческого интервью.
Частые ошибки
- Пять одинаковых проектов вместо двух доведённых до конца
- Проект без живой ссылки или с ошибкой при первом открытии
- Копия проекта из курса без единого своего решения
- README из одной строки «npm start»
- Не помнить, как работает свой же код, когда интервьюер просит открыть файл
Чек-лист
- Два-три проекта, каждый задеплоен и открывается с телефона
- В каждом есть работа с сетью, загрузка, ошибка и пустое состояние
- Хотя бы одна настоящая сложность решена и описана в README
- TypeScript, линтер и несколько тестов
- Рассказ о каждом проекте на две минуты отрепетирован вслух
Вопросы из базы Техпрогона
Частые вопросы по теме с ответом и разбором. Откройте любой и попробуйте ответить сами.
Как тренировать в Техпрогоне
- Вопросы, которые всплывают при разборе проекта, есть в каталогах React, JavaScript и браузера с ответами и разбором.
- Банк историй в кабинете: питч и истории STAR про проекты, бесплатно до трёх историй.
- Билеты с зачётом по React: 20 вопросов, зачёт при двух ошибках и меньше. Хорошая проверка, понимаете ли вы то, что уже написали.
- Мок «Наедине» с задачами с кодом бесплатно, 3 задачи в день.
Частые вопросы
Сколько pet-проектов нужно junior frontend-разработчику?
Можно ли положить в портфолио проект из курса?
Нужен ли свой бэкенд в pet-проекте?
Что делать, если идей нет?
Командный проект лучше одиночного?
Билеты с зачётом вместо чтения статей
20 вопросов в билете, зачёт при двух ошибках и меньше, разбор каждой ошибки. Бесплатный тариф без ограничения по времени.
Читайте также
Портфолио frontend-разработчика
Как собрать портфолио frontend-разработчика: сколько проектов нужно, что в них показать, как оформить README и GitHub и как рассказать о проекте на собесе.
Резюме frontend-разработчика
Как составить резюме frontend-разработчика: структура по блокам, полный пример для junior, формулировки до и после и ошибки, из-за которых не перезванивают.
Frontend без опыта
Как frontend-разработчик без опыта находит первую работу: что показать работодателю, где искать вакансии, как откликаться и готовиться к собеседованию.
Frontend с нуля
План обучения по этапам и первые проекты
Что должен знать junior frontend
Темы и частые вопросы собеседования
Все статьи
Первая работа, подготовка к собесу и задачи с кодом