Как бы вы оценили профиль программиста на Github? [закрыто]

Многие люди в сообществе open source говорят, что они сильно учитывают профиль кандидата на Github при приеме на работу.

Я активен на Github, с несколькими собственными проектами и некоторыми вкладами в другие. Но, глядя на свой профиль, как если бы я был работодателем, я вижу много шума: проекты, которые я клонировал, но никогда не участвовал, и т. Д. Проекты и патчи, которыми я горжусь, не выделяются.

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

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

9 из 10 претендентов никогда не отправляли ни одного патча в один проект с открытым исходным кодом. Даже обновление неработающей документации ставит вас в верхний эшелон разработчика. Это показывает, что вы достаточно знакомы с каким-либо пакетом с открытым исходным кодом, чтобы знать, что не так, вы достаточно внимательны, чтобы отправить патч, и сопровождающие этого пакета считают, что ваша работа достаточно хороша, чтобы ее включить. Как обобщение, это показывает, что вы берете на себя инициативу оставлять грязные вещи лучше, чем вы их нашли.

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

Так что один принятый патч выглядит великолепно. Длинная история из 2-3 простых патчей за квартал еще лучше. Даже лучше, чем это было бы внести что-то заметное.

1. Значительный вклад в важные проекты с открытым исходным кодом (верхние 0,1% -1% кандидатов)
2. Расширенная история небольших вкладов в любые проекты (более 5% кандидатов)
3. Один однострочный патч для относительно неизвестного пакета (более 10% кандидатов)

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

Блоги также отличный показатель качества, но для стиля общения, а не технического мастерства. Сколько программистов потрудились написать статью № 1 в блоге? Здесь применяется тот же тип отсечения 1% / 5% / 10%.

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

Должны быть специальные инструменты для пользовательской оценки, работающие с данными Github. На данный момент вы можете использовать сторонние сайты. Например, есть http://coderwall.com - один быстрый просмотр профиля показывает, когда разработчик когда-либо представлял патч, если кто-то еще разветвлял свой проект, сколько языков он использует ...

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

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

Даже если вклад в проект с открытым исходным кодом может быть плюсом для кандидата (как упомянуто @marshally), вы должны оценивать и нанимать по старинке, разговаривая.

Некоторые ссылки, на которые я наткнулся сразу после прочтения этой темы:

• GitHub не ваше резюме
• Самые активные пользователи GitHub , особенно эти 2 комментария от важных участников: 1 , 2 .

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

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

Если кто-то хочет оценить вас, он / она должен взглянуть на вашу «истинную» картину, дерьмовый код, а также хороший код. Я недавно брал интервью, и интервьюер попросил меня открыть мою учетную запись на github, затем он просмотрел одно из моих репозиториев, просмотрел какой-то дерьмовый код, который я написал год назад на языке, который я изучал.

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

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

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

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

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

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

Приятно было не начинать сначала техническое интервью. Казалось, у них была правильная позиция: найти хорошую «командную» форму, а затем оценить навыки.