Как использовать GitHub для поиска разработчиков

Содержание
  1. Введение в GitHub для разработчиков
  2. Почему GitHub?
  3. GitHub Issues
  4. Социальное кодирование
  5. Запросы на включение (Pull requests)
  6. Управление проектами (Project management)
  7. Сравнение коммитов
  8. Webhooks и Services
  9. Заключение
  10. Как оформить профиль на GitHub так, чтобы он работал при поиске работы
  11. Нужно ли это
  12. Что показать, если показать нечего
  13. Почему GitHub не поможет нанять разработчика
  14. Разреженность данных
  15. GitHub показывает только вклад в open source
  16. Большинство проектов GitHub не впечатляют
  17. Число фоловеров показывает популярность, а не талант
  18. Интервьюеры не проверяют профили GitHub
  19. GitHub: Инструкция для нетехнических специалистов
  20. В чем смысл OpenSource?
  21. Терминология в контексте GitHub
  22. GitHub, как средство получения информации
  23. Информация о развитии GitHub
  24. Данные о развитии технологий
  25. Показатели уровня разработчика
  26. Профиль Линуса Торвальдса, основателя Линукс и создателя Git
  27. Гитхаб — не только для программных продуктов
  28. Государственные законы на GitHub
  29. Как предприниматель может использовать Github
  30. Инструкция по GitHub для рекрутеров: как найти того, кто вам нужен
  31. Как GitHub может помочь найти специалистов?
  32. Пошаговая инструкция: как искать специалистов в GitHub
  33. 1. Регистрация
  34. 2. Поиск по ключевым словам
  35. 3. Поиск по языкам программирования
  36. 4. Поиск по технологиям
  37. 5. Отслеживание активности 
  38. 6. Коммуникация
  39. Как заинтересовать кандидата?
  40. 1. Рынок подстраивается под IT-специалиста, а не наоборот
  41. 2. Работу в вашей компании нужно продавать
  42. 3. Специалист может не проявлять энтузиазма
  43. Почему важно рекрутить на GitHub?

Введение в GitHub для разработчиков

Как использовать GitHub для поиска разработчиков

2 января 2019 Антон Кулешов Перевод 2872 0

Короче говоря, это платформа для разработчиков программного обеспечения, основанная на GIT.

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

Почему GitHub?

Теперь вы знаете, что такое GitHub и наверняка задаетесь вопросам – зачем мне его использовать и как?

В конце концов, GitHub управляется частной компанией, которая получает прибыль от размещения чужого кода. Так почему вы должны использовать этот сайт вместо аналогичных платформ, таких как BitBucket или GitLab?

Помимо личных предпочтений и технических причин, есть одна значимая причина: все используют GitHub, поэтому сетевой эффект огромен.

Со временем основные кодовые базы были перенесены из других систем контроля версий в GIT из-за его удобства. GitHub исторически находится в выгодном положении и прилагает много усилий для удовлетворения потребностей сообщества открытого исходного кода.

Сегодня, когда вы будете искать какую-либо библиотеку, вы в 99% случаев найдете ее на GitHub.

Помимо открытого исходного кода, многие разработчики также размещают частные репозитории на GitHub из-за удобства платформы.

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

GitHub Issues

GitHub Issues – одна из наиболее популярных в мире систем отслеживания багов.

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

Если вы найдете проблему в проекте, управляемом кем-то другим, она будет открытой до тех пор, пока вы не закроете ее (например, если выясните, в чем заключается проблема) или пока владелец репозитория не закроет ее.

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

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

Но некоторые репы с открытым исходным кодом публикуются компаниями, которые предоставляют услуги для этого кода.

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

Социальное кодирование

Несколько лет назад в логотип GitHub входил слоган «социального кодирования».

Что это значит? Важен ли сейчас этот слоган? Конечно.

Подписки (Follow)

На GitHub можно подписаться на разработчика или репозиторий, зайдя в профиль пользователя и нажав «Подписаться» или нажав кнопку «Следить» в репозитории.

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

Звезды (Stars)

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

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

Крупные проекты могут иметь десятки тысяч звезд.

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

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

Ответвления (Fork)

Последний важный сетевой индикатор проекта — это количество ответвлений.

Это ключ к тому, как работает GitHub. Ответвление — это основа запроса на включение (PR), который является предложением об изменении. Человек может добавить ответвление к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения в исходник.

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

Чем популярнее, тем лучше

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

Запросы на включение (Pull requests)

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

Проект может иметь сотни PR. Как правило, чем популярнее проект, тем больше PR. Например, в проекте React:

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

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

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

Это означает, что запрос на включение не всегда принимается быстро. Нет никакой гарантии, что запрос когда-либо будет принят.

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

Управление проектами (Project management)

Наряду с issues, благодаря которым разработчики получают обратную связь от пользователей, интерфейс GitHub предлагает и другие функции, позволяющие управлять проектами.

Одна из них – Projects. Это новый раздел, который очень редко используется. Это система «Канбан», которая помогает организовать баги и работу, которую необходимо выполнить.

Wiki предназначена для использования в качестве документации для пользователей. Одним из наиболее впечатляющих применений Wiki, которое я видел, является GitHub Wiki языка программирования Go.

Также в управлении проектами помогают контрольные точки. Это часть страницы issues. Вы можете соотнести проблемы с определенными контрольными точками, которые могут быть целями релизов.

Представив релизы, GitHub расширил функциональность тегов GIT.

Тег GIT — это указатель на конкретную версию. Если он выполняется последовательно, то помогает вам вернуться к предыдущей версии кода без ссылки на конкретные версии.

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

Хотя тег GIT можно создавать программно (например, с помощью тега git из командной строки), создание релизов GitHub – это ручной процесс, который происходит в пользовательском интерфейсе GitHub. Вы, по сути, говорите GitHub создать новый релиз и сообщаете, к какому тегу вы хотите применить его.

Сравнение коммитов

GitHub предлагает множество инструментов для работы с кодом.

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

GitHub позволяет вам делать это с compare view: просто добавьте /compare в конец имени репозитория.

Например: https://github.com//react/compare

На рисунке ниже я сравниваю последнюю версию React v15.x с последней версией v16.0.0-rc, доступной на момент написания этой статьи, чтобы увидеть, что изменилось.

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

Webhooks и Services

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

Webhooks

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

Когда происходит событие, GitHub отправляет запрос POST на URL, который мы говорим ему использовать.

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

Мы отправляем команду push к GitHub, GitHub сообщает серверу об этом, и сервер извлекает данные из GitHub.

Services

Сервисы GitHub и новые приложения GitHub представляют собой сторонние интеграции, которые улучшают работу разработчика или предоставляют услуги.

Например, вы можете установить исполнитель тестов для автоматического запуска тестов каждый раз, когда вы делаете новые коммиты. Здесь поможет TravisCI.

Можно настроить непрерывную интеграцию с помощью CircleCI.

Можно создать интеграцию Codeclimate, которая анализирует код и предоставляет отчет «Техническая задолженность» и покрытие тестирования.

Заключение

GitHub — это замечательный инструмент и сервис, которым можно воспользоваться. Это настоящий драгоценный камень в современном наборе инструментов для разработчиков. Данное руководство поможет вам начать работу. Реальный опыт управления проектами с открытым или закрытым исходным кодом GitHub (как пользоваться им, показано во многих статьях) — это то, что нельзя упустить.

Источник: http://falbar.ru/article/vvedenie-v-github-dlya-razrabotchikov

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

Как использовать GitHub для поиска разработчиков

Алексей Руденко, Director of Data Management в Ring Ukraine, написал статью о том, как начинающим разработчикам оформить профиль на GitHub так, чтобы он стал дополнительным преимуществом на собеседовании. Статья была опубликована на сайте DOU.UA. Представляем ее вашему вниманию.

Photo by Caleb White on Unsplash

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

Я уже более 15 лет управляю процессами создания продуктов — от гипотез до устойчивых продаж.

Последние два года вместе с fellow kottans помогаю новичкам и свитчерам приобретать новые технические скиллы в разработке, развивать soft skills и находить первую работу в IT.

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

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

Нужно ли это

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

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

А тесты — это же всегда стресс, сказывающийся на качестве работы.

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

Существуют различные взгляды на открытые портфолио проектов на облачных VCS (GitHub, GitLab и подобных). Многие опытные разработчики считают, что на профиль никто не смотрит.

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

А когда по итогам цикла собеседований остаётся несколько равноценных кандидатов, то каждый бит информации может оказаться решающим — в том числе и проекты на GitHub.

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

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

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

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

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

Никто не ожидает увидеть уникальный проект на 100500 строк кода.

Оценивать, скорее всего, будут уровень владения шаблонами проектирования, стиль кода, способность написать минимальную документацию, навыки работы с Git.

Почему это всё важно? Потому что это о коммуникации. Это то, чего будут ожидать от сотрудника, помимо написания собственно кода. Код пишется в первую очередь для других людей.

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

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

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

Все новички делают что-нибудь такое, но не все завершают и показывают. Не ищите оригинальности — это всё ради демонстрации навыков и умений.

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

Вот отличный пример работы студентки курса по фронтенду, а теперь разработчицы в MacPaw Mary Fedirko — погодное радио (нажми кнопку ON).

В этом проекте она продемонстрировала творческий подход не только к написанию «очередного JS-фреймворка», но и к дизайну и внешнему представлению в целом.

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

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

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

Источник: https://techrocks.ru/2020/05/13/make-your-github-profile-helpful-in-finding-job/

Почему GitHub не поможет нанять разработчика

Как использовать GitHub для поиска разработчиков

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

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

Например, в последнем списке вакансий на Hacker News куча объявлений с просьбой указать профиль GitHub в своём заявлении о приёме на работу.

Есть несколько правильных статей, почему нельзя требовать от кандидатов профили GitHub. Особенно рекомендую «Этика неоплачиваемого труда и сообщество Open Source» и «Почему GitHub — не резюме».

Обе статьи отлично объясняют причины, почему при найме не следует спрашивать о вкладе в свободные проекты. Но я не о том, что это неэтично или что GitHub не слишком подходит для демонстрации проектов.

Я о том, почему эти профили просто малополезны.

Разреженность данных

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

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

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

Для количественной оценки я собрал публичные коммиты всех пользователей из GitHub Archive и получил такие цифры:

  • Только 17% пользователей в прошлом году запушили какой-то код
  • Только 7,4% пользователей сделали это более 10 раз
  • Только 1,4% пользователей сделали это более 100 раз
  • Только 0,15% пользователей сделали это более 500 раз

Такое распределение примерно соответствует степенному закону (или, по крайней мере, чему-то похожему). Это означает, что большинство пользователей относительно малоактивны, но в небольшом количестве аккаунтов — сотни тысяч коммитов за год. Для примера взгляните на график по проценту разработчиков на GitHub с определённым количеством фоловеров:

Получить количество коммитов из GitHub API сложно [1], так что я привожу количество фоловеров, у которых похожее распределение. Если вы введёте свой userid на странице статьи, то получите мини-отчёт, на какой позиции находитесь.

Плюс в том, что даже с 10 фоловерами вы можете смело утверждать, что входите в топовый 1% всех разработчиков. Минус в том, что если у подавляющего числа разработчиков нет данных в публичных профилях, то эти профили нельзя использовать для фильтрации кандидатов на работу. У 83% нет коммитов за прошлый год, а у 88% нет фоловеров. Это не значит, что они плохие разработчики. Просто у них нет нет вклада в проекты open source, чтобы похвастаться.

GitHub показывает только вклад в open source

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

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

Думаю, наиболее поучительно сравнить известных программистов, которые работают в индустрии open source, с другими знаменитостями, которые работают в другой индустрии. Например, у Линуса Торвальдса больше всего фоловеров на GitHub.

Это вполне оправданно, ведь он создатель нескольких невероятно успешных проектов с открытым исходным кодом, таких как Linux и git. С другой стороны, у Джона Кармака или Джеффа Дина вообще нет профилей GitHub, хотя они оба хорошо известны своей работой в одинаково успешных проектах с закрытым исходным кодом, таких как Doom и Google.

Я всегда считал, что требовать предоставить примеры коммитов open source при поиске разработчиков в проект с проприетарным кодом — это верх лицемерия. Это напоминает компании, которые требуют рекомендации, но сами запрещают выдавать рекомендации бывшим сотрудникам. Если вы не разрешите человеку писать проекты с открытым исходным кодом, то нет смысла требовать наличия таких проектов для получения работы. Даже если оставить лицемерие в стороне, оценка по профилю GitHub выглядит сомнительно, если она исключает большинство разработчиков, в том числе таких как Джон Кармак и Джефф Дин. Мне кажется, должен быть некий «Тест Джеффа Дина» для найма: если ваши требования по вакансии разработчика исключают кого-то вроде Джеффа Дина, вероятно, вы что-то делаете неправильно.

Большинство проектов GitHub не впечатляют

Даже у той малой части разработчиков c проектами на GitHub большинство проектов не слишком впечатляют.

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

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

К примеру, на GitHub около 190 000 репозиториев с названием «datasciencecoursera».

Кроме того, из более чем 78 миллионов репозиториев в GitHub Archive около 1,1 млн называются «hello-world» и 1 млн называются «test».

Число фоловеров показывает популярность, а не талант

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

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

В качестве примера взгляните на Github-профиль Stichpunk:

У этого профиля около 1560 подписчиков, что вносит девушку в топ 0,002% лучших разработчиков на GitHub. У неё также несколько относительно популярных репозиториев и она, похоже, работает в крупной IT-компании. На первый взгляд, это довольно респектабельный разработчик.

Но это профиль не настоящего человека. Он создан авторами сериала «Кремниевая долина» для эпизода «Табы против пробелов»:

Каждый раз, когда вы всерьёз рассматриваете количество фоловеров GitHub как некий значимый показатель, просто помните, что у фейкового профиля персонажа из одного-единственного эпизода сериала больше последователей, чем у 99,998% разработчиков, и он располагается примерно на 670-м месте в мире.

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

Многие популярные проекты на самом деле очень впечатляющие. Я не пытаюсь утверждать, что популярность и качество хотя бы немного не коррелируют. Проблема в том, что сделать проект популярным — это совсем другая задача, требующая совсем другого набора навыков, чем просто написание качественного кода.

Интервьюеры не проверяют профили GitHub

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

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

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

Судя по рассказам, это довольно распространённая практика. Например, Дэн Луу написал в твиттере:

«Несмотря на шумиху о том, как open source помогает вашей карьере и что github==резюме, у меня только в 2 из 50 интервью кто-то смотрел мой код» — Дэн Луу
Дэн Луу входит в топ-1000 по количеству фоловеров на GitHub. По крайней мере, мой опыт не объясняется только относительно скромным портфолио на GitHub.

Или вот на hftguy.com один разработчик изучал аналитику GitHub после прохождения множества собеседований — и обнаружил, что его проекты зашёл посмотреть только 1 человек (и это может быть он сам во время проверки):

«После дюжины телефонных собеседований (1 разработчик за звонок) и нескольких очных (от 4 до 7 интервьюеров) мой профиль посмотрели только один раз. Вывод: никого не волнует GitHub. Никто не будет его смотреть» Хотя профили GitHub затруднительно использовать как источник данных, я всё равно планирую использовать их для будущего проекта. Идея в том, что хотя профили отдельных пользователей дают разреженный зашумлённый сигнал, но объединение информации от большого количества пользователей всё ещё позволяет обнаружить некоторые интересные тенденции.

Сноска 1

На GitHub нет API, чтобы получить статистику по активности за последний год. Судя по всему, выдаётся временная шкала в SVG (вроде такой), которую можно распарсить. Я почти справился с этим хаком для данной статьи, но упёрся в некоторые ограничения CORS по загрузке этого в браузере. Можно было написать прокси для запросов, но это уже превращалось в маразм, так что я выбрал вариант с фоловерами. ↑

  • HR
  • поиск сотрудников
  • найм разработчиков
  • резюме
  • собеседование
  • GitHub

Хабы:

  • Open source
  • GitHub
  • Управление персоналом
  • Карьера в IT-индустрии

Источник: https://habr.com/ru/post/350912/

GitHub: Инструкция для нетехнических специалистов

Как использовать GitHub для поиска разработчиков

GitHub — крупнейший в мире хостинг для хранения и работы с IT-проектами. Ресурс объединяет почти 24 миллиона разработчиков и более 100 тысяч организаций. В прошлом году 50% из ТОП-10 энтерпрайз компаний мира использовали в работе сервис GitHub Enterprise, среди них Walmart, Apple и General Motors. Как вы, как не технический специалист, можете использовать возможности GitHub?

В чем смысл OpenSource?

Для начала стоит объяснить, почему так много людей готовы поделиться своими знаниями бесплатно.

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

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

Терминология в контексте GitHub

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

  • Гит (Git) — система контроля версий, хранит все изменения в проекте с момента начала, с возможностью вернутся к любому изменению в прошлом;
  • Звездочки (Stars) — аналог лайка на Фейсбуке (чем больше, тем лучше);
  • Фолловеры (Followers) — люди, которые подписались на обновления;
  • Контрибьюторы (Contributors)- люди, которые участвуют в разработке проекта;
  • Форк (Fork) — копия репозитория на Гитхабе;
  • Ветка (Branch) — используется для разработки обособленных задач;
  • Мердж (Merge) — процесс вливания одной ветки в другую;
  • Коммит (Commit) — запись изменений в репозиторий;
  • Код ревью (Code review) — проверка кода на соответствие требованиям, задачам и оформлению;
  • Пулл реквест (Pull request)— если вы что-то изменили в своем форке и хотите теперь добавить изменения в исходный репозиторий, нужно оставить запрос (пулл реквест) на принятие ваших правок в основной репозиторий. Владелец репозитория может принять или отклонить такой запрос.

GitHub, как средство получения информации

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

Информация о развитии GitHub

На Гитхабе сейчас примерно 10 TB исходного кода. Это крупнейший сервис для хостинга и совместной разработки IT-проектов, которым каждый месяц пользуются более 6 миллионов человек.

Не все принимают активное участие в разработке, некоторые просто отслеживают развитие интересующего их проекта.

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

Данные о развитии технологий

К июлю 2017 года на Гитхабе было зарегистрировано 393 различных языка программирования. Наиболее активно сейчас развивается Swift, в первой десятке также Ruby и PHP.

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

Показатели уровня разработчика

Подбирая аутсорсинговую команду разработчиков, заказчики часто предпочитают кроме портфолио компании ознакомится также с резюме членов будущей проектной группы. Альтернативный вариант — просмотреть профили разработчиков на Github.

Профиль Линуса Торвальдса, основателя Линукс и создателя Git

О чем может рассказать Github-профиль разработчика

  1. В информации под фото разработчика можно найти ссылки на организации внутри GitHub, в которых разработчик состоит — отличный способ узнать об интересах специалиста;
  2. Подписчики — один из показателей уровня разработчика и его репутации в профессиональной среде;
  3. Репозитории и активность — собственно, тот самый вклад, внесенный разработчиком в проекты на Github. Даже если вы не технический специалист, ключевые слова в названии репозиториев подскажут, каким технологиям разработчик уделяет внимание. На примере профиля Линуса Торвальдса, не сложно понять, что этот человек активно участвует в разработке Линукс :)

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

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

Участие в опенсорс разработке в очередной раз подтверждает интерес разработчика к миру IT, а уровень работ — еще один показатель уровня его компетентности. Как создать успешный проект на GitHub читайте здесь.

Гитхаб — не только для программных продуктов

Крупнейший хостинговый сервис используют также компании и специалисты из других отраслей: медицина, образование, ритейл и многие другие.

В 2013 году GitHub анонсировал возможность хранения географических данных, а именно GeoJSON файлы, в виде интерактивных карт. Функционал карт на GitHub также включает визуализацию изменений в картах и возможность выбора стиля отображения карт. Один из интересных проектов в этом направлении — репозиторий, хранящий интерактивную историю о изменении географии всех избирательных округов США.

Государственные законы на GitHub

Государственные законы США, Германии, Франции, и Японии также можно найти на Гитхабе. Стив Морин (Steeve Morin), например, позаботился о том, чтобы выложить на сервис все изменения во французском гражданском кодексе со времен Наполеона.

Германия и вовсе создала аккаунт Бундестага — в 2012 году граждане страны получили доступ к самым свежим текстам законов на Гитхаб.

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

Как предприниматель может использовать Github

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

  1. Подобрать аутсорсинговую команду для разработки вашего проекта, а также получить дополнительную информацию о специалистах, с которыми вы будете работать;
  2. Возможность следить за тенденциями в сфере веб и IT-разработки, узнавать о новейших проектах и технологиях, набирающих популярность;
  3. Получать данные о развитии ваших потенциальных проектов-конкурентов, а также проектов, на которые вы равняетесь;
  4. Повысить эффективность своего решения, создав страницу компании с репозиториями проектов и предоставив участникам GitHub возможность предлагать улучшения.

Разработчики студии stfalcon.com обладают большим опытом в создании технически сложных решений для крупных компаний. Напишите нам на  info@stfalcon.com, чтобы поделиться своей идеей. Мы с радостью ответим на все ваши вопросы и поможем реализовать проект вашей мечты!

Источник: https://stfalcon.com/ru/blog/post/GitHub-manual-for-non-technical-entrepreneurs

Инструкция по GitHub для рекрутеров: как найти того, кто вам нужен

Как использовать GitHub для поиска разработчиков

Лучшие специалисты достойны того, чтобы их хорошенько поискать. Поэтому, команда Hurma System продолжает обсуждать, где искать кандидатов в 2019 году. И сегодня мы поговорим про IT-рекрутмент на крупнейшем сервисе для хостинга IT-проектов и их совместной разработки — GitHub.

Как GitHub может помочь найти специалистов?

GitHub — веб-сервис, который позволяет разработчикам хранить свой код, а также делиться этим кодом с коллегами и заниматься его совместной разработкой в open source.

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

Профиль специалиста на GitHub для IT-рекрутера — ценный источник информации, поскольку именно там можно понять какая должность у кандидата, место его работы и в какой стране мира он находится. Также в профиле отображается email специалиста и его сайт.

Обращайте внимание на количество подписчиков у разработчика, его вклад в другие проекты и репозитории. Чтобы проверить популярность проектов, необходимо обратить внимание на то, какое количество людей отметили или «форкнули» их. Это означает, что другие пользователи создали копию кода, могут изменять и применять его в своих проектах.

Пошаговая инструкция: как искать специалистов в GitHub

Давайте разберем, какие нужно сделать первые шаги на веб-сервисе рекрутерам для поиска кандидатов. 

1. Регистрация

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

2. Поиск по ключевым словам

Если вам нужен определенный специалист, например, Java-разработчик, то если вы пропишете слово «Java» в поиске, то GitHub выполнит поиск по таким категориям:

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

3. Поиск по языкам программирования

Также на GitHub можно сразу искать по языкам программирования, которые знает специалист. 

Например, вам нужен специалист, владеющий Python. Вы вводите в Google такой запрос:

site:github.com inurl:tab=repositories Python

Далее, переходите по предложенным ссылкам.

4. Поиск по технологиям

В GitHub на страницах репозиториев также указываются кодовые названия технологий и их описания. Такой вид поиска можно осуществить по ключевым запросам, которые не являются названиями языков программирования.Например, в Google нужно ввести:

site:github.com inurl:tab.repositories Java Spring NoSQL

5. Отслеживание активности 

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

6. Коммуникация

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

Как заинтересовать кандидата?

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

1. Рынок подстраивается под IT-специалиста, а не наоборот

Стремительное развитие технологий превращает некоторых специалистов в сфере в «трофей», который хочет заполучить каждая компания. Но, если кандидат —  профессионал, то в любом случае не он ищет работу, а она его.

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

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

2. Работу в вашей компании нужно продавать

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

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

Только после этого напишите индивидуальное письмо с предложением, которое потенциально может его заинтересовать.

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

3. Специалист может не проявлять энтузиазма

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

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

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

Почему важно рекрутить на GitHub?

Подбор персонала в IT — непростая и постоянно изменяющаяся сфера. Рекрутеру важно все время развиваться, быть в курсе тенденций рынка и постоянно обучаться новому.

Именно поэтому точечный поиск на таких специализированных площадках, как GitHub, — отличная возможность найти нужного специалиста и проанализировать его деятельность.

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

Источник: https://hurma.work/ru/blog/instrukcziya-po-github-dlya-rekruterov-kak-najti-togo-kto-vam-nuzhen/

Все HR- сотруднику
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: