Как не надо собеседовать

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

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

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

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

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

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

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

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

1. Автотесты

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

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

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

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

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

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

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

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

1.1. Причины

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюмируя:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поскольку:

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

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

Эпилог

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

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

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

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

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

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

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

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

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

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

P.S.

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

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

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

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