Первая работа во frontend

Pet-проекты для frontend-разработчика: идеи по уровням и как о них рассказать

Обновлено 6 мин чтения
Содержание
  1. Коротко
  2. Зачем нужны pet-проекты, если есть учебные
  3. Идеи pet-проектов по уровням
  4. Как не сделать «ещё один todo»
  5. Что должно быть в каждом проекте
  6. Как рассказать о проекте на собеседовании
  7. Частые ошибки
  8. Чек-лист
  9. Вопросы из базы
  10. Как тренировать
  11. Частые вопросы
Коротко

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

Зачем нужны pet-проекты, если есть учебные

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

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

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

Идеи pet-проектов по уровням

Уровень здесь не про грейд, а про то, где вы сейчас. Начинайте с первой строки и переходите к следующей, когда текущий проект работает и задеплоен.

УровеньИдеяЧто в ней прокачать
Первый проектАдаптивная страница по макету: лендинг, карточка товара, профильСемантика, Flexbox и Grid, доступность, вёрстка от узкого экрана
Первый проектВиджет погоды или курса валют через открытое APIfetch, состояния загрузки и ошибки, работа с датами
Уверенная базаКаталог с фильтрами, поиском и пагинациейСостояние в адресной строке, debounce поиска, пустые результаты
Уверенная базаТрекер привычек или расходов с хранением в браузереФормы и валидация, localStorage, графики
Сильный juniorКанбан-доска с перетаскиванием и офлайн-режимомСложное состояние, оптимистичные обновления, тесты
Сильный juniorЛичный кабинет с авторизацией и ролями на своём или открытом APIМаршрутизация, защита страниц, обработка 401 и 403
Лучшая идея та, которой вы будете пользоваться сами. Тогда вы найдёте баги раньше интервьюера и сможете честно рассказать, что улучшили после первого запуска.

Как не сделать «ещё один todo»

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

  • Реальные данные. Возьмите открытое API или свой небольшой сервер. Пустой массив в коде не показывает работу с сетью.
  • Медленная сеть. Проверьте проект с замедлением в DevTools. Нужны скелетоны, блокировка повторной отправки, понятная ошибка.
  • Краевые случаи. Пустой список, очень длинное название, сто тысяч строк, отключённый интернет.
  • Своё решение. Например, отмена устаревших запросов при быстром вводе или виртуальный список для длинной ленты.
  • Доступность. Форма проходится с клавиатуры, у кнопок есть подписи, контраст достаточный.

Одна такая сложность, решённая и описанная в README, весит больше, чем три одинаковых проекта. Если нужен пример, как формулировать решение, посмотрите разбор задач на собеседовании frontend: debounce и отмена запросов там разобраны с кодом.

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

  1. Живая ссылка. Проект открывается в браузере без установки. Бесплатного хостинга статики для этого хватает.
  2. README. Что это, зачем, стек, как запустить, какие решения приняты и что бы вы сделали дальше. Пять абзацев, не роман.
  3. История коммитов. Небольшие коммиты с понятными сообщениями. Один коммит «initial» на весь проект вызывает вопросы.
  4. TypeScript и линтер. Для современной вакансии это ожидаемая база, а не бонус.
  5. Хотя бы несколько тестов. Пара тестов на логику и один на компонент уже показывают, что вы знаете, зачем они нужны.
  6. Адаптивность. Проверьте ширину телефона. Интервьюер часто открывает ссылку именно с него.

Как упаковать проекты в целом, разобрано в статье про портфолио frontend-разработчика. Здесь важна сама начинка.

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

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

  1. Что за проект и какую задачу он решает. Одна фраза.
  2. Стек и почему именно он. «Так было в курсе» не ответ, а «нужна была типизация данных из API» ответ.
  3. Самая сложная часть и как вы её решили. Это центр рассказа.
  4. Что не получилось или что бы вы сделали иначе. Честность здесь ценится.
  5. Что дальше: какие улучшения вы видите.
Как это звучит

«Сделал каталог книг на React и TypeScript с поиском по открытому API. Сложнее всего было с поиском: ответы приходили не по порядку, и на экране мелькали старые результаты. Добавил отмену прошлого запроса через AbortController. Сейчас бы вынес загрузку данных в отдельный слой с кешем, чтобы не грузить одно и то же при возврате назад.»

После рассказа будут уточнения: почему не использовали библиотеку, как устроено состояние, что будет при тысяче элементов. Общая структура рассказа о себе и опыте разобрана в гайде «Расскажите о себе», а истории о трудностях удобно строить по STAR из поведенческого интервью.

Частые ошибки

  • Пять одинаковых проектов вместо двух доведённых до конца
  • Проект без живой ссылки или с ошибкой при первом открытии
  • Копия проекта из курса без единого своего решения
  • README из одной строки «npm start»
  • Не помнить, как работает свой же код, когда интервьюер просит открыть файл

Чек-лист

  • Два-три проекта, каждый задеплоен и открывается с телефона
  • В каждом есть работа с сетью, загрузка, ошибка и пустое состояние
  • Хотя бы одна настоящая сложность решена и описана в README
  • TypeScript, линтер и несколько тестов
  • Рассказ о каждом проекте на две минуты отрепетирован вслух

Вопросы из базы Техпрогона

Частые вопросы по теме с ответом и разбором. Откройте любой и попробуйте ответить сами.

Как тренировать в Техпрогоне

  • Вопросы, которые всплывают при разборе проекта, есть в каталогах React, JavaScript и браузера с ответами и разбором.
  • Банк историй в кабинете: питч и истории STAR про проекты, бесплатно до трёх историй.
  • Билеты с зачётом по React: 20 вопросов, зачёт при двух ошибках и меньше. Хорошая проверка, понимаете ли вы то, что уже написали.
  • Мок «Наедине» с задачами с кодом бесплатно, 3 задачи в день.

Частые вопросы

Сколько pet-проектов нужно junior frontend-разработчику?
Обычно хватает двух-трёх доведённых до конца. Важнее, чтобы в каждом была своя сложность и вы могли подробно о ней рассказать.
Можно ли положить в портфолио проект из курса?
Можно, если вы заметно его доработали и честно об этом пишете. Без своих изменений учебный проект почти ничего не добавляет.
Нужен ли свой бэкенд в pet-проекте?
Не обязательно. Открытого API или простого готового сервера достаточно. Важно показать работу с сетью, ошибками и загрузкой на стороне клиента.
Что делать, если идей нет?
Возьмите задачу, которая раздражает вас самих: учёт расходов, список фильмов, расписание тренировок. Своя боль даёт мотивацию довести проект и честную историю для собеседования.
Командный проект лучше одиночного?
Он показывает работу с git, ревью и договорённостями, это плюс. Но на собеседовании вас спросят, что сделали именно вы, поэтому свою часть нужно знать досконально.

Билеты с зачётом вместо чтения статей

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

Читайте также