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

Так это обычно происходит.
Так это обычно происходит.

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

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

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

Разумеется автор не «сразу родился» плотно упакованным техническими знаниями — много лет (и далеко не всегда успешно) он точно также как и вы дорогой читатель, ходил по собеседованиям в качестве кандидата, прежде чем оказаться с другой стороны переговорного стола.

Поэтому успел на собственной нежной психике испытать все описанное в статье.

Если вы вынуждены проводить технические интервью не имея достаточного опыта за плечами — статья специально для вас и точно поможет снизить риски неправильного найма.

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

1. Автотесты

Экспресс‑тесты, квизы, опросники, любые онлайн или оффлайн (на бумаге) системы тестирования, с ИИ или без, основанные на выборе нужных вариантов из набора предложенных — не работают.

Все прекрасно понимаю:

большой поток кандидатов, мало времени и острое желание оптимизировать затраты на проведение интервью самым простым и очевидным способом.

Увы, но так просто проблема оценки технического уровня не решается и все красиво выглядящие задачки, вроде такой:

существуют лишь для траты вашего времени и денег вашей компании — на покупку системы онлайн‑тестов, но не дают вменяемых результатов.

И да (просто обязан был это сообщить):

такими тестами срезаются даже очень сильные инженеры, чьи компетенции вам бы точно подошли

На что есть вполне объективные причины.

1.1. Причины

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

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

На что есть веская причина:

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

Если только вы не хотите заставить кандидата, проходящего такой тест, прочесть 100 страниц технической спецификации для 5 строк кода, разумеется.

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

Если все еще не понимаете о чем речь:

Java это язык программирования, у которого есть множество разных версий: 1.8, 11, 17, 21 — только самые часто используемые.

У языков программирования есть компилятор, интерпретатор или транспилер, а поскольку Java очень популярна — для нее есть все вышеперечисленное, причем разных реализаций и от разных вендоров.

Таким образом код программы на Java можно:

  • скомпилировать, например в байткод или нативное приложение;

  • интерпретировать — выполнять по шагам;

  • перекодировать (транспилировать) в код на другом языке.

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

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

В полностью управляемой Java, можно добиться абсолютно любого поведения пользовательской программы воздействием на рантайм:

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

И все это без каких-либо изменений оригинального кода программы.

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

И поводом для глумежа разумеется.

1.2. Проблема глубины

У автотестов есть еще одна проблема, о которой стоит рассказать:

человеческая память сильно ограничена и не работает по принципу жесткого диска.

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

Поэтому несмотря на то, что сам автор когда-то проходил сертификацию по Java, с ходу и без помощи Гугла (или компилятора) — не сможет уверенно сказать, сработает такой код или нет:

if (obj instanceof String name && name.length() > 10) {
..
}

А между тем этот код взят из задания новой версии экзамена «Oracle Certified Professional: Java SE Developer», который автор когда‑то успешно сдал.

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

Напомню, что за всю свою жизнь видел лишь одного человека, который мог свободно оперировать пунктами спецификации языка Java (JLS) без обращения к документации и интернету.

И этот человек был психически больным (савант).

1.3. Проблема обмана

Наконец третья важная истина, которую вам стоит узнать об автоматических средствах проведения интервью:

любые автотесты — прямое приглашение к обману

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

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

Поэтому как только оставите кандидата наедине с автотестами — у того немедленно появится острое желание эти самые тесты обойти любым способом.

Не потому что он лютый жулик нехороший человек а просто из принципа и на уровне инженерного рефлекса.

Резюмируя:

забудьте про любые автоматические тесты, если собираетесь нанимать нормальных инженеров

2. Стресс-тест

Следущий дурацкий метод, уходящий корнями в 70е — то что называется «стрессовое интервью».

Это необязательно сектантская дичь когда на кандидата орут, выдают сломанный стул с пиками, ударяют по столу кулаком или плескают в лицо водой (хотя когда-то делали и такое) — в современных реалиях «уникальных снежинок» речь идет лишь про «симуляцию стрессовой ситуации» как таковой:

перенос интервью в последний момент, задержка перед началом — то самое «заставить подождать»

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

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

Смысл всего этого цирка — посмотреть как человек будет себя вести в реальной рабочей обстановке когда все вокруг горит:

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

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

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

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

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

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

Поэтому никакая реакция программиста в стрессовой ситуации не является показательной и не имеет отношения к его ежедневной работе:

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

Так что даже если кандидат спокойно переживет дикий ор над ухом и гам за соседним столом — не стоит автоматически записывать его в хорошие инженеры.

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

Как-то так это выглядит со стороны кандидата.
Как-то так это выглядит со стороны кандидата.

3. Групповое интервью

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

Расскажу про другое:

когда одного кандидата собеседуют несколько интервьюеров.

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

Столь радикальное увеличение участников резко усложняет процесс интервью и прикладываемые обоими сторонами усилия:

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

А если собеседников несколько — все усложняется кратно.

Вообще проблематику совместных интервью можно отлично оценить по подкастам блогеров  — некоему упрощенному аналогу интервью:

единицы действительно умеют вести нормальную дискуссию, не перебивая гостя, но даже они — подготовленные и «калиброванные» ведущие с большим опытом начинают лажать при увеличении количества участников.

Теперь представьте каково будет вам и вашим коллегам «от клавиатурной сохи», не занятым 8 часов день в производстве медиаконтента.

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

С-стиль
С-стиль

4. Собственный опыт и выполненные проекты

Два самых известных, самых банальных и самых надоевших вопроса любого интервью: «расскажите о собственном опыте» и «расскажите о выполненных проектах» — на 2025й год перестали работать окончательно.

Так что пожалуйста перестаньте их задавать.

Не то чтобы они идеально работали в прошлом или работодателя действительно волновал ваш предыдущий опыт, просто теперь кандидаты спокойно пишут в своем резюме «работал в Яндексе курьером» или «чинил андронный коллайдер в CERN».

Резонно полагая, что проверить факты у вас все равно не выйдет.

Ну не будете же вы в самом деле звонить в Яндекс, выясняя работал ли там на должности «Senior‑Pomidor Developer» Вася Пупкин с 2020го по 2023й годы.

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

Считаю что все доступное время интервью стоит потратить на выяснение и оценку текущих навыков, не прошлых или будущих а только тех что есть в голове у кандидата на момент интервью.

И текущего состояния психики — все эти ваши «soft skills», опрятный внешний вид и уникальный навык смывать за собой воду в туалете — на самом деле важны.

Не поверите, но так тоже бывает (и чаще чем хотелось бы):

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

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

Кстати возрасту и большому стажу в ИТ тоже не стоит доверять просто так:

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

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

Тот самый красный флаг
Тот самый красный флаг

5. Ловля на ошибках

Наконец последний по списку, но далеко не последний по важности метод, который вам точно стоит забыть и прекратить применять на интервью, можно лаконично описать известной идиомой:

докопаться до столба

Придирки к словам, мелкие неточности в терминах (например неправильное произношение) или невозможность ответить на какие-то специфические вопросы — не повод считать кандидата идиотом плохим специалистом.

В качестве примера:

однажды автора во время интервью попросили рассказать как работают блокировки в PostgreSQL, но только не снаружи — из процедур и запросов, а.. изнутри, внутри самого сервера СУБД.

Не представляю чего ожидал услышать интервьюер и к чему вообще был столь интересный вопрос, но на предлагаемом проекте PostgreSQL не использовался совсем, а «экспертные» знания этой СУБД автор никогда не заявлял.

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

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

Но абсолютно точно — не про знание всех до единого методов модного в этом сезоне фреймворка.

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

Поскольку:

понимание принципов работы всегда важнее знания тонкостей реализации.

Если конечно вы действительно хотите нанять хорошего и умного инженера.

Эпилог

Проверять уровень технических знаний одного человека должен другой технически грамотный человек а не машина.

Да это долго, сложно и муторно, еще это стоит денег.

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

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

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

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

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

Но как в иностранных океанах, так и в нашем отечественном ИТ-болоте работает один и тот же метод противодействия:

уровень технических знаний и компетенций человека проверяет другой технически грамотный и компетентный человек.

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

P.S.

Оригинал статьи в более вольном изложении можно найти в нашем блоге.

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

мы готовы помогать с проведением технических собеседований, если ваша компания сейчас нанимает.

Контакты в профиле.

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


  1. panzerfaust
    02.07.2025 18:36

    Да это долго, сложно и муторно, еще это стоит денег.

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

    Удивительно, уже вторая статья за день с тем же посылом. Но все равно не дойдет.

    И да, упомянутые автотесты - позавчерашний день. Уверен, сейчас будут вливать миллиарды в индустрию AI-assisted собесов. Но ровно с тем же результатом.


    1. alex0x08 Автор
      02.07.2025 18:36

      уже вторая статья за день с тем же посылом

      скорее некоторые выводы совпадают, с рядом моментов я бы поспорил.


  1. verasokolovaip
    02.07.2025 18:36

    1. Заставить человека ждать от 40 минут

    2. Плеснуть ему в лицо воду

    3. Заставить проходить автотесты, причем за его спиной должны стоять минимум 4 человека и комментировать каждый шаг


    1. kompilainenn2
      02.07.2025 18:36

      Плеснуть ему в лицо воду

      чтобы разбудить или что?


      1. Rive
        02.07.2025 18:36

        Чтобы файербол не скастовал.


  1. puchuu
    02.07.2025 18:36

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


    1. ahdenchik
      02.07.2025 18:36

      А можно пример такой задачи?


    1. randomsimplenumber
      02.07.2025 18:36

      Хороший тамада, интересные конкурсы ;)


  1. botyaslonim
    02.07.2025 18:36

    Никогда не видел, чтобы программистов нанимали через стрессовое интервью.

    «расскажите о собственном опыте» и «расскажите о выполненных проектах» — на 2025й год перестали работать окончательно.

    - а вот это не так. Ничто так не выдаёт уровень саморефлексии человека, как рассказ о себе. Всегда пользовался и всегда буду, потому что человек выдаёт максимум информации на таком рассказе, и не только словами. Интервьюеру достаточно только грамотные вопросы иногда подкидывать


    1. alex0x08 Автор
      02.07.2025 18:36

      Ничто так не выдаёт уровень саморефлексии человека, как рассказ о себе

      "Пьем мы как-то с Илоном водку, тут заходит Марк Цукерберг и приносит с собой еще закуси. Так и появилась концепция автономных роботов с ИИ - чтобы кучерявому за добавкой бегать не пришлось. Все так и было! И я там был и лично участвовал."

      Это я в красках сейчас рассказал что временами на голубом глазу выдают кандидаты пытаясь впечатлить.

      Ржать в голос или еще как-то серьезно реагировать вам при этом нельзя, как и немедленно выгонять - не поймут-с.


  1. santjagocorkez
    02.07.2025 18:36

    А потом один технически грамотный специалист заваливает оценку другому технически грамотному специалисту до отказа в найме. А почему? Да всего лишь потому, что тот произносит “true” вот так: “трау”. А поправлять, как мы уже выучили, является «докапыванием до столба».

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


    1. alex0x08 Автор
      02.07.2025 18:36

      А потом один технически грамотный специалист заваливает оценку другому технически грамотному специалисту до отказа в найме

      С этим ничего не поделать и действительно бывают отказы не по причине компетенций.

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

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

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

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