Преамбула

За последние годы в IT у меня сформировалось четкое ощущение, что мало того, что рекрутмент как явление сломан в силу множества причин, одна из которых - некомпетенция акторов этих процессов, так ещё и собеседования от самих же IT специалистов вызывает огромные вопросы по всем тем же причинам.

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

Небольшое уточнение 1

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

Небольшое уточнение 2

Здесь я рассмотрю только технические собеседования. С софтовыми собесами у меня проблем никогда не возникало. Да, есть проблема в странных вопросах, на которые больно и неприятно отвечать, например: "Назовите 3 своих главных недостатка", где тебе нужно как уж на сковородке вертеться, чтобы попасть в категорию "вайбовый" от HR'а. Но к таким собеседованиям всегда можно подготовиться, проработать все, даже самые глупые вопросы, и далее на опыте проходить такие собеседования без особых проблем.

В общем, проблема HR-собесов у меня на повестке дня не стоит, и я не считаю, что они ломают собеседования в целом.

Почему все плохо?

Вопрос достаточно сложный и комплексный. Собеседования все проводят по-разному. Где-то, как в Яндексе, по миллиону этапов, где тебя стараются загасить, чтобы по итогу дать тебе ЗП ниже рынка с обоснованием: "Ну ты же плохо прошёл 2586'ой этап, где тебе нужно было, балансируя на канате, жонглировать бензопилами, рассказывая наизусть "Войну и мир". Поэтому мы считаем, что такой оффер оправдан.". И я не буду рассматривать данный тип собеседований. Где-то, как в 99%* IT-компаний, тебя как какого-то второкурсника спрашивают на экзамене термины, которые ты выучил только ради этого экзамена, а в непосредственной работе тебе это пригодится дай Бог 1 раз, и то не факт.

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

Не ищутся подходящие специалисты

Когда вы пытаетесь нанять специалиста, вам нужно идти на компромиссы. Нельзя нанять дешёвого, компетентного специалиста быстро. А если ваши критерии достаточно высокие к кандидатам, то дешево и быстро не получится практически никогда. Кто-то идет на эти компромиссы, а кто-то просто кричит на весь мир, что всё несправедливо, кругом враги, и ничего поделать нельзя.

В случае с техническими собеседованиями всё сложно, и нужно разбираться.

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

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

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

Почему проблему не решают?

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

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

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

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

Рыба гниёт с головы, а найм в компаниях - с нанимающих менеджеров. Далее по цепочке HR по абстрактным описаниям пишут абстрактные вакансии, на них откликаются сотни и тысячи людей. Не из-за шаблонности, а в целом из-за кризиса найма и перекоса в сторону работодателя. А HR будучи, скорее всего, таким же некомпетентным человеком (вы где-нибудь видели курсы/лекции/направления в университетах по HR мастерству? Я тоже нет) вместо того, чтобы делать свою работу, пойдет подключит ATS, включит автофильтры и неспеша будет разгребать те вакансии, которые понравились системе.

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

Что можно сделать?

Так или иначе, можно было уже сделать вывод, что просто задавать глупые однотипные вопросы на собеседовании - это не выход. Тогда что можно сделать?

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

Такой подход экономит кучу времени и вам, и кандидату. Можно пройтись по базовым вопросам за 15-20 минут, и по итогу остановиться только на них, не переходя к уже более прикладным вопросам.

Прикладные вопросы в нашем случае - это вопросы 2 типов:

1. Вопросы, которые непосредственно связаны с будущей деятельностью кандидата в кампанию.
2. Вопросы, которые помогут отсеять людей, на самом деле не имеющих релевантного для работы или описанный в резюме опыта.

Выглядит так, будто оба пункта по сути являются 1 пунктом, но нет.

В первом случае мы задаем вопросы, связанные с нашей доменной областью. Например, если это платежная система, жизненно важно знать, работал ли кандидат с такими системами; что знает про транзакционность и двухфазные коммиты; а может, как эти двухфазные коммиты избежать, и много другое. Да, я сам говорил, что в целом не обязательно, чтобы кандидат имел опыт в нужной вам сфере. Главное - понимание того как работать. Тут вопросы нужно задавать, если вам нужен именно специалист, а не тот, кто умеет работать. Это разное, не перепутайте.

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

И по мне так второй тип вопросов очень сложно задавать, если у задающего нет заинтересованности в этом. И мы снова возвращаемся к некомпетентности, но тут не совсем про неё. Скорее про отсутствие мотивации задавать такие вопросы.

На самом деле, я довольно редко слышал на техническом интервью вопросов про свой опыт. Все такие вопросы заканчивались на этапе с HR'ом, и никуда дальше не шли. А если даже и были вопросы, они не заходили глубже уточняющего вопроса: "А как именно ты это сделал?". Этого не достаточно для выявления кандидата, который не умеет на самом деле это делать, а просто написал в резюме этот пункт. Нужно копать глубже, и если кандидат начинает сыпаться, то это уже звоночек.

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

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

Послесловие

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

Вся эта статья - не крик души, не отчаянная попытка поменять устоявшийся уклад вещей. Я лишь накинул идею для обсуждения. Может, статью прочитает какой-нибудь head of <чего-нибудь>, и подумает: "Блин, а ведь действительно это проблема" и пойдет поднимать вопрос о корректировки работы найма конкретно у себя в кампании.

Звучит так, будто я не стою за свои слова, и пытаюсь дать себе "пути отхода" или, по-другому, сказать: "обоссыте, но не бейте", но нет. Я лишь пытаюсь сказать, что моя статья не отражает полной картины найма. Где-то я пошёл на упрощение, где-то явно что-то сам не до конца понимаю, поэтому решил опустить. Но от идеи я точно не отказываюсь, и решение проблемы буду продолжать отстаивать, если не паду под шквалом хорошей аргументацией**.

Примечания по тексту

* 99% по моим ощущениям. Статистика собрана по тем собеседованиям, в которых непосредственно я участвовал, а также по тем собесам, которые я видел в записи от своих учеников (Без нарушения закона о персональных данных. Без видео, а голос был искажен).

** Знаю, какими программисты могут быть грубыми и нетактичными. Просто сказать, что "афтар дурак" - это не аргумент.

*** Текст был написан без использования нейросетей. Если вы увидите в моем тексте длинные тире или странные формулировки, то будьте уверены, что это всё написал я своими руками. Да, я пишу длинные и средние тире. Это норма копирайтинга. Не кидайтесь на само собой разумеющиеся вещи.