Как оформить профиль на GitHub так, чтобы он работал при поиске работы

Kate

Administrator
Команда форума
Эта статья о том, как начинающим разработчикам оформить профиль на GitHub так, чтобы он стал дополнительным преимуществом на собеседовании. Статья будет полезна в первую очередь новичкам, ведь им сложнее других найти работу. Опытные специалисты тоже, надеюсь, найдут в этом материале для себя ценные соображения и практики.

Я уже более 15 лет управляю процессами создания продуктов — от гипотез до устойчивых продаж. Последние два года вместе с fellow kottans помогаю новичкам и свитчерам приобретать новые технические скиллы в разработке, развивать soft skills и находить первую работу в IT. Часто вижу у людей проблемы с презентацией своих навыков и личных проектов, в частности профиля и репозиториев на GitHub, поэтому и решил написать этот материал.

Сразу договоримся о контексте: речь будет идти о настройке профиля на GitHub для поиска работы.

Нужно ли это​

Чаще всего от кандидата на позицию разработчика ожидают определённого уровня технических знаний. Новичкам особенно тяжело: практики мало, опыта прохождения технических интервью тоже не хватает или совсем нет. А ещё прескрининг... Код кандидата, написанный до интервью, может стать конкурентным преимуществом. Тестовые задания дают не только для того, чтобы проверить умение писать алгоритмы и оперировать структурами данных, но и чтобы увидеть подходы к решению задачи, структуру проекта и код. Любой код, доступный на этапе прескрининга, может стать предметом изучения интервьюеров ещё до первой встречи. И кто знает, возможно, вам дадут меньше тестовых заданий или вовсе обойдутся без них. А тесты — это же всегда стресс, сказывающийся на качестве работы.

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

Существуют различные взгляды на открытые портфолио проектов на облачных VCS (GitHub, GitLab и подобных). Многие опытные разработчики считают, что на профиль никто не смотрит (см. Простое решение). Для некоторых тим- и техлидов увидеть code style и способ организации кода в проекте (особенно в отношении кандидата-джуна) лучше, чем услышать 1000 слов на собеседовании. Правильное оформление профиля и двух-трёх наиболее показательных репозиториев на GitHub поможет обойти конкурентов. А когда по итогам цикла собеседований остаётся несколько равноценных кандидатов, то каждый бит информации может оказаться решающим — в том числе и проекты на GitHub.

Во всяком случае, если уж и указывать линк на GitHub-профиль в резюме, то точно есть смысл помочь ревьюеру увидеть самое главное.

Конечно, первое, что увидит ревьюер, — титульная страница профиля, с которой его нужно провести на конкретный проект или проекты. Тут все должно быть информативно и удобно.

Если профиль пустой, возникает закономерный вопрос: зачем в резюме добавлена ссылка на GitHub-профиль и почему в списке проектов — пусто? Ответ «Ну, если надо, то добавлю» — плохой.

Начнём с проектов.

Что показать, если показать нечего​

Никто (sic!) не ожидает увидеть уникальный проект на 100500 строк кода. Оценивать, скорее всего, будут уровень владения шаблонами проектирования, стиль кода, способность написать минимальную документацию, навыки работы с Git. Почему это всё важно? Потому что это о коммуникации. Это то, чего будут ожидать от сотрудника, помимо написания собственно кода. Код пишется в первую очередь для других людей.

Разумеется, могут оценить и уровень владения технологиями. Одно дело — прочитать в резюме «CSS3 — средний» или услышать ответ на вопрос «А что ты умеешь в JavaScript?». И совершенно другое — увидеть в репозитории хорошо читаемый код, отражающий действительные технические навыки.

Оговорка для педантов: ясно, что обмануть можно и там, и там. Но в этой статье речь не об этом классе проблем.

Выберите два-три проекта, которые наилучшим образом отражают ваши навыки. Учебные тоже годятся (быстро допили незаконченные). Или добавьте одну-две простых игры типа крестики-нолики, Frogger или Memory Game. Все новички делают что-нибудь такое, но не все завершают и показывают. Не ищите оригинальности — это всё ради демонстрации навыков и умений. Демо не обязательно должны быть сложными, с анимациями, встроенным видео и миллионом визуальных эффектов. Достаточно одной фишки.

Вот отличный пример работы студентки курса по фронтенду, а теперь разработчицы в MacPaw Mary Fedirkoпогодное радио (нажми кнопку ON). В этом проекте она продемонстрировала творческий подход не только к написанию «очередного JS-фреймворка», но и к дизайну и внешнему представлению в целом. Нестандартный вид учебного проекта — это и дополнительная мотивация в процессе выполнения (делать подобные интерфейсы в разы интереснее), и повышение вероятности того, что на такой проект работодатель обратит внимание.

Было бы здорово, если бы кто-то сделал ревью вашего кода.

Некоторые разработчики советуют раскрывать в резюме участие в проектах с открытым кодом. А для этого нужно поучаствовать в таких проектах :) На самом деле это не очень сложно и даже можно найти материалы и поддержку в этом процессе.

Ещё один источник проектов — хакатоны. Онлайн, оффлайн, локальные/международные — выбирайте на свой вкус. Их ежемесячно проводятся десятки. Кроме того, указание хакатонов и митапов в резюме — ясный индикатор заинтересованности в профессии.

Еще один совет: лучше учебные репы, чем ноль реп. При прочих равных условиях кандидат с даже «примитивными» проектами выигрывает у кандидата с отсутствующими общедоступными следами деятельности. Репозитории можно удалять, архивировать и сделать приватными — так профиль со временем будет становиться всё более профессиональным.

Оформляем репозиторий​

Цель оформления репозитория — показать товар «лицом». В этом контексте проигрывают те, кто оформляет проект в стиле «сами разберитесь, как моё приложение запустить, чтобы увидеть, как оно работает». Потому что это всё может быть очевидно для автора, но не для стороннего наблюдателя.

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

Краткое описание и ссылка на публикацию​

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

Начать просто — нажмите кнопку Edit.

Например, было:

image13_ChI9LFH.png


Стало:

image11_miqC6hc.png


В вебе выглядит так:

image5_LY0ZSMY.png
Источник: kottans stats by Igor Kurkov

Из Description, кстати, формируется содержание тега <title> страницы проекта, if you know what I mean.

Документация​

Чаще всего README.md содержит одну только строку: # project-name.

Что должно быть в README.md:

  • О чём проект? Например: «A movies database web application», «Rick and Morty universe REST server».
  • Зачем этот проект? Например: «I mastered CSS animations, CSS Grid, CSS Flexbox» (пункты, разумеется, оформить отдельными буллет-поинтами).
  • Ссылка на демо (да-да, ещё раз повторить то, что уже есть в описании — overcommunication не грех).
  • Инструкции по сборке и запуску проекта. Это вот всё git clone … , yarn build … и прочее — как во взрослых проектах.
  • Структура проекта, архитектура приложения, API — это тоже показывает навыки, необходимые разработчику.
Пишите всё это в синтаксисе markdown. Так мы демонстрируем владение ещё одним полезным навыком.

Цель этого не только дать читателю хорошее представление о проекте, но ещё показать отношение к документированию (не любить писать документацию можно будет потом) и базовые навыки подготовки документации. Смотрите, например, учебный проект с использованием The Movie Database API.

image3_vtnopEY.png
Источник: Movie Database by Vlad Vorobiov

Кстати, сделать из такой документации сайт может быть актуально для не-фронтенд-проектов — документация без лишних элементов интерфейса GitHub читается лучше. Это довольно просто: нужно в настройках включить публикацию.

image2_Xr3miri.png


image9_RnRr4CX.png


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

Вот так README.md может выглядеть, когда опубликован:

image8_5z8uP7e.png
Источник: Git course. Проект на GitHub

Продвинутые техники​

Скриншоты, скринкасты​

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

А скринкаст в виде гифки сделает демо ещё более наглядным. Пример: описание задачи в курсе по фронтенду. Гифку лучше захостить за пределами GitHub, допустим, на imgur.

Чем сделать такую гифку? Например, oCam for Windows. Можно записать скринкаст с помощью QuickTime для Mac или встроенными средствами Windows 10 (Win+G) и затем сконвертировать с помощью MOV to GIF или MP4 to GIF.

Для записи работы в терминале хорошо подходит asciinema.

Topics​

На будущее: topics помогают проекту появиться в поисковых запросах. Какие ключевые слова вписывать? Начните с используемых в проекте технологий: JavaScript, ReactJS, Python, Java, C#, Laravel, PHP, REST, MongoDB, Node, PostgreSQL, SPA, web app, AMP, CSS, HTML... Добавьте два-три ключевых слова о самом проекте: game, casual game, database, movies, weather, demo, educational, tutorial... GitHub ещё что-нибудь подскажет из своего списка.

Например, было:

image6_6tmxXVd.png


Стало:

image7_zycdirF.png
Источник: React patterns, demo by Vitalii Ovcharenko

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

Промежуточный summary​

На хорошо оформленный репозиторий можно дать прямую ссылку в резюме. Указывайте ее прямо в разделе Skills или Education — где релевантно. Это должна быть ссылка не такого вида github.com/username/repo, а аккуратная и лаконичная, хоть и выглядящая немного «по-инженерному», например: react-patterns project. Тут реальный путь скрыт за описанием проекта. Щёлкать по линкам уж все умеют, а читабельность заметно лучше.

Оформляем профиль​

Титульная страница профиля на GitHub позволяет быстро оценить активность пользователя. Для ее оформления также можно использовать альтернативную визуализацию (на примере профиля Bohdan Kovalchuk) — прямо берите и вставляйте в резюме чарты.

image4_l1OCYYv.png


Но давайте сравним два профиля на GitHub.

Невыразительный:

image12_6uil1Im.png


Информативный:

image10_vo7VmJA.png
Источник: профиль на Github by Aleksey Ivanov

Чем отличается второй:

  • не рандомная аватарка;
  • есть имя (если профиль — ваше резюме, то чего стесняться?);
  • статус явно говорит о том, что Алексей открыт к предложениям о работе;
  • коротко описаны скиллы (Front-end, React, NodeJS);
  • есть ссылка на профиль в LinkedIn;
  • есть 6 отобранных проектов, с которых заинтересованный посетитель и начнёт изучение портфолио.
Зайдите в свой профиль сейчас, нажмите Customize your pins и добавьте хотя бы 2-3 самых показательных проекты. Затем в настройках профиля заполните всё, что возможно.

Делаем личное портфолио на GitHub​

Знаете ли вы, что проект вида username.github.io после публикации доступен, собственно, под таким именем? Вот пример личного сайта-портфолио (проект на гитхабе, Ruslan Sakevych):

image1_fWYBvxS.png


Код​

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

Стиль кода​

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

Так что «причешите» код, который планируете показывать. Линтеры вам в помощь (заодно научитесь настраивать, если ещё не умеете). Можно, не стесняясь, брать преднастроенные проекты — Open Source. Например, ESLInt-Prettier-Husky boilerplate для JS фронтенда или EodData CLient (Python, Aleksey Ivanov). Для вашего стека придётся поискать или поспрашивать кого-нибудь.

Коммиты​

Комментарии коммитов тоже пишутся для других людей. Комментарии вида «added file», «fixed», «add code» и подобные (осторожно, вредные советы!) говорят о недостаточно хорошо развитых навыках изложения мысли и нелюбви к людям, которые будут читать ваш код. Самое время приобретать правильный навык. И лучше немного помучаться над текстами коммитов в учебных или пет-проектах, чем потом выслушивать от старших по званию коллег ворчливые замечания или вообще не найти желающих сделать код ревью.

Вот один из примеров читабельной истории коммитов: frontend project lvl1 by Sergey Shramko.

Простое решение​

Чтобы не заниматься всем вышенаписанным, можно просто никому никогда не признаваться в наличии профиля на GitHub. Нет материала — нечего критиковать.

Вот даже говорят, что это всё бесполезно: почему GitHub не поможет нанять разработчика / Хабр

Выбор — за вами.

Итого​

GitHub-профиль работает и помогает — когда он есть. Оформить его аккуратно — означает позаботиться о тех, кто будет его изучать в процессе прескрининга и собеседований, и, следовательно, о себе как о конкурентоспособном кандидате.

Свидетельства «очевидцев» из числа моих знакомых разработчиков-новичков:

Евгений, Front-end Developer: «У меня спрашивали про самый интересный проект: что делает, почему так, логику и связи модулей. Ещё открывали другой проект и по нему тоже задавали вопросы. Я уже пару месяцев как трудоустроился. По моему мнению, что сработало: 1. Множество тестовых задач с других собесов, часть из которых опубликовал на гитхабе; 2. Собственные нетипичные и работающие микропроекты».

Лена, Front-end Developer: «Задавали вопросы по моим проектам на нескольких собеседованиях. Смотрели портфолио. На одном просили прокомментировать самый интересный проект из примеров на гитхабе».

А у вас когда-нибудь смотрели портфолио? Помогало ли портфолио при поиске работы?

Что ещё почитать по связанным темам​

Credits​

Спасибо команде kottans и персонально Christina Landvytovych, Oleksandr Lapshyn за поддержку и contribution в материалы статьи.

В качестве иллюстраций здесь используются проекты разработчиков, которые так или иначе имеют отношение к комьюнити kottans. Если вам какой-то из проектов понравится, не пожалейте поставить ⭐ на GitHub — вам обязательно воздастся :)


 
Сверху