×Закрыть

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

Эта статья о том, как начинающим разработчикам оформить профиль на 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.

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

Стало:

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

Источник: 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.

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

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

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

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

Источник: 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 ещё что-нибудь подскажет из своего списка.

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

Стало:

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

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

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

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

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

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

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

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

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

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

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

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

Зайдите в свой профиль сейчас, нажмите Customize your pins и добавьте хотя бы 2-3 самых показательных проекты. Затем в настройках профиля заполните всё, что возможно.

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

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

Код

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

Стиль кода

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

Так что «причешите» код, который планируете показывать. Линтеры вам в помощь (заодно научитесь настраивать, если ещё не умеете). Можно, не стесняясь, брать преднастроенные проекты — 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 — вам обязательно воздастся :-)

LinkedIn

53 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Що може сказати github про розробника, крім того що він бере участь в опенсорс-тусовці або не бере?

“if you change tabs to spaces, you will be fuckin killed” ©Microsoft code convention :-))

Ха-ха, не знал, прикольно 🙂. Я думал это просто повод торговаться на меньшую зп на собеседовании.

Например: «A movies database web application»

a movie database web application

всё остальное та же ж история давайте кратко у вас должен быть резюме с которого всё должно быть ясно больше ничего у вас быть не должно и сомнительно

если у вас действительно что-то стоящее напишите за это в резюме конечно если это действительно что-то стоящее сравнимое с преславутым «коммерческий опыт» если нет опять же ж никому оно не интересно даже там на самых начальных уровнях

ничего личного просто бизнес аукцион джунов по 100 человек на место никто никакие гитхабы читать просто не в состоянии селяви

Хтось може перевірити на скільки профіль github.com/OleksiyRudenko відповідає критеріям статті?

Я можу )
Так собі відповідає. Відсотків на 77. Але навіть при повній відповідності він мені і не допоможе, якщо я, раптом, вирішу змінити роботу.

Добрый день! Посмотрел ваше резюме на linkedin — похоже что у вас нету опыта разработки (уверен что для вас это не проблема) Как вы пришли к тому что у разработчика должен быть гитхаб профиль и почему резюме, тех задания и т.д. просто недостаточно? Мне кажется сейчас каждый джун знает что у него должен быть гитхаб профиль поэтому и заливают туда что попало и это не совсем работает так как интервьюеру хотелось бы. ИМХО.

А зачем те, кто заливает что-попало на GitHub тратят время интервьюера?

Что изменится от того что здесь будет хоть какой-то ответ?

Ничего, это был риторический вопрос.

Есть. Корректнее сказать, был. Указывать его для меня, считаю, нерелевантно.
Согласен с тем, что льют что попало. С другой стороны, новичкам тяжело понять, что именно работает и как это работает.

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

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

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

Там ,кстати, появились новые удобные фишки. Пока еще в бета режиме , но уже радует — встроенный прямо в GitHub редактор Visual Code и обсуждения.

Якщо є конкретні значні проекти чи контріб’юти в інші проекти — можна просто вказати в резюме окремою секцією і показати, якщо когось цікавить

В іншому разі всі ці красоти — хіба для джуніорів корисні на першу роботу

lil. bs. більшість пунктів пиртянуті за вуха.
Ви спочатку пройдіть HR з питанням чи ви англійською розмовляєте (це після лінкідіна де вказано що флєент). А вже тех спец МОЖЕ подивитись ваш гітхаб.

Ну або відразу пишіть ліду проекта на який вас намагаються захарити, тоді да — тоді гітхаб працює.

У вас дуже добре і зрозуміло оформлений профіль і титульні проекти.
Малоймовірно, що з метою пошуку роботи.
В яких випадках це працює для вас?

Іноді треба постукати в двері щоб зрозуміти що невідкриють.

З/И/ тримати гітхаб в порядку можуть люди в яких достатньо часу для/їх робота oss-проектів, які практикують continuous education (термін не дуже правильний) або просто вчаться. або їх компанія використовує gh ентерпрайз/органіхацію для роботи.

Камон, не все впирається в галери з ейчарами і багатьма левелами співбесід. Я за останній десяток років досить багато допомагав наймати людей невеликим компаніям та клієнтам інхауз, і в офіс, і ремоут. Допомагав формувати вимоги, фільтрував кандидатів та проводив технічну частину співбесіди. Резюме без лінків на репозиторії завжди одразу відкладав, міг до них повернутись на другому колі, якщо був дефіцит кандидатів. Якщо були лінки на гітхаб, але там нічого корисного — теж відкладав. Якщо на гітхабі був код, який чітко демонстрував відсутність навичок організованої роботи — відкладав. Коротше кажучи — люди, які мали нормальні профілі та проекти на гітхабі легко проходили первинну фільтрацію і часто були в результаті найняті. Просто приклад з реального життя за межами мікровсесвіту галер.

гггг. ти мене не взанав Ігорко?

З/И/
15 років тому я вже подавався в туж контору що і ти і без гітхаба ну ти вкурсі.

Звичайно впізнав)) Тому й написав, до речі)

Якийсь сенс очікувати шо девелопери будуть викладати щось на гітхаб, якшо це не PR в якийсь опенсорс-проект або власна утиліта, яку вони саппортять?

Відколи це Github став Behance’ом? Ніколи не сприймав його як місце цілеспрямованої демонстрації себе.

Можете не сприймати — ніхто не примушує. Я лише навів приклад з реального життя, тої його (величезної) частини яка знаходиться за межами вашого звичного та комфортного IT Bubble. Крім описаного мною кейсу є ще кейс джунів / трейні які активно шукають свою першу роботу. Та й взагалі реальний код, живі коміти та взаємодія з іншими в межах опенсорсу (навіть issues) теж багато про що говорять. Я не кажу що це обов’язково, і не кажу про очікування. Але те, що активний аккаунт на github може бути корисним в кар’єрі — факт. Особливо в кар’єрі за межами галер та в ремоут. І я навів конкретний приклад як кандидати без github можуть взагалі відсіюватися задовго до інтерв’ю.

Реальний код, живі коміти та опенсорс тусовка це нормально коли до того є потреба або зацікавлення в конкретних проектах. Але хіба варто писати в github тільки заради того шоб показати себе? Хіба дійсно для трейні.

Так ніхто ж не сперечається :) Так, для established девів це не обов’язково. Для тих кого цікавлять лише галери з печивом — теж, мабуть. Для деяких технологій / мов / стеків — очевидно, теж (для якихось більше, для якихось менше). Для джунів / трейні, щоб вигідніше себе продемонструвати — *може* бути корисним. Очевидно ж, що джун без досвіду роботи в конторі, але з реальними проектами (нехай і тестовими / навчальними), з комітами, з якоюсь кількістю starred repositories вже має певний досвід, можливо навіть більший і кращий ніж той, хто вже має півроку чи рік роботи в резюме, але без доказів. Хз що він там робив той рік? Чому його навчили? Що вміє? Які commit messages пише? А біс його знає. Все треба виясняти під час співбесіди. А якщо є реальний код на гітхабі — я по комітах навіть бачу хід думок, підхід до вирішення проблем (а це і є головний навик програміста).

Хіба дійсно для трейні.

Ну так автор в першому ж абзаці прямо про це й пише:

Статья будет полезна в первую очередь новичкам, ведь им сложнее других найти работу

А я вже додав свій юзкейс — для пошуку досвідчених девів, але ремоут та інхауз, за межами ІТ-галер.

Спасибо за статью!

Отличная статья!
Могу поделиться опытом жены, которая недавно искала первую работу и активно для этого занималась своим GitHub’ом.

1. Важно иметь титульный проект, закрепленный на главной странице. В нем должно быть все то, что указал автор. Плюс добавлю от себя: обязательное наличие Unit тестов (в случае iOS еще Snapshot и UI тестов) и крайне желательно наличие CI. CircleCI и Bitrise дают бесплатные минуты для open-source. Глупо не пользоваться. Как указал автор, отлично работают gif-скрины — даже если это просто консоль.
Пример: github.com/...​astasia-Petrova/Snapvideo

2. Как указал автор, можно и нужно вести свои учебные проекты на GitHub. Тут главное показать постоянство коммитов и рост культуры кода. Можно также заморочиться с CI, если есть покрытие тестами.
Пример: github.com/...​ty-iOS-Nanodegree-Program

3. Можно и нужно выкладывать все свои решенные задачи на LeetCode. Можно это оформить в виде простого To-Do списка.
Пример: github.com/...​nastasia-Petrova/LeetCode

4. Можно использовать pinned gist в виде виджета активности. Открытые PRы, Issue и т.д.
Пример: github.com/Anastasia-Petrova

5. Можно поддерживать CV в виде README файла прямо на GitHub. Markdown отлично подходит для оформления. Это удобно в качестве reference для инженеров-интервьюеров прямо во время интервью. Можно шарить экран и ходить по ссылкам не покидая GitHub. А PDF и Doc оставьте рекрутерам.
Пример: github.com/Anastasia-Petrova/CV

Нахиба это все нужно? Это реально помогает при поиске работы, во всяком случае на западе. Особенно первой или одной из первых.
Опять же, из свежего опыта жены — все ее интервью включали активное обсуждение ее кода и технических решений на GitHub. Это выводит интервью из типичной для джуниоров плоскости «чем интерфейс отличается от абстрактного класса» в плоскость диалога взрослых людей.

Это конечно хорошо, но когда вы сами причешите свой гитхаб?)

github.com/...​ctionViewController.swift

Ох, лучше не напоминай :)
Это говно, которое ни стереть, ни смыть.
Поэтому я и не предлагаю себя в качестве примера.
С другой стороны, для меня, в данный момент, это и не особо важно.

Очень хорошо оформлены репы — понятно, что из себя представляют проекты.
Репу CV, как вариант, можно переименовать в anastasia-petrova.github.io + в настройках поставить публикацию из мастера (хотя, для этой категории проектов эта фича может включаться автоматом) и оно сразу станет титульной веб-страницей её как разработчика.
Посмотрел коммиты Snapvideo — приятно глазу. Отличная культура разработки. Уверен, что и код тоже читабельный. Мои комплименты.
Остаётся только пожелать всяческих успехов.

Репу CV, как вариант, можно переименовать в anastasia-petrova.github.io + в настройках поставить публикацию из мастера

Интересно, надо глянуть. Спасибо!

CV на GitHub не лучшее решение. Часто требуется именно файл (например, в формате PDF). Так CV в виде файла загружается в профиль djinni.co. Кроме того, если хочется самому написать о себе в какую-то фирму, там как правило есть кнопочка «Загрузить резюме».

CV на GitHub не лучшее решение. Часто требуется именно файл

i.redd.it/rqe1sqh978c11.jpg

Вот дельное замечание. Почему-то чаще всего в комментариях встречается логика вида «... лучше Х вместо Y...» и «... Х вот вообще никогда-никогда не работает, уж лучше null»
И почти не встречается «... а ещё к этому можно дополнительно сделать Z».
Удивительно.

пошел смотреть как мой выглядит (уныл и давно заброшен)

Питання до автора, ви готові побачивши хороші приклади проектів на GitHub взяти спеціаліста на проект, без технічної співбесіди та тестового завдання?
(чи можлива ситуації що спеціаліст пройде тільки інтерв’ю з рекрутетом, а технічні вміння будуть підтвердженні GitHub-ом)

Звісно не готові, матимеш ті самі інтерв’ю, ще й отримаєш субєктивне фе, якщо хтось причепиться до твого нещасного петпроекту

отримаєш субєктивне фе, якщо хтось причепиться до твого нещасного петпроекту

Что замечательно! Потому что если «фе» будет конструктивным и предметным, то ты получишь отзыв и ревью. А если деструктивным и неадекватным — то красный флаг для компании. Зачем идти работать в говённом коллективе?

Замечательно це якщо після офера

А гавеним може бути просто один неадекват, якому пощастило скрінити кандидата

А гавеним може бути просто один неадекват, якому пощастило скрінити кандидата

Что может делать говённый неадекват в адекватном коллективе? Тем более состоящий в процессе найма (таких же неадекватов?).

Бутерброд с сыром, колбасой и говном — это просто говно.

Якщо на черзі 5 кандидатів, одне просте речення, що «ой код так собі» може коштувати кандидату всього подальшого процесу

одне просте речення, що «ой код так собі» може коштувати кандидату всього подальшого процесу

Если код действительно «так себе», то где здесь проблема? Инженерия, вроде как, про меритократию.
Те, у кого кода вообще нет, будут писать тестовое задание и их код точно также может оказаться «так себе» в глазах интервьюера.

Нє, дядя, інженерія, це про роботу над реальними продуктами, а не міряння в кого красівше гітхаб

А от інтерв’ю, з іншого боку, це тонка гра на виживання твого резюме серед потенційних конкурентів

Если твой поинт в том, что плохой код на гитхабе хуже, чем вообще никакого, то я согласен.

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

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

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

Для джунів — я згоден, це корисно

Для решти — саме так, якщо нема чим хвалитись, то краще не пробувати, тільки збільшує шанси на реджект

Я перебрав сотні резюме в різних командах в різних процесах

Повір, гамняне резюме, — ніхто навіть не дивиться на ті всі гітхаби, нормальне резюме гітхаба не потребує, але от ЯКЩО він вказаний, то будьяка лажа на будьчию думку, збільшить твої шанси не отримати

Я тебе запевняю, багатьом дуже навіть не подобаються рюшечки і надмірна концентрованість на гітхабі — це сприймається як ознака, що ти не будеш сконцентрований на основній роботі

Я вважаю, що самого тільки гарного резюме — недостатньо. Так само, самих тільки працюючих і зрозуміло написаних проектів, а рівно і оформлення доки — теж недостатньо. Можу тільки сказати, що в сукупності — це велика перевага.
Тех.співбесіда, це не тільки про код та «письмову» комунікацію, але ще й про навички усної комунікації, culture fit і все таке інше «софтове». IMHO.
Дякую за запитання.

Я вважаю, що самого тільки гарного резюме — недостатньо.

це лише бізнес якщо «гарнього резюме не достатньо» ви просто робите щось не так і десь поряд з вами у черзі стоїть той чийого «гарнього резюме вже достатньо» і з більшою ймовірністю виграє саме він просто тому що це усього лише бізнес

Тех.співбесіда, це не тільки про код та «письмову» комунікацію, але ще й про навички усної комунікації, culture fit і все таке інше «софтове». IMHO.

важко реально очікувати «і все таке інше» від джуна з гітхабом і відповідно безглуздо так само важко очікувати вже від себе самого що за скромних 1-2 години реальної співбесіди середньої національної галери можна буде досконало виявити «і все таке інше» від будь кого будь якого іншого рівня для цього всього просто є випробний термін і от тут вже має піти саме «навантаження» частина якого будуть прямими тест-маркерами «о норм чувак впорався нічого не запартачив нікому не встиг набриднути і не позадавати тупих питань значить нормальний чувак можна брать»

щоб все це бодай трохи оцінити з більш-менш цінного хітхабу реального проекту треба у тому всьому покопирсатися бодай годину і то за наявності певних навичок оцінки та розуміння того що саме маркерами чого саме у тому копирсанні є

і це звісно за умови таки реально реального проекту а не «студентської лабораторної»

А чим тестове крудоподібне завдання краще проектів на ГХ? Так і уявляю ситуацію, як ти співбесідуєш Чейні, даючи йому ТЗ запилити рест сервіс.
Завжди веселив такий підхід.

Вважаю, що гарні pet-проекти на GitHub-і можуть замінити тестове і більше розповісти про спеціаліста, а технічна співбесіда буде більше про життя та які цікаві задачі вирішував

Вибач, я думав ти з табору «ви нам не підходите, бо з Спрінг 5.5.25 не працювали, а ваші коміти в ядро нас не цікавлять». :)

хотя-бы тем, что на гитхаб можно увидеть историю комитов, как истории разработки

Так я ж за ГХ. ;)

Подписаться на комментарии