Как не надо собеседовать
Пришло время рассказать широкой аудитории про методы, которые больше не работают для технических интервью в 21м веке.
Разумеется автор не «сразу родился» таким умным и плотно упакованным техническими знаниями господином — много лет (и далеко не всегда успешно) он точно также как и вы ходил по собеседованиям в качестве кандидата, прежде чем оказаться с другой стороны переговорного стола.
Поэтому успел на собственной шкуре и нежнойжопепсихике испытать все описанное ниже в этой статье.
Если вы вынуждены проводить технические интервью не имея достаточного опыта за плечами — статья специально для вас.
Надеюсь что хотя-бы часть кринжа и позорных печальных практик, принятых в ИТ-индустрии, моя работа поможет изжить.
1. Автотесты
Экспресс-тесты, квизы, опросники, любые онлайн или оффлайн (на бумаге) системы тестирования, основанные на выборе нужных вариантов из набора предложенных — не работают.
большой поток кандидатов, мало времени и острое желание оптимизировать затраты на проведение интервью самым очевидным способом.
Увы, но так просто проблема оценки технического уровня не решается, поэтому все красивые задачки вроде такой:
существуют лишь для траты вашего времени и денег (на покупку такой системы онлайн-тестов), но не дают вменяемых результатов.
1.1. Причины
Постараюсь вкратце объяснить суть претензий для читателей, не отягощенных высшим техническим образованием.
Дело в том что во всех подобных тестах код задачи всегда абстрактен и не учитывает окружение, зато варианты ответов подаются максимально однозначными.
детально формализовывать окружение для каждого теста можно слегка за#баться, тем более что учесть абсолютно все нюансы в любом случае не выйдет.
К сожалению в программировании (как и в любой другой области) между абстракцией и конкретным результатом находится натуральная пропасть, которую в былые времена собственно и обсуждали на интервью приличные джентельмены.
Если все еще не понимаете о чем речь:
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. Групповое изнасилование интервью
Не буду затрагивать вариант, когда одновременно собеседуют стадо несколько человек на одну должность, поскольку так поступают для куда более простых работ вроде грузчиков, курьеров, сантехников — кого-угодно, но не дорогих разработчиков в ИТ.
когда одного кандидата собеседуют несколько интервьюеров.
Причин для такого действа может быть множество, например высокая должность на которую собеседуют кандидата, нехватка собственных компетенций у интервьюеров или даже политика компании — да, так тоже бывает.
Столь радикальное увеличение участников резко усложняет процесс интервью и объем прикладываемых усилий обоими сторонами для его проведения:
далеко не все умеют вести диалог — не перебивать друг друга, давать высказаться и вовремя переключаться.
А если собеседников несколько — все усложняется кратно.
Это нетрудно заметить по например подкастам блогеров — некоему аналогу интервью, единицы из них умеют вести дискуссию даже вдвоем, не говоря уже о группе.
По личному опыту могу сказать что ни одно из собеседований, на которых меня собеседовало несколько человек ничем хорошим не закончилось, поэтому когда сам оказался на другой стороне переговорного стола — старался всеми силами не пускать на интервью посторонних.
4. Собственный опыт и предыдущие проекты
Два самых известных, самых банальных и самых надоевших вопроса любого интервью: «расскажите о собственном опыте» и «расскажите о ваших предыдущих проектах» — на 2025й год перестали работать окончательно.
Так что пожалуйста перестаньте их задавать.
Не то чтобы они идеально работали в прошлом или работодателя действительно волновал ваш предыдущий опыт, просто теперь кандидаты спокойно пишут в резюме «работал в Яндексе курьером» или «чинил андронный коллайдер в CERN».
Резонно полагая, что проверить факты у вас все равно не выйдет.
Ну не будете же вы в самом деле звонить в Яндекс, выясняя «работал ли там на должности Senior-Pomidor Developer Вася Пупкин с 2020го по 2023й годы».
Поэтому не стоит тратить время, выясняя где и кем кандидат работал и чем на самом деле занимался — все это (внезапно) не так важно, поскольку даже при наличии реального, а не вымышленного опыта и стажа в хорошей компании человек запросто вам может не подойти.
Считаю что все доступное время интервью стоит потратить на оценку текущих навыков, не прошлых или будущих, а только тех что есть в голове у кандидата на момент интервью.
И текущего состояния психики — все эти ваши «soft skills», опрятный вид и навык смывать за собой воду в туалете.
Не поверите, но так тоже бывает:
отличного в недавнем прошлом, подававшего большие надежды программиста внезапно накрывает шиза, с чего он перестает мыться, бриться ипохмелятьсяменять нижнее белье, зато начинает общаться с «духами компьютерных предков», получая сигналы из космосалично от Илона Маска.
И получается что резюме отличное, навыки и знания — впечатляющие, но только сам человек — шиз, которого из дурки выпускать нельзя.
Кстати возрасту и большому стажу в ИТ тоже не стоит доверять просто так:
в нашей отрасли полным полно «сбитых летчиков», когда-то занимавших высокие посты и делавших крутые проекты, но в нынешнем состоянии ни на что не годных.
Поэтому увы, но придется собеседовать всех, даже если кандидат старше вас в два раза, с бородой до пояса и называет «сынок» — это не повод автоматически считать его достойным инженером.
5. Ловля на ошибках
Наконец последний по списку, но далеко не последний по важности метод, который вам точно стоит забыть и прекратить применять на интервью, можно лаконично описать известной фразой:
Придирки к словам, мелкие неточности в терминах (например их неправильное произношение) или невозможность ответить на какие-то специфические вопросы — не повод считать кандидата идиотом плохим специалистом.
однажды автора во время интервью попросили рассказать как работают блокировки в PostgreSQL, но только не снаружи СУБД — из процедур и запросов, а изнутри, т.е. внутри самого сервера.
В душе не #бу не представляю чего тогда ожидал услышать интервьюер и к чему вообще был столь интересный вопрос, но на предлагаемом проекте PostgreSQL не использовался совсем, а «экспертные» знания этой СУБД автор никогда не заявлял.
Если когда-нибудь попадете на собеседование в компанию уровня FAANG — сможете лично убедиться, что реальную ценность имеют лишь системные и глубокие знания, но не «веяние моды» или знание деталей реализации.
там точно не станут спрашивать «что делает эта функция» или «какой будет результат выполнения», а большая часть вопросов будут про логику, мышление и уровень понимания предмета.
Но абсолютно точно — не про знание всех до единого методов очередного модного фреймворка.
Считаю что вам также стоит отходить от «мещанских» вопросов о тонкостях конкретной реализации (даже если сейчас это является больным местом вашего проекта) и попытаться сфокусироваться на вопросах принципов и логики:
понимание принципов работы всегда важнее знания тонкостей реализации
Если конечно вы действительно хотите нанять хорошего и умного инженера.
Эпилог и наставления
Проверять уровень технических знаний одного человека должен другой технически грамотный человек.
Да это долго, сложно и муторно, еще это стоит денег.
Но никаких других вариантов к сожалению нет, не было и не будет в обозримом будущем.
И каждый раз когда будете пытаться «срезать углы» в кадровом вопросе, доверившись сертификатам кандидата, его прежнему опыту в предыдущих крутых местах, внешним рекомендациям или автоматическому тестированию — каждый раз будет риск больших потерь.
Поскольку нанимаемый человек запросто может оказаться не тем за кого себя выдает.
Нельзя сказать, что вся эта паранойя и на#балово характерны лишь для нынешнего «особо аморального» поколения айтишников или только отечественного ИТ — желающих получать большие деньги ничего не делая и ни за что не отвечая было много и в 90е.
Причем по обе стороны Атлантики.
Мой опыт общения с иностранными коллегами показывает, что наши отечественные шерстяные жулики, пытающиеся заскочить в ИТ любым возможным способом — малые дети, по сравнению с чудовищами, что водятся в большом европейском или американском ИТ.
Но как в иностранных океанах, так и в нашем отечественном ИТ-болоте работает один и тот же метод противодействия:
уровень технических знаний и компетенций человека проверяет другой технически грамотный и компетентный человек.