О чем статья
Речь пойдет о найме. Я заметил, что мое мнение и мнение некоторых коллег на работе (а как выяснилось позже - и на Хабре) о том - какие выводы делать из гита кандидата при устройстве на работу - кардинально расходятся. И один раз мы уже чуть не потеряли из-за этого кандидата, который закрыл наши потребности с большим запасом. А несколько раз возможно и потеряли. Мне за время работы (сейчас уже чуть больше 10 лет в коммерческой Android-разработке) не раз приходилось собеседовать кандидатов, и изредка они прикладывали свой гит.
Посему предлагаю мой алгоритм анализа гита кандидата при устройстве на работу. (кому лень всё читать - заключение будет в конце - обобщенный результат будет там)
Стоит ли вообще оценивать гит кандидата?
Первое - время для оценки гита. Если ценность кандидата такова, что его проход на следующий этап нужно оценить за 10 минут - в принципе гит можно и не открывать (поставив просто в плюсик что кандидат что-то хотел показать) ну или потратить 5 минут на беглый просмотр классов. Но в текущих реалиях отличить сгенерированный код, код списанный с методички или написанный по руководствам - всё равно скорее всего не выйдет за 5 минут.
Если время есть - то всё сразу становится намного интереснее. Тогда перейдем ко второй части - типичные варианты проектов в гите соискателя и как их готовить.
Варианты проектов, которые встречаются чаще всего
Проект на показ
Обычно это что-то идейно заезженное и не очень сложное. Для фронтовых разработчиков - чаще даже без серверной части. Что-нибудь вроде - todo листа, списка покупок, затрат, прогресс просмотренных сериалов.
Характеризуется тщательно отполированным кодом с использованием последних или мейнстримных библиотек и подходов. Даже для приложения из полутора экранов и пяти классов - будет завезён di, база данных (для хранения пары строк), последний ui фреймворк, и актуальная асинхронщина.
В гите будет четкая структура коммитов с правдоподобными комментариями, и короткий срок жизни проекта (например весь сделан за неделю, или коммиты в него прилетают раз в несколько лет, пачками, в момент - когда соискатель меняет работу)
Проблема такого кода (для нас) в том, что он вообще то не очень то и показывает знания кандидата (и может быть вообще результатом llm например), и уж точно нельзя сразу делать вывод, что перед нами эксперт, который будет писать так же на вашем проекте.
Если есть некоторое количество времени - то можно поискать несостыковки (когда весь код использует общую архитектуру, а в одном месте обнаруживаем иную реализацию). Но в целом я таким занимался редко - обычно достаточно бегло проглядеть код и убедиться в его постоянстве
Какие выводы сделать для собеседования:
Хорошей отправной точкой будет посмотреть список использованного инструментария и подходов, а затем опросить кандидата, зачем этот инструментарий нужен. Например очень показательно будет если кандидат использовал mvvm или di - но не может объяснить зачем нужены эти паттерны. Расспросить о функционале тех-же библиотек, отличном от использованного в проекте - например если кандидат использовал rx с flatMap, но у него в pet приложении ни разу не происходит объединение двух потоков (combineLatest или merge или zip) - задать задачу с их спользованием. Если человек действительно знает инструментарий - то он скорее всего сможет отойти от имеющегося кода на пару шагов, если же нет - то начнет плавать. И вот тут уже возникнут вопросы - почему он в демо проекте использовал технологии, которые знает поверхностно и что он этим хотел показать?
Какие выводы я бы сделал о кандидате (безотносительно ответов на вопросы):
Кандидат мотивирован пойти на работу, он запарился и сделал показательный репозиторий. Как минимум - он хочет на работу попасть, это уже небольшой но плюс.
Бонусом - если это кандидат уровня senior - я бы по спрашивал про ситуации, когда бы он выкинул эту архитектуру и код. Исключительно по моей дурацкой классификации (которую вообще забейте) - кандидат уровня senior - должен не только уметь хорошо применять инструменты, но и понимать - когда они не нужны (а не - у меня в руках молоток - значит всё вокруг гвозди).
Проект для самообучения
Встречаются ситуации, когда человек ведёт экспериментальный проект для изучения новых технологий (или несколько проектов).
Такой проект может не содержать идеи вообще (приложение, которое не делает ничего полезного), а качество кода может быть далеко от коммерческого. Разные куски могут использовать разные технологии, спагетти код, чистый абсурд (например рисование стандартной двухкадровой анимации напрямую через openGL, или блокирующие вызовы в ui) и вообще - такой проект далеко не обязательно скомпилируется. Комментарии коммитов в Git могут носить хаотичный характер и не содержать полезных сведений (например, «ахаха (злобный смех)» в качестве commit message).
С такими случаями у моих коллег пару раз возникали разногласия. Разработчик-ревьюер брал проект, убеждался, что код не компилируется, смотрел пару классов, видел «какой-то ужас: главный поток лезет в сеть и блокирует приложение, в базе данных хранятся JSON-объекты строками, весь код внутри экранов» - и рекомендовал отказать кандидату.
На самом деле - на таких проектах разработчик ставит эксперименты. В случае с главным потоком лезущим в сеть например - кандидат на интервью позже ответил - что сделано это намеренно в попытке обойти networkOnMainThreadException в android - и да, есть некоторые методы позволяющие влезть в сеть из ui потока повесив приложение на момент запроса, и не привести при этом к данному исключению.
Я пойму комментаторов, которые скажут, что такую непотребщину и не стоит показывать - но её и не всегда явно демонстрируют (например могут предложить посмотреть конкретную очень локализованную часть проекта, но оценить то хочется всё), или это может быть один проект из нескольких в гите, на который вы обратите внимание первый, или кандидат просто приложил всё, что у него есть, рассчитывая на дискуссию потом.
Что делать с таким гитом:
Найдите наиболее безумные вещи, спросите у кандидата - почему они сделаны так а не иначе и что он хотел этим достичь (не стоит кстати начинать с агрессивной позиции и утверждать что что-то неправильно, пусть сам вам расскажет почему сделано именно так)
Если видите несколько технологий решающих одну проблему (корутины, реактивщину и ручное управление потоками для работы с асинхронностью например) - отлично будет спросить у кандидата их сравнительный анализ.
Если вы увидели антипаттерны (типичные - спагетти код, god object) и вас это беспокоит - выясните у кандидата как бы он сделал это в коммерческом приложении.
Какие выводы я бы сделал о соискателе (безотносительно ответов на вопросы):
Он любопытен, и программирование скорее всего вызывает у него интерес.
Он будет глубоко копать до сути вещей, а значит скорее подходит для технических задач, и возможно ему даже скучно будет - если вся работа у вас в компании "перетаскивание json" - по этому можно это дополнительно уточнить.
Бонусом - если это джун - то это вероятно как-раз тот самый джун с горящими глазами которого вы ищите.
Pet-проект для себя
Так я назвал проект - который идейно решает какую-то внутреннюю проблему кандидата. Например локальный аналог google photo, своё приложение для управления умным домом, некоторыми устройствами в нём, собственные читалки и т.п.
Чаще всего такие проекты сложнее и больше чем демонстрационные. При этом - если срок поддержки больше ~6 месяцев - то они могут содержать в одном проекте разные подходы к разработке и разный технологический стек (или переходы между стеками в истории).
Коммиты чаще всего содержательны для больших правок, но не подробны, а код вполне может включать большие куски, которые вы бы не пропустили на мр (те-же спагетти код, godobject, куча логики скинутые в одно место, отсутствие di). Проект так-же может иметь неправильно настроенный .gitignore или например небезопасно настроенный di.
С такими проектами мы тоже расходились с коллегами во мнениях - тоже были споры на предмет того, что если человек пишет все данные в файл, а не развернул базу данных или если у него пляшет архитектурный подход от нормальной декомпозиции - до всё в внутри ui компонента - то он не сможет нормально работать.
Практика показывает что наоборот - такие кандидаты зачастую самые крутые специалисты.
Всё дело в том, что домашний проект для личного использования ни в коем случае нельзя сравнивать с коммерческим. Почему? Да потому что задачи - совершенно другие, и как результат - решения для этих задач тоже.
На домашнем проекте - нет необходимости вести везде строгую архитектурную декомпозицию - мы закладываем её для того, чтобы быть устойчивыми к изменению бизнес требований на лету, а в домашнем проекте заказчик и разработчик - одно лицо - и он может гарантировать на уровне обещания самому себе - что никогда не захочет изменять какой-то экран. Тогда вместо того, чтобы городить три слоя архитектуры и разделения данных - можно написать ui код прямо в компоненте, в 3 раза быстрее.
Нет необходимости защищаться от bus-фактора - т.к. потеря разработчика в данном случае = концу проекта. И даже настраивать корректно гит - далеко не всегда важно т.к. ну попали локальные файлы в гит минуя гитигнор - ну в следующий раз через 5 лет, когда потребуется поменять машину для разработки - вливаешь новые.
Так-же нужно понимать что на домашнюю разработку обычно есть часок после работы, а не 40 часов в неделю и час разработки может быть намного дороже, чем красота и чистота кода.
Куда смотреть в таком гите (тут выбор чуть сложнее потому что проекты бывают огромны):
Посмотреть набор последних коммитов и файлы с ними ассоциированные - тут можно увидеть какими инструментами сейчас пользуется кандидат и опросить его о них. Вполне может быть что инструментарий внедрен как попытка обучиться - и исчерпывающих знаний о нём не будет - тогда спросить у кандидата каким инструментарием он пользуется в работе / до того, попросить сравнить новый и старый подход. Можно оценить как кандидат актуализирует свои знания по мере бега технологий вперед, и сложно ли ему обучиться новому.
Посмотреть код который максимально долго не изменялся. По спрашивать - какие изменения в него внёс бы в него кандидат.
Возможным плюсом я бы считал использование сторонних стеков - мы искали узкоспециализированных специалистов (frontend android), но чтобы построить что-то больше todo-листа обычно требуется либо заодно захватить backend (и тут python, js, php etc.) может быть какой-то CI, и другие любопытные вещи вплоть до развёрнутого локально GitLab. И если кандидат без страха залез в сторонние технологии в домашнем проекте - значит не будет воротить нос когда потребуется помощь в CI и у вас, а это всегда плюс.
Если в коде имеется очевидно спорное решение - попросить его аргументировать.
Я обычно еще спрашиваю - почему свой велосипед а не готовое решение, это может дать полезные "софтовые" данные о кандидате - например осмотрительность - если он не доверяет облачным решениям других провайдеров, или любознательность - если он решил проверить сможет ли сам реализовать то, что уже сделали другие, или даже упорство - если ему бросили вызов и он его принял (знавал одного человека, который всю карьеру, причем весьма успешную, построил на том, что в университете ему бросили вызов что он ни за что не сможет).
Какие выводы я бы сделал о кандидате (безотносительно ответов на вопросы):
Кандидат скорее всего горит разработкой. Мало кто, кому не нравится программирование, взялся бы еще и вне работы делать дополнительно хоть что-то.
Если проект с долгой поддержкой - значит скорее всего кандидат уже хапнул на нём легаси, и имеет опыт работы с таковым.
Чем больше проект - тем больше ошибок скорее всего там было допущено, и больше полезных выводов уже сделано. Такой человек позволит вашей команде избежать ошибок которые уже допускал сам.
Это основные варианты гитов, которые я видел. Но рассмотрим и экзотику.
Коммерческий проект
Если кандидат пришел с собственным коммерческим проектом (который выложен в сторы, за него просят денег) - и даёт ссылку на его git.
Всё очень индивидуально - но в целом - я делал в таком случае вывод по двум критериям. Насколько код соответствует написанию нормального корпоративного продукта (послабления как для предидущего варианта возможны, но минимальны). Читайте комментарии в сторе - баги и критику оттуда можно отлично обсудить на собеседовании, особенно если вы по коду можете хотя-бы предположить их причину.
OpenSource возможно даже с кучей звёзд
К сожалению или к счастью - владение например библиотекой - даже с кучей положительных отзывов и звёзд - не гарантирует умение кандидата писать хоть сколько нибудь подходящий вам код. Возможно - он одиночка, который пишет всё с подходом: "как настроение пошло" и в своем уникальном стиле. Но умеет превосходно проектировать api.
В данном случае сценарий совпадает с пунктом выше (про коммерческий проект), но на моей памяти такой кандидат к нам приходил 1 раз, и это был очень сильный разработчик (и у нас на него нехватило денег, но это другая история).
Послесловие
Наверняка я видел не все варианты гита, и бывают разработчики которые скидывают гит в котором кроме readme с "азаза затролил, это никто смотреть не будет" и ничего нет, или гиты с вирусами (тут кстати не забываем запускать всё, что компилируете из кода кандидатов в защищенной среде - в моем случае gradle скрипты я просматриваю, а исполняемые файлы запускаются на тестовом смартфоне) или еще какая экзотика - но я таких даже и не встречал. И однозначно - бывает происходят смешения представленных категорий (например home проект который ведется долго, решает конкретную задачу, но нём обкатываются новые библиотеки как в учебном проекте - чаще всего в отдельных ветках), но в целом в этих случаях - каждая часть просто оценивается отдельно согласно тем-же принципам.
Заключение
Выводы которые я хотел бы донести.
Приложенный к резюме Git ни при каких условиях не должен идти кандидату в минус и уж тем более быть поводом отказа от дальнейших шагов (ну может быть кроме фейковой ссылки/репозитория).
Pet проекты бывают разные и имеет смысл по разному их анализировать.
Код некоммерческих проектов нельзя оценивать по тем-же критериям, что код коммерческих.
Фраза «кто делает хорошо, делает хорошо всегда» - хоть в целом и верна, но с оговоркой - что хорошо написанный код, это тот, что хорошо решает поставленную задачу, и хорошо написанный скрипт - может быть группой сваленных в кашу методов и переменных, в единой области видимости - если задача была написать его за 15 минут, и выкинуть после единичного использования навсегда. Задачи которые ставил для себя кандидат в частном гите вы можете не угадать.
Вылизанный гит для показа — как девушка в полном параде прямо из салона красоты - здорово, но не информативно с точки зрения программиста оценивающего рекрутов (жить потом придётся с тем как она выглядит дома по утрам) - для опытных разработчиков я в целом считаю создание такого проекта минимальным плюсом.
Гит кандидата - это всегда инструмент для дальнейшей беседы. Он отлично подходит для того, чтобы подготовить вопросы и темы для обсуждения перед интревью, а не пытаться нащупать их в процессе, но не для оценки самого кандидата.
Ну и про хайповое: мне пока не попадались кандидаты с вайб-закоженным гитом - но чувствую скоро они появятся. Но... меня это не беспокоит. Если человек не будет способен защитить или аргументировать свой код - он пролетит, и не важно - списал он код с методички, взял у нейросити, или написал за ручку с преподавателем курсов «в IT за 15 минут». А если он код сможет защитить достаточно достоверно, и не посыпется потом на других вопросах - то скорее всего и работать он сможет, даже если код не его (а ведь защищать чужой код сложнее чем свой - в своем ты хотя бы знаешь почему он так написан, а в чужом пойди разбери, хотя - и свой превращается в чужой через пол годика)
Ну и забавная история в завершении.
Один соискатель прислал резюме со ссылкой на Git, который хостил у себя локально - развернул дома сервер, настроил DDNS, выложил проект и, естественно, не озаботился TLS-сертификатами. HR-специалист решила посмотреть его работы, но получила предупреждение о небезопасном подключении (а нынче они ух какие страшные). После этого она доложила начальству о «попытке взлома методами социальной инженерии», которую якобы предотвратила (и, честно говоря, в целом она молодец — всегда начеку), и добавила кандидата в чёрный список.
Через пару дней, когда возник закономерный вопрос «Куда пропал кандидат?», история раскрылась. Git проверили «профессионалы», просмотрели код, а на собеседовании соискатель вместе с нами посмеялся над ситуацией - и в итоге его взяли на работу.