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

Все связывают портфолио с визуальным представлением ваших навыков, и это тривиально сделать, если вы разработчик, работающий с визуальными элементами, например FrontEnd-разработчик.

Но что произойдет, если вы работаете исключительно на BackEnd? Как сделать так, чтобы API, микросервис или библиотека OSS «выглядели красиво»?

Вы не можете.

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

Что есть в портфолио?

Давайте разберемся с самым основным вопросом: что такое портфолио?

Портфолио — это, по сути, способ продемонстрировать свои навыки и свою работу.

Что это такое? У вас нет работ для демонстрации? Не проблема, мы это тоже учтем.

Дело здесь не в «работе», а в том, что своей работой вы демонстрируете свое мастерство. И это должно быть вашим фокусом: навыки.

Вы хотите, чтобы люди, просматривающие ваше портфолио, поняли, на что вы способны. Так что не имеет значения, создали ли вы API, который подключается к Google Maps, или просто свой заурядный API погоды. Дело в том, что вы знаете, как взаимодействовать со сторонними API.

И это то, на чем будет сосредоточено наше внимание.

На каких навыках следует сосредоточиться?

Говоря о фокусе, какие ключевые навыки каждый бэкенд-разработчик должен выделить в своем профиле?

Ну, если вы спросите меня, я бы попытался сосредоточиться на следующих пунктах:

  • Язык серверной части. Это базовый язык, вы не сможете создать портфолио, чтобы продемонстрировать свои навыки работы с серверной частью, если вы знаете только HTML и CSS (например). Тем не менее, вам повезло, так как большинство языков дружественны к серверной части. Пока у вас есть проекты, использующие любой из следующих компонентов, все в порядке: Node.js, Python, PHP, Ruby, Go, Rust, Clojure и вообще все что угодно.
  • Моделирование данных. Я имею в виду тот факт, что вы знаете, как мыслить с точки зрения хранения данных. Другими словами, можете ли вы взять проблему и превратить ее в данные? Вы можете создавать таблицы базы данных? Или закодировать результаты в удобном формате (например, CSV, JSON и т. д.)? Можете ли вы создать сложную модель данных, в которой разные сущности связаны друг с другом? Вы знаете, что такое ER-диаграмма? Затем используйте его в качестве наглядного пособия для вашего портфолио.
  • Шаблоны проектирования. Хотя шаблоны проектирования применимы для любого контекста, они весьма полезны и актуальны в серверной среде. Вот почему важно показать, что вы знаете о них. Хотя какие? Это зависит от вас, их много и количество не очень важно, просто то, что вы знаете о них и умеете использовать их в своем коде.
  • Архитектурные шаблоны: это, вероятно, не является жестким требованием, особенно если вы играете младшую роль. Однако, если вы знаете о шаблонах, таких как MVC, распределенные микросервисы и т. д., всегда полезно выделить их. Как бэкенд-разработчик, вы в конечном итоге будете иметь дело с такими шаблонами, и показать, что вы можете с ними справиться, всегда хорошо.
  • SQL. В сочетании с вашими навыками моделирования данных, демонстрирующими, что вы знаете, как получать данные из базы данных SQL (вероятно, это самый распространенный тип хранилища данных), это отличный навык для сосредоточиться на. Скорее всего, вы будете использовать его в будущем.
  • Понимание парадигмы клиент-сервер. Это то, что вы будете использовать довольно часто как часть своей внутренней роли. Важно понимать, как выглядит запрос от вашего клиента и каков ответ. Используете ли вы HTTP (что является очень распространенной практикой в ​​​​бэкэнд-разработке)? Затем вам лучше показать, что вы знаете, что такое запрос, как отправить его в другую службу и каковы обычные характеристики HTTP (такие как коды ответа, глаголы и т. д.).

Вы определенно можете продолжать добавлять новые навыки, но пока у вас есть все вышеперечисленные (за исключением архитектурных шаблонов, которые я считаю необязательными), вы доказали, что являетесь бэкенд-разработчиком для тех, кто хочет вас нанять. .

Следующий большой вопрос: где вы можете создать портфолио?!

Где вы создаете портфолио?

Как только вы знаете, на чем сосредоточиться, следующий большой вопрос — куда это поместить. Хип, который, пожалуйста, используйте прямо сейчас, — это ваш собственный профиль на Github. В конце концов, вы в основном будете публиковать общедоступные репозитории, и если у вас есть доступ к Github (некоторые страны не имеют), то вы, вероятно, будете иметь весь свой достойный показа код там. .

Если это ваш случай, то, возможно, рассмотрите возможность просмотра следующего видео о том, как настроить свой профиль:

Теперь, если у вас нет учетной записи Github или по какой-то причине работа, которую вы хотите показать, отсутствует, вы можете использовать любую платформу для ведения блога. Просто убедитесь, что это что-то, что позволяет вам настроить его как можно больше. Избегайте таких платформ, как Medium, Hashnode и Dev.to, так как они позволяют вам делиться только письменным контентом.

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

  • Название проекта.
  • Набор используемых технологий.
  • Небольшое описание о нем с указанием извлеченных уроков и трудностей, обнаруженных в процессе.
  • Любая дополнительная документация, которая может оказаться уместной (например, добавление ER-диаграмм, если это применимо здесь).

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

Наконец, какими вещами, по вашему мнению, вы можете поделиться в своем репозитории? Давайте поговорим об этом.

Что вы можете показать?

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

Теперь, какой контент вы должны добавить в свое бэкэнд-портфолио? Смотря как. Над какими типами проектов вы работаете?

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

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

  • Контент. Будь то письменный контент в виде статей или книг, видео на YouTube или даже подкаст. Пока вы делитесь своими знаниями, вы можете позиционировать себя как человека, которого стоит нанять. На самом деле, вы можете позиционировать себя как лидера отрасли или «идейного лидера» (как бы вы ни ценили этот термин).
  • Над чем вы сейчас работаете? У вас может не быть проектов для показа, но потенциально вы можете над чем-то работать. Может быть, вы создаете свою первую библиотеку OSS? Возможно, вы работаете над идеей SaaS. Что бы это ни было, если вы пишете код, то говорите об этом! Поделитесь своим опытом, расскажите о своих планах проектирования и поделитесь любыми схемами или идеями. Все, о чем стоит поговорить, должно быть частью вашего портфолио. Это может сказать тому, кто читает это, что у вас есть план и что вы активно работаете над собой.

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

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

У вас есть бэкенд-портфолио? Поделитесь им в комментариях, чтобы вдохновить других!