Git-детектив: как проверить, что код кандидата – действительно его собственный

За последние годы найм ИТ-специалистов оброс новым вызовом: как убедиться, что кодовое решение, присланное кандидатом, написано именно им, а не позаимствовано в интернете или сгенерировано ИИ. Сегодня, когда удалённая работа и тестовые задания «на дому» стали нормой, всё чаще HR-специалисты и тимлиды задаются вопросом: «Кто на самом деле автор этого кода?» В этой статье разберёмся, как привычные инструменты разработчиков – прежде всего Git – помогают пролить свет на происхождение кода кандидата, и какие приёмы используют компании, чтобы выявлять плагиат и подтверждать подлинность навыков соискателей.

Новый вызов для HR: чужой код под видом своего

В реальной работе программисты постоянно переиспользуют чужой код – и это нормально, даже рекомендуется. Зачем изобретать велосипед, если решение общедоступно? Использование чужих наработок сокращает время разработки и повышает надёжность, ведь код уже обкатан (источник recruitingdaily.com). Однако при найме такая практичность играет против нас: если кандидат просто скопировал готовое решение, оценить его собственные умения невозможно.

Получается иллюзия квалификации. Как отмечает исследование HireVue, плагиат в технических заданиях сводит на нет цель оценки — мы не различим, кто действительно понимает код, а кто лишь выдал чужое за своё. В итоге компания рискует нанять человека, чьи реальные скиллы не соответствуют блестящему (но не своему) решению, или наоборот – отсеять хорошего разработчика из-за ложных подозрений.

HR-менеджеры и тимлиды уже столкнулись с этой проблемой. В эпоху обилия готовых решений на Stack Overflow и GitHub дежавю при проверке тестовых заданий стало тревожным звоночком. Сайты вроде LeetCode наполнены классическими задачами и их решениями – стоит такой задаче попасть в тестовое, и через некоторое время решение всплывёт онлайн (источник medium.com). Неудивительно, что по опыту техлидов значительная часть присылаемых работ содержит заимствованный код.

В одном случае кандидат умудрился скопировать решение самой задачи прямо из блога интервьюера (курьёз, частично вина самого интервьюера, опубликовавшего код в открытом доступе). Часто плагиат виден невооружённым глазом: достаточно загуглить парочку нетривиальных строк из решения – и поисковик тут же укажет источник. По словам одного автора, «в большинстве случаев плагиат легко обнаружить через Google или по коду нескольких кандидатов».

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

Конечно, прямое копирование – не единственный риск. Сегодня появился новый, более изощрённый способ сдать «чужую» работу: сгенерировать код при помощи больших языковых моделей вроде ChatGPT. Такой код может оказаться уникальным и не быть помечен плагиат-детекторами, ведь он не скопирован из существующего репозитория. Тем не менее авторство кандидата здесь иллюзорно – это решения, предложенные ИИ. Как отмечают в Codeaid, появление AI-кода – свежий вызов: пока не до конца понятно, как оценивать его роль в тестовых заданиях, но очевидно, что на горизонте новая проблема (источник codeaid.io).

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

История коммитов как детектор правды

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

Как советует опытный разработчик Кирилл Розов, кандидату стоит «оформлять историю в Git», то есть делать много осмысленных коммитов по ходу работы (источник habr.com). Для проверяющего наличие такой истории – подарок: виден весь процесс, шаги мысли, эволюция решения. Можно понять, как человек разбивал задачу на части, какие делал правки, как именовал коммиты и ветки. По сути, история коммитов показывает ход мысли разработчика – то, чего не увидеть по итоговому коду.

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

А что настораживает? Ситуация, увы, типичная: в репозитории кандидата один-единственный коммит, в котором сразу лежит весь готовый проект. Именно с таким сталкивался Розов, просматривая тестовые задания: «Зачастую проекты, которые кандидаты отправляют, содержат весь код в одном локальном коммите. Ты не знаешь, что происходило – истории не видно».

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

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

Так что первый совет для HR: требуйте у кандидатов представить Git-репозиторий с историей изменений. Если даёте своё тестовое задание – прямо укажите, что оценивать будете и историю коммитов тоже. Это простое условие отсеет самых ленивых любителей копипасты.

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

Например, если репозиторий публикуется на GitHub, там фиксируется время push – загрузки коммитов на сервер, и это может разоблачить нарочно проставленные ретродаты (источник stackoverflow.com). В реальных кейсах такие хитрости встречаются крайне редко – куда чаще мошенники надеются, что проверяющий вообще не заглянет в историю. Но профессионалы заглядывают обязательно, и кандидаты об этом знают. Не случайно сегодня на профильных ресурсах советуют начинающим разработчикам: следите за чистотой и структурой своего Git, ревьюерам это важно.

GitHub не даст соврать: смотрим на вклад соискателя

Ещё один сценарий: кандидат указывает в резюме ссылку на GitHub, дескать, вот мои проекты, смотрите код. Тут HR-специалисту (или нанимающему разработчику) полезно уметь «покопаться» в деталях. Во-первых, стоит убедиться, что проект действительно его. Иногда соискатели форкают популярные репозитории или выкладывают шаблонные проекты, слегка их изменив.

Признак тревоги – если в GitHub-репозитории множество чужих коммитов. К счастью, на странице проекта легко увидеть, кто автор большинства коммитов: можно нажать на вкладку Contributors (или воспользоваться командой git shortlog локально), чтобы посмотреть статистику вкладов. Если имя кандидата фигурирует как основной автор – уже хорошо. Если же большая часть кода написана другим человеком (или коммиты помечены странными адресами e-mail), стоит задать вопросы.

Полезный инструмент – команда git blame или функция “Blame” на GitHub, которая показывает автора каждой строки кода. Обычно её применяют, чтобы выяснить, кто и когда внёс конкретное изменение, но в контексте найма git blame может помочь понять, не состоит ли решение целиком из вставленных фрагментов. Например, если файл явно скопирован из другого проекта, у оригинала могут быть характерные комментарии или стилистика, выдающие чужое авторство. Конечно, плагиаторы обычно чистят комментарии и переименовывают переменные, чтобы замаскировать копию (источник habr.com). Но и это можно заметить: неестественные стили именования, разные стили кода в разных частях решения – всё это красные флажки.

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

Инструменты против копипаста: от MOSS до мониторинга

Помимо ручного изучения истории, существуют и автоматические средства проверки кода на заимствования. Многие платформы для проведения онлайн-кодингов (HackerRank, CodeSubmit, Яндекс.Контест и т.д.) внедряют системы поиска схожего кода. Один из известных алгоритмов – MOSS (Measure of Software Similarity), разработанный в Стэнфорде. Он сравнивает присланное решение с базой ранее сохранённых решений и вычисляет процент совпадения. Например, в системе HireVue код кандидатов автоматически прогоняется через MOSS, и если совпадение подозрительно высокое, кандидат помечается как возможный плагиатор. Конечно, порог схожести – тонкий момент. Совпадение 100% явно указывает на копирование, а вот 20-30% может получиться и случайно, особенно в небольших программах, где у всех решения похожи.

Поэтому специалисты советуют: использовать результат плагиат-чекера как сигнал, но не как приговор. Всегда стоит вручную перепроверить код, дать кандидату шанс объяснить схожесть. Разные компании по-разному относятся к доле открытого кода в решении – важно заранее определить политику. Совет от экспертов: обсудите с техническим руководителем, что вы считаете недопустимым плагиатом, и донесите эти ожидания до кандидата. Например, можно прямо сказать в задании: «Просим реализовать решение самостоятельно. Использование сторонних библиотек – ок, копирование готовых решений из интернета – не ок». Это честно по отношению к кандидатам и обезопасит вас от лишних споров на этапе проверки.

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

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

Беседа по коду – последний экзамен

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

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

Можно попросить кандидата внести небольшое изменение в свой код или дополнить функциональность в режиме реального времени. Например: «Хорошо, у тебя получилось решение со статическим вводом. А как бы ты расширил программу, чтобы она обрабатывала несколько случаев подряд?» Реакция скажет о многом. Человек, писавший код, обычно сразу включается в задачу и начинает кодить или рассуждать вслух, а плагиатор – теряется, ведь он не понимает внутренней кухни решения.

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

Вывод: комплексный подход к проверке кода

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

Автоматические плагиат-детекторы (MOSS и аналоги) быстро сигнализируют о подозрительной схожести, а мониторинг действий при выполнении задания укажет на странные паттерны (например, массовый copy-paste). Наконец, живая беседа по решению расставит все точки над i, выявив реальное понимание. Такой многоуровневый подход отсеет большинство случаев обмана.

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