Портфолио frontend-разработчика: что положить, как оформить и показать на собеседовании

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

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

Хороший набор для junior закрывает разные стороны работы фронтендера. Не обязательно в разных проектах, можно в одном большом.

Если нужны идеи, что именно сделать, загляните в статью про pet-проекты для frontend. Там идеи разложены по уровню сложности.

README это витрина проекта. Его читают раньше кода, а иногда вместо кода. Хороший README отвечает на пять вопросов.

1. Что это. Одно-два предложения: что делает приложение и для кого.
2. Ссылка на работающий сайт. Сверху, сразу под описанием. Плюс скриншот или короткая анимация.
3. Стек. Список технологий и почему выбраны ключевые.
4. Как запустить. Команды установки и запуска. Проверьте, что они работают на чистой копии.
5. Решения и компромиссы. Что было сложно, что бы сделали иначе, что не успели. Этот раздел больше всего нравится инженерам.

• Закрепите на профиле два-три лучших репозитория. Остальное можно оставить, но сверху должно быть главное.
• Коммиты по шагам с понятными сообщениями: «форма заявки: валидация телефона», а не «fix» и «update».
• Никаких ключей и паролей в коде. Секреты в переменных окружения, пример в файле .env.example.
• Уберите из репозитория сборку, node_modules и личные файлы. Добавьте .gitignore.
• Один и тот же стиль кода во всём проекте: настройте форматтер и линтер.

Работа с Git тоже проверяется на собеседовании. Вопросы о ветках, слиянии и pull request есть в разделе Инструменты.

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

Отдельный сайт-портфолио для junior не обязателен. Хватит профиля на GitHub с закреплёнными проектами и ссылками в резюме. Если делаете свой сайт, сделайте его так же аккуратно, как остальные проекты: его тоже будут оценивать как работу.

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

Перед откликами попросите знакомого разработчика открыть ваш профиль и сказать, что он видит за минуту. Если такого знакомого нет, проверьте сами по списку ниже, представив, что видите проект впервые.

• Понятно ли из первого экрана README, что это за проект и где его открыть?
• Что будет, если отключить интернет или API вернёт ошибку? Пользователь увидит сообщение или белый экран?
• Работает ли интерфейс на узком экране телефона без горизонтальной прокрутки?
• Можно ли пройти основной сценарий только с клавиатуры?
• Есть ли в коде огромные компоненты на сотни строк, которые стоит разбить?

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

Вас почти наверняка попросят рассказать про один проект. Подготовьте рассказ на две-три минуты заранее.

1. Какую задачу решает проект и почему вы за него взялись.
2. Какой стек выбрали и почему именно его.
3. Самое сложное место и как вы его решили.
4. Что бы сделали иначе сейчас.

Будьте готовы открыть код и объяснить любую строчку. Если в проекте есть кусок, скопированный из интернета, разберитесь в нём до собеседования. Вопрос «а почему здесь useMemo?» без ответа сильно снижает доверие ко всему портфолио.

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

• Десять незаконченных проектов вместо двух доведённых
• Проекты из курса без изменений и без пометки, что сделали вы
• Нет живой ссылки, только код
• README из шаблона генератора проекта
• Ключи API и пароли в открытом репозитории
• Код, который вы не можете объяснить

• Два-три проекта закреплены на GitHub
• У каждого живая ссылка, скриншот и README с разделом решений
• Работает на телефоне и с клавиатуры
• Есть формы, работа с API и обработка ошибок
• Коммиты по шагам с понятными сообщениями
• Готов рассказ про главный проект на две-три минуты

• Merge или rebase: что выбратьИнструменты
• Как бы ты построил CI/CD для проектаИнструменты
• Как написать хороший Dockerfile для NodeИнструменты
• Образ и контейнерИнструменты
• Линтер и форматтерИнструменты
• Чем rebase отличается от mergeИнструменты
• Когда нельзя делать rebaseИнструменты
• Как отменить коммит в общей веткеИнструменты
• Что значит ^ в версииИнструменты
• Blue-green деплойИнструменты

• Билеты с зачётом по технологиям из ваших проектов: JavaScript, React, TypeScript, вёрстка. Проверьте, что можете объяснить то, что написали.
• Задачи с кодом с автопроверкой в браузере: по три в день бесплатно. Хорошая разминка перед тем, как дописывать проект.
• Банк историй в кабинете: рассказ о проекте по STAR и питч. На бесплатном тарифе три истории.
• Чек-лист резюме: проверьте, что ссылки на портфолио стоят на видном месте.