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

Меня зовут Сергей Романов, я работаю в KODE тимлидом бэкенд-разработчиков. Недавно проверял тестовые задания кандидатов на менторскую стажировку и увидел в коде нестандартный для Go архитектурный паттерн. В нем не было ошибки, но обычно пишут не так. Он встретился мне еще в шести заданиях. На втором задании я подумал, что у меня дежавю. На третьем — что ребята списали из одного источника. На четвертом обнаружил пометку «GPT-4», которую автор забыл удалить, и все встало на свои места. 

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

Источник: к/ф «‎Гарри Поттер и Орден Феникса», режиссер Дэвид Йейтс
Источник: к/ф «‎Гарри Поттер и Орден Феникса», режиссер Дэвид Йейтс

Что выдает читера на собеседовании

Внезапное озарение

Кандидат не может решить задачу. Ему предлагают спокойно разобраться с ней попозже. Он соглашается и присылает ответ через пару минут после окончания собеседования. Это подозрительно, ведь только что в течение некоторого времени у него не получалось найти решение. Мы отправляем условие в Chat GPT и получаем дословно такой же текст.

Chat GPT вообще ненадежный подельник, и при первой же возможности сдает с потрохами
Chat GPT вообще ненадежный подельник, и при первой же возможности сдает с потрохами

Резкая уверенность

Перед ответом на вопрос происходит заминка на 5-10 секунд: кандидат чешет в затылке, хмыкает и как бы раздумывает, а затем быстро и уверенно отвечает. Были такие кейсы и во время лайвкодинга — курсор долго находится вне фокуса, то есть кандидата нет на страничке, а затем он возвращается и пишет правильное решение.

Помехи видеосвязи

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

А у вас стена белая

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

Микронаушник

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

Как спалиться в тестовом

Использование ИИ в тестовых заданиях легко заметить:

  • По идентичному стилю, формулировкам и ошибкам у разных людей.

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

  • По низкому качеству перевода на русский язык. Например, «конечная точка API» вместо «API endpoint».

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

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

Пример кода с комментариями
Пример кода с комментариями

Почему читерство — не выход

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

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

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

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

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

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

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

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

Как использовать ИИ во благо

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

Пример не слишком качественно сгенерированной документации
Пример не слишком качественно сгенерированной документации

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

Как же быть в итоге

Короткий ответ: либо списывать так, чтобы не поймали, либо не списывать вовсе. Я склоняюсь ко второму. На мой взгляд, у использования ИИ в тестовых заданиях три причины:

  1. Желание сэкономить время.

  2. Желание спрятать пробелы в знаниях.

  3. Неуверенность в себе и ощущение, что ИИ знает лучше.

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

Во втором случае считаю, что все тайное становится явным. Вместо того, чтобы идти на риск, лучше пополнить знания с помощью глубокого ресерча: почитать статьи или книги, посмотреть видео, покопаться в сообществах. Причем относительно глубокого — по опыту, в некоторых заданиях кажется, что кандидат мог бы найти верное решение после получасового ресерча в Google. Но вместо этого он прочел краткую выжимку из  Chat GPT по диагонали и не добрался до истины. Если на ресерч совсем нет времени, размышляйте самостоятельно и комментируйте ход мыслей. Например, «Не уверен, что здесь пригодится именно этот метод, но раз он может сделать то, то и то, он подходит с вероятностью 90%».

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

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

А вы что думаете?

Комментарии (23)


  1. NikaLapka
    01.11.2024 12:02

    Имхо, выглядит так, чтобы лишь бы избежать личной ответственности. Потому, что лично по моему опыту есть лишь два условия: 1-кандидат, работник, может пользоваться чем угодно, лишь бы в рамках УК РФ :) , а так хоть по телефону у мам, пап, дедушек, gpt,.. консультироваться, всё равно все младшие специальности лучше всего обучаются через накопленный опыт при выполнения задач, 2- тут кто-то возразит, -"но ведь в нужный момент он подведёт и не сможет решить какую-нить задачу!", на что я поправляю, подведёт он не кого-то, а своего начальника - меня, значит я за это и несу ответственность и поэтому именно я предусматриваю, составляю договор, графики работ, и т.п. достаточные для выполнения задачи в случае форс-мажора, а с некомпетентным работником можно и расстаться.


  1. ChePeter
    01.11.2024 12:02

    Нужно наоборот, требовать и проверять умение соискателя решать задачи с ИИ и прочими ChatGPT.

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


    1. alpha_man
      01.11.2024 12:02

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


    1. FireLynx
      01.11.2024 12:02

      Это отдельное умение, важная составляющая которого - суметь оценить правильность выданного ии решения.

      Соответственно, понимание происходящего должно быть.


  1. BadDancer
    01.11.2024 12:02

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


    1. mixsture
      01.11.2024 12:02

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


      1. AdrianoVisoccini
        01.11.2024 12:02

        Уже давно с товарищем обсуждаем идею для собеседований. Товарищ теперь тимлид в Сбере, сказал попробует внедрить. Идея такая:
        Вместо всех душных вопросов, вместо поворота деревьев и прочих алгоритмов, которые как заметил автор не придется использовать на работе в должности, достаточно провести короткую 40-6 минут лайвкодинг сессию на тестовом проекте
        даете соискателю доступ в гит, пусть он при вас
        клонирует проект, запускает его по подсказкам из ридми а дальше даете ему одну из типовых тасок придуманных на ходу. Проект может быть простой - пара контроллеров, пара ручек, банальнейшая бизнес логика, база, миграции ну и докер. Можно варьировать в рамках бизнес домена компании.
        Например - приложение кошелек, которое имеет простые методы типа Withdraw, deposit, getBalanse итд. Дальше просто просишь сделать новую ручку, или переписать существующую, чтобы она делала что-то по другому.
        Будет видно и умеет ли человек с гитом работать и понимает ли структуру приложения и умеет ли читать код и видит ли корнеркейсы и проблемы и глубину познания тоже. Джуну можно простить запись без транзакции, мидл должен знать про пропагации очевидно, можно дать ему задачу на вложенные транзакции.
        При этом задачи должны быть элементарные так как проверить нужно в основном умеет ли человек работать, знает ли где кнопки в IDE понимает ли что с чем связывается и как. Не обзательно даже чтобы он задачу закончил при вас и она работала - и так будет ясно буквально всё. А самое главное - количество задач безгранично и никак подготовиться к этому нельзя, не литкод не поможет не слив типовых задач. Ну разе что наушник в ухе, от него не денешься никуда.


        1. strwolf
          01.11.2024 12:02

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


        1. mixsture
          01.11.2024 12:02

          А зачем тогда существует онбординг по 2 недели (и более)? Ведь в этой сессии вы исходите из того, что собеседуемый уже разобрался в архитектуре проекта. И тогда можно проверить его на реальных задачах. Думаю, что это применимо только в очень небольших нишах - там, где проект небольшой - если у вас условный микросервис на 5 сущностей, его можно окинуть взглядом за 10 минут, то применимо.
          В остальных же случаях это будет проваленное собеседование (причем независимо от знаний соискателя) и масса потраченного времени: как вашей фирмы, так и соискателей.


  1. black1277
    01.11.2024 12:02

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


    1. FireLynx
      01.11.2024 12:02

      Но ещё лучше, если код понятен настолько, что комментарии и не нужны.


      1. strwolf
        01.11.2024 12:02

        да это так


      1. black1277
        01.11.2024 12:02

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


  1. SilverDrakon
    01.11.2024 12:02

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

    А один раз вообще был эпик фейл у кандидата - делали тестовое по SQL в гугл документе (там это удобно, так как в реально времени видно, что и как пишет человек). Так вот, я формулировку второго вопроса ещё не озвучил, а кандидат уже ответ на него вставил копипастом (видимо кто-то из более ранних кандидатов скинул ему все задания).
    Ну, и ещё, если кандидат не "руками" пишет в документе, а где-то там копается-копается, а потом копипастит решение - явно он отправлял задание кому-то, кто ему решал.
    После года проведённых собеседований такие вещи сразу уже бросаются в глаза.


    1. Ravager
      01.11.2024 12:02

      Давно так стали делать? В бигтехе работаете?


  1. strwolf
    01.11.2024 12:02

    Согласен со всем кроме первого. Да это сгенерировал ChatGPT. Чат как раз положительно отвечает почти всегда на любое высказывания по типу "это правда что?" По крайней мере так раньше было. Объясню, скиньте код синьора 5 летней давности и спросите - это сгенерировано СhatGPT? И он в 90% ответит что да.


  1. olku
    01.11.2024 12:02

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

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


  1. MainEditor0
    01.11.2024 12:02

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


  1. conopus
    01.11.2024 12:02

    А я вот думаю: если ChatGPT лучше человека отвечает на вопросы, то может с вопросами что-то не то?


  1. GulDmitry
    01.11.2024 12:02

    Считаю, что это прекрасно, надеюсь, что кто-нибудь выпустит хардварный вариант для прохождения интервью или что-то программное незаметное. Сам проводил лайвкодинги, вяло читая задачу за день до собеседования и, когда кандидат предлагал вариант, в котором я был не уверен, говорил “ну попробуй”. Имея под 500 задач на литкоде, вообще не понимаю, для чего это нужно. Сколько обсуждали, что спрашивают либо то, с чем недавно работали, либо с листочка. Современное интервью — это позор: лайвкодинг, системный дизайн, всякие STAR-системы для ответа на бытовые вопросы — это пиздец, и надеюсь, что языковые модели разъебут эту систему. Говорить, что “а вот наши лайвкодинги даже приятные для соискателя! Мы помогаем, включены, даём даже свою IDE!” Спрашивать C4 на системном дизайне, а потом увидеть, что в реальности даже документации нет. И сами же потом говорят, что пересечений крайне мало, даже давать реально встреченную задачу — сделка с совестью, не более.


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

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


    1. fried_rice
      01.11.2024 12:02

      Какое-то не бизнесовое мышление:) предложенный Вами вариант идеалистичен, на такое мало кто согласится. Подбирать по культуре...хотелось бы, но кандидат может быть лапушкой, но настолько неспособным решать задачи и в принципе работать, что просто горько становится, но, увы, за "хорошего человека" не платят+ не забываем про ТК РФ и почему можно отказывать кандидату: культура не равно деловые и прочие качества.


      1. GulDmitry
        01.11.2024 12:02

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


  1. ArtyomO
    01.11.2024 12:02

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

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

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

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