Портфолио начинающего специалиста: что показать, если коммерческих кейсов ещё нет

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

Выберите законченный фрагмент

Для первого кейса подойдёт небольшой сервис, страница вымышленного продукта с явной пометкой «учебный проект» или улучшение открытого проекта. Не выдавайте концепт за заказ реальной компании. Законченная небольшая работа даёт больше поводов для разговора, чем обещание огромного приложения.

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

Объясните решения

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

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

Подготовьте проект к просмотру

У разработчика полезны понятный README, инструкция запуска и описание ограничений. GitHub позволяет представить информацию о себе в README профиля; используйте его как короткую точку входа к работам. Документация GitHub о профиле.

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

Не придумывайте показатели

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

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