Перевод статьи «New Dev? Job-Hunting? Avoid These GitHub Mistakes!».
За последние недели ко мне обратились сразу несколько разработчиков, находящихся в поисках своей первой работы. Они просили проверить их резюме и портфолио, а также посоветовать, как можно улучшить их профили на GitHub. Основные проблемы, обнаруженные мной, встречались в большинстве просматриваемых мной профилей. Поэтому я решила написать эту статью с советами о том, как программисту создать интересный GitHub-профиль.
Реальность такова, что рынок труда для начинающих разработчиков очень конкурентный, и конкуренция постоянно возрастает за счет усердной работы все новых курсов по программированию, которые ежемесячно пополняют армию новичков. Я думаю, что в таких условиях время, потраченное на создание уникального, информативного профиля, будет потрачено не зря.
Ошибка №1. Включение в свой GitHub-профиль всех созданных вами приложений
Думаю, люди так поступают из убеждения, что чем больше приложений они создали, тем более компетентными и разносторонними покажутся работодателям. Однако, размещение в профиле на GitHub всех созданных приложений имеет обратный эффект: кандидат кажется ненадежным и несфокусированным. Поэтому приложения для своего профиля нужно придирчиво отбирать. Руководствуйтесь следующими критериями:
- Приложения, размещенные в вашем профиле, должны демонстрировать ваш рост как разработчика. Для этого можно включить две итерации одного приложения: первая будет содержать код, написанный на заре вашего ученичества, а во второй код будет со всеми улучшениями и проведенным рефакторингом. В README улучшенной версии расскажите, какие изменения вы внесли и почему.
- Приложения должны демонстрировать результаты вашей борьбы с трудностями, с которыми вы сталкивались во время учебы.Включите в ваш профиль приложения, которые вам было тяжело создавать, и задокументируйте трудности, которые вы преодолели, в файлах README. Эти приложения послужат прекрасной темой для обсуждения на собеседованиях.
- Приложения в профиле должны показывать ваше умение комбинировать разные функции и заставлять их слаженно работать вместе. В портфолио начинающих разработчиков часто можно увидеть приложения, каждое из которых показывает реализацию какого-то конкретного функционала. Например, в одном приложении реализована аутентификация, в другом — чат между пользователями. Я советую включить в свой профиль приложение, где реализованы и слаженно работают разные функции. Это будет больше похоже на те приложения, с которыми вам придется иметь дело на будущей работе.
- Приложения в профиле должны показывать вашу увлеченность и интерес к разработке. Это позволит вам выглядеть уверенно и увлеченно, когда будете обсуждать свои приложения на собеседовании. Если приложение не вызывает у вас желания его обсуждать, не включайте его в свой профиль, насколько бы сложным технически оно ни было.
Ошибка №2. Пустые, дефолтные или скудные README-файлы
Когда кто-нибудь заходит в ваш GitHub-репозиторий, он видит название проекта и столбец папок. Большинство пролистывает вниз до раздела README, и зачастую только лишь для того, чтобы найти там пустой файл или дефолтный README-текст от GitHub. Все эти люди могут так никогда и не узнать, какой потрясающий код скрывается в этих папках, а все потому, что ваш README-файл произвел неблагоприятное впечатление.
Если вы находитесь в поисках работы, вы заинтересованы в том, чтобы сделать процесс знакомства с вами как можно более простым. Ваши README-файлы это ваша возможность рассказать историю, которая поразит эйчара и заставит его захотеть познакомиться с вами поближе. Я считаю, что README-файл для каждого проекта, размещенного вами на GitHub, должен содержать следующие пункты:
- Причины создания приложения. Тут не нужно ничего сверхъестественного, никто не ждет, что вы собирались спасти мир при помощи своей программы. Это должно быть простое пояснение того, почему вы решили потратить какое-то время именно на это приложение. Возможно, вы хотели изучить новую библиотеку. Или создать специальное приложение для пожилых собачников.
- Список функций приложения. Просто маркированный список того, что делает ваше приложение.
- Возникавшие проблемы и реализованные решения. Здесь мы возвращаемся к вопросу качества приложений, размещаемых в профиле. Я уверена, что если при создании приложения вы не сталкивались ни с какими трудностями или вообще делали все по туториалу, то такое приложение не следует включать в свой профиль. Там должны быть только те приложения, создание которых потребовало усилий и которые показывают вашу стойкость в борьбе с трудностями. А все эти трудности должны быть описаны в README (но не слишком подробно, не надо писать роман).
- Инструкции по локальному разворачиванию приложения. Чаще всего менеджеры по найму такого не делают, но есть отдельные энтузиасты, которые могут захотеть развернуть приложение кандидата локально, попробовать сломать его и на основе всего этого составить вопросы для собеседования. Поэтому я рекомендую описать простые шаги для воспроизведения вашего приложения в локальной среде. Обязательно укажите ограничения относительно операционных систем или связанного ПО.
Ошибка №3. Включение приложений, не развернутых онлайн
Как я уже сказала, довольно мало менеджеров попытаются развернуть ваше приложение локально. Но большинство из них хотели бы «пощупать» вашу программу и протестировать ее функционал. Неразвернутые приложения это друзья-товарищи ненаписанных README. Не разворачивая свое приложение, вы опять-таки упускаете возможность заинтересовать менеджера и продемонстрировать свои навыки. Поэтому, пожалуйста, разворачивайте все, что выкладываете на вашем GitHub.
«Но что, если мое приложение главным образом касается бэкенда?» Не проблема! Реализуйте самый минимальный фронтенд, разверните приложение и поясните в README, что в этом приложении вы фокусировались исключительно на бэкенде, а его фронтенд не предназначен для демонстрации ваших навыков и служит лишь для доступа к функционалу бэкенда.
Как насчет незаконченных или заброшенных приложений?
Несколько разработчиков, чьи профили я просматривала, были не согласны с моим советом размещать на GitHub только высококачественные приложения. «Но я же сейчас работаю над несколькими проектами и они еще не закончены! Где же мне их размещать?» Ну, есть несколько способов отделить ваши завершенные приложения, готовые к показу, от тех, над которыми вы еще работаете.
- Закрепите ваши приложения, готовые к показу, в вашем GitHub-профиле. Кликните «Customize Your Pins» под «Popular Repositories», затем выберите до 6 приложений, которые должны отображаться. Любой человек, попавший на вашу страницу, первыми увидит именно эти приложения.
- Приставка для незаконченных приложений. Добавляйте приставку «In Progress» или какую-то другую пометку к незавершенным приложениям. При таком подходе вы покажете, какие приложения все еще в процессе работы (и, следовательно, должны игнорироваться или просматриваться, но с поправками на их незавершенность).
ПРИМЕЧАНИЕ: изначально я советовала завести 2 аккаунта на GitHub: один для проектов, которые вы хотите показывать (разной степени завершенности), и второй для всех остальных. Но, поразмыслив над возражениями в комментариях, я решила этот пункт все же убрать.
Примечание редакции: В комментариях читатели отметили, что слишком «прилизанный» аккаунт вызывает подозрения. Разработка это путь как побед, так и поражений, причем последние позволяют приобретать опыт и расти над собой. Когда у разработчика есть незавершенные и даже заброшенные проекты, это нормально, так что не стоит их прятать. Но следует быть готовым к вопросам о том, почему вы эти проекты забросили.
Итоги
Ваш выбор приложений для профиля должен отражать историю, которую вы хотите рассказать, и показывать навыки разработчика, которые вы хотели бы продемонстрировать (причем они не должны напоминать универсальный швейцарский нож).
Ваша цель — убедить менеджера по найму, что вы — ценное приобретение для их команды разработчиков. Поэтому выбирайте приложения, доказывающие вашу способность эффективно находить и внедрять технические решения, а также ваше умение работать самостоятельно и мотивировано.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]