GitHub-ревью кандидата: как превратить код в честный этап найма

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

Казалось бы, вот он – идеальный инструмент найма программистов в эпоху open source. Но так ли всё просто? Может ли просмотр профиля в GitHub действительно заменить традиционное интервью и тестовые задания, и главное – как сделать этот этап прозрачным и справедливым для всех участников процесса?

GitHub вместо резюме: мода или необходимость?

Идея оценивать программиста по его активности в open source выглядит заманчиво. Для рекрутера это быстрый способ заглянуть в реальный код кандидата, а для самого разработчика – шанс продемонстрировать навыки не на словах, а на деле. Некоторые гайды по найму прямо рекомендуют запрашивать у соискателей портфолио проектов или ссылку на GitHub и внимательно их изучать: это позволит оценить качество прошлых работ и вклад в открытые проекты (источник hyresnap.com). Крупные компании тоже не обходят стороной GitHub. Например, рекрутеры Facebook признаются, что ищут кандидатов среди контрибьюторов популярных open source-проектов и просматривают их код при отборе на вакансии (источник kula.ai).

На волне хайпа многие разработчики поспешили прокачать свои профили: заводят pet-проекты, выкладывают учебные задания, следят за зелёными квадратиками коммит-статистики. Возник даже своеобразный фольклор: «если тебя нет на GitHub, ты не программист». Однако реальная ценность таких профилей оказалась далеко не однозначной.

Во-первых, подавляющее большинство разработчиков либо вовсе никак не проявляют себя на GitHub, либо делают это эпизодически. По оценке инженера и блогера Бена Фредериксона, 83% пользователей GitHub за последний год не совершили ни одного публичного коммита (источник benfrederickson.com). Только 7,4% сделали больше 10 коммитов, и лишь исчезающе малые 0,15% – более 500 коммитов за год. Далеко не каждый талантливый разработчик участвует в open source. Лучший программист, с кем работал Фредериксон, вообще не имел публичных репозиториев – ни коммитов, ни своих проектов, ни фолловеров.

Тем не менее, это не помешало ему быть выдающимся специалистом. Похожий пример – легендарные Джон Кармак или Джефф Дин: они известны своими закрытыми проектами (Doom, Google), и публичного аккаунта на GitHub у них нет. Если фильтр на входе требует активного GitHub, он… отсеет самого Джеффа Дина. Такой «тест Джеффа Дина», по меткому замечанию Фредериксона, ясно показывает несовершенство подхода.

Во-вторых, открытый профиль отражает лишь часть работы программиста. Большинство софта в индустрии – закрытое. Если человек годами пишет корпоративный код под NDA, у него физически не будет чего показать в публичном репозитории. Как заметил один разработчик, значительная часть его выкладок на GitHub – это хобби или фриланс, никак не связанные с основным местом работы (источник habr.com). Рабочий же код часто нельзя открыть из-за коммерческой тайны или просто пользы в нём мало без внутреннего контекста.

Так стоит ли требовать open source-активность от кандидата, если на самой работе вы не позволите ему коммитить в open source? «Это высшая степень лицемерия», – пишет всё тот же Фредериксон. Получается, компания хочет подтверждения навыков в виде чужих бесплатных проектов, хотя в штате не даст программисту тратить время на сторонний open source. Не самая честная позиция, и некоторые авторы прямо называют подобные требования этически сомнительными.

Наконец, не всякий код на GitHub одинаково полезен для найма. В эпоху буткемпов и онлайн-курсов там накопились миллионы учебных репозиториев, одинаковых проектов и шаблонов. Например, было подсчитано, что на платформе свыше 190 000 репозиториев с названием “datasciencecoursera” – студентов просили завести их для курса. Наличие подобных заготовок в профиле говорит лишь о том, что человек прошёл обучение, но никак не раскрывает его талант. Да и собственные пет-проекты часто больше демонстрируют энтузиазм, чем соответствие конкретным требованиям вакансии.

А как же показатели популярности – звёзды, фолловеры? Интуитивно кажется, что если у проекта тысячи звёзд, а у автора сотни подписчиков, то перед нами ценное приобретение. Но метрики GitHub склонны измерять не навыки, а популярность. Можно написать полезную утилиту, которой пользуется узкий круг профессионалов – и она останется почти без звёзд. А можно выложить занимательный, но тривиальный проект – и проснуться знаменитостью Hacker News. Количество фолловеров и репозиториев нередко говорит скорее о вовлечённости в сообщество (или умении себя подать), чем о качестве кода.

Многое зависит и от внешних факторов, порой далеких от программирования. Показателен эксперимент: один разработчик рассказал, что за 5 лет активной работы над множеством проектов (включая вклад в популярный Spring Boot) его профиль собрал лишь 16 подписчиков. Зато профиль его девушки привлёк 3 фолловеров всего за неделю, хотя вклад в код у неё был минимальный. Едва ли дело в мистических способностях новичка – скорее сказываются особенности восприятия и случайность. Такой разброс ещё раз подтверждает: цифры на GitHub – шумный сигнал, на который нельзя полагаться без оглядки.

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

Заглядывают ли работодатели в ваш репозиторий?

При всех обсуждениях вокруг «GitHub-резюме» возникает вопрос: а используют ли компании эти данные на практике? Ответ во многом зависит от конкретной культуры найма, но в среднем картина далека от всеобщего повального анализа GitHub-кодов.

Разработчик Дэн Лу, автор популярного блога, поделился любопытной статистикой из собственного опыта кандидата: лишь в 2 интервью из 50 у него действительно смотрели код на GitHub. Причём Дан Лу – далеко не безызвестный новичок: его аккаунт входит в топ-1000 по количеству фолловеров на GitHub. То есть дело не в скромности профиля – просто большинству интервьюеров оказалось не до него. Более того, некоторые признавались ему, что даже резюме толком не прочитали перед встречей, не то что его репозиторий. Это не единичный случай.

На форуме Hacker News и Reddit айтишники регулярно шутят, что HR-специалисты просят ссылку на GitHub «для галочки», а дальше ей никто не пользуется. В комментариях на «Хабре» найдётся немало историй о том, что профиль на GitHub почти никогда не смотрят – скорее исключение. Один инженер, устроившись работать в Канаду, написал: пока дойдёшь до этапа, где код кандидата вообще может заинтересовать технического специалиста, «99 из 100 соискателей уже отсеются по причинам, не связанным с кодом (HR, резюме и прочее)». К тому моменту, говорит он, обычно уже неважно, есть у человека проекты на GitHub или нет.

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

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

Почему же многие рекрутеры и нанимающие менеджеры обходят стороной этот кладезь информации? Причин несколько. Кто-то признаётся, что смотрит GitHub только при возникновении вопросов к резюме – например, если есть сомнения в уровне или редкие навыки, указанные кандидатом. Другие попросту перегружены потоком откликов: на первом этапе найма не до глубокого анализа кода, а дальше уже и времени нет. В крупных компаниях ресерч профилей обычно не входит в обязанности HR-отдела, а технические интервьюеры подключаются к процессу поздно и то не всегда.

Кроме того, оценивать чужой код – трудоёмкое занятие. Быстро пробежать резюме куда проще, чем разбираться в стилях кодирования, архитектуре и качествах чужого проекта. Не всякий разработчик-наблюдатель готов этим заниматься ради каждого кандидата. Тем более что профиль может оказаться пустым или бесполезным – затраченное время пойдёт впустую.

Есть и ещё одна сторона медали: объективность. Парадоксально, но при всей видимой прозрачности, профиль GitHub может ввести в заблуждение неопытного оценщика. Мы уже говорили о перекосе в показателях и неполноте данных. Добавим сюда человеческие biases: узнавание знакомых технологий (или неприятие незнакомых), впечатление от оформления профиля, даже время последних коммитов (некоторые, увидев, что кандидат коммитил в рабочие часы, делают скоропалительный вывод о его дисциплине). Разобраться, где кандидат действительно молодец, а где приписал себе лишнее, порой непросто.

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

Прозрачность превыше всего: как правильно использовать GitHub при отборе

Итак, мы видим, что простой призыв «пришлите ваш GitHub, мы там всё узнаем» на практике не работает. Но это не значит, что GitHub-ревью бесполезно в принципе. Просто применять его нужно взвешенно и прозрачно. Что это означает на деле?

1. Попросите кандидата самому представить свои проекты. Вместо тихого «шпионажа» по ссылке – открытый разговор. Далеко не каждый проект в профиле может быть релевантен вашей вакансии, и сам разработчик лучше знает, где у него сильные стороны.

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

2. Изучайте качество, а не цифры. Если уж смотреть профиль, то глубже поверхностных метрик. Зелёные квадратики статистики коммитов, число репозиториев, звёзды – забудьте, толку от них мало. Вдумчиво просмотрите один-два выбранных проекта. На что обратить внимание? Почитайте README и описание – насколько ясно человек презентует свою работу. Оцените структуру кода, стиль, наличие тестов, документации.

Если это fork или контрибьюция в чужой проект – взгляните на обсуждение pull request’а. Кстати, единственный “весомый PR” в известный репозиторий может рассказать о кандидате больше, чем десяток пет-проектов, как заметил один инженер. По истории обсуждения видно умение разобраться в чужом коде, реагировать на замечания, доводить задачу до конца. Именно такие вещи и стоит искать, проводя ревью GitHub-кода. Однако будьте готовы, что на поиск тех самых «жемчужин» уйдёт время. Если вы его не закладываете – лучше не делайте вполсилы. Половинчатый, неосознанный анализ профиля лишь создаст иллюзию объективности. Прозрачность требует, чтобы вы точно знали, зачем и что именно вы смотрите в репозитории кандидата.

3. Обсудите код с кандидатом на интервью. GitHub-ревью не должно происходить за спиной у соискателя. Наоборот, сделайте его частью диалога. Например, выделите несколько минут, чтобы попросить разработчика рассказать о выбранном проекте: какие задачи решал, какие технологии применял, с какими трудностями столкнулся. Задавайте вопросы по коду: «Я посмотрел модуль Х, там интересное решение – расскажете, как до него дошли?» или «В pull request Y вам оставили комментарий про оптимизацию, как вы исправили?».

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

4. Не делайте из отсутствия профиля проблему. Прозрачность – это ещё и честность критериев. Если вы решили включить анализ GitHub в процесс отбора, позаботьтесь о равных условиях для всех. Недопустимо «тайно» отбирать только тех, у кого зелёная стена коммитов, отсекая остальных. Открыто скажите, что приветствуете ссылки на код, но это необязательный этап. У кандидата может не быть возможности показать свой прошлый код – тогда предложите альтернативу.

Например, дать небольшое пробное задание или пройти вместе парное программирование. Главное – не наказывайте человека за обстоятельства, не зависящие от его таланта. Многие отличные специалисты приходят из сфер, где open source не принят, или попросту не успевают контрибьютить, занимаясь работой и семьёй. Ваш фильтр не должен дискриминировать таких людей. Помните, GitHub-профиль – это бонус, а не обязанность. Используйте его как дополнительный сигнал, когда он есть, но не превращайте отсутствие активности в красный флаг по умолчанию.

5. Будьте готовы объяснить свои выводы. Завершая GitHub-ревью, спросите себя: сможете ли вы обосновать кандидату, почему его код произвёл на вас то или иное впечатление? Прозрачность подразумевает, что оценка не скрыта за семью печатями. Если вам понравилось решение – скажите об этом, отметьте, что именно ценно. Если же остались сомнения (например, код показался неоптимальным или непонятным) – задайте об этом вопрос открыто.

Дайте шанс человеку прокомментировать свои решения. Вполне возможно, там были причины, о которых вы не догадались. Такой обмен мнениями не только выравнивает положение (кандидат понимает, на основании чего его оценивают), но и сам по себе может стать мини-technical discussion, показывающей профессиональный уровень и культуру инженера. В идеале этап ревью кода превращается в двусторонний обмен, а не в односторонний приговор. Тогда и слово «прозрачность» приобретает настоящий смысл.

* * *

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

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

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

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

Вывод: GitHub-ревью как часть отбора – не панацея и не формальность, а ещё один формат собеседования. И как любое собеседование, его надо проводить интересно, уважительно и прозрачно. Тогда он работает на вас.

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