Политика найма в большинстве компаний оставляет желать лучшего. Они просто тратят своё и наше время (я как-то проходил собеседование из 9 этапов!). Они охотятся на передовых программистов и при этом даже не могут отличить реальных людей от LLM. Короче, в манибол они явно не играют.

Для соискателей картина тоже выглядит тоскливо. Некоторые из лучших знакомых мне программистов (среди которых мейнтейнеры компилятора Rust) не могут найти работу, так как теряются под воздействием стрессовых факторов собеседования. Одному такому человеку, который уже более 4 лет работает с Haskell и более 2 лет — с Rust, рекрутёр прямо сказал, что тот «не технарь». Плюсом ко всему компании могут неделями, а порой и месяцами мурыжить людей, не давая понять, приняли их на работу или нет.

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

Как должно выглядеть правильное собеседование

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

Собеседования должны:

1. Дифференцировать соискателей. То есть позволять отличить senior-разработчика от маркетолога, использующего ChatGPT.

2. Быть прозрачными. То есть отражать фактические должностные обязанности.

   • Сюда входит написание кода, а также проектирование архитектуры, ревью пул-реквестов, документирование и так далее. Все хорошие senior-разработчики являются универсалами.

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

   • Люди — не разменный товар.

   • Потеря сотрудников, хорошо подходящих в проект, стоит недёшево.

   • Потеря сотрудников в целом тоже обходится дорого.

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

4. Экономить время. То есть занимать у обеих сторон минимум необходимого времени.

   • Время инженера стоит дорого.

5. Строиться на уважении. То есть уважать соискателя и его время.

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

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

Есть ещё 6-й критерий, который может оказаться более спорным. Назовём его вкус. Инженер с плохим вкусом может очень быстро штамповать решения, оставляя за собой бардак, который приходится подчищать остальным участникам команды. Измерять это качество очень трудно, но важно. И, напротив, сотрудник, который вкладывает время в повышение качества работы команды, в разы повышает её эффективность (к примеру, выполняя роль «человека-клея»).

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

Live-coding, или собеседование по LeetCode

Не отвечает критериям дифференцирования, прозрачности, уважения и вкуса. Очень слабо демонстрирует потенциальную долгосрочную ценность сотрудника. Live-coding не позволяет отличить senior-программиста от маркетолога, использующего ChatGPT, и большинство вопросов на подобном собеседовании слабо связаны с повседневными обязанностями. Все грамотные инженеры являются специалистами широкого профиля, а тестирование в формате live-coding не ориентировано на проверку таких качеств.

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

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

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

Задания «на дом»

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

Проектирование архитектуры

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

Знакомство с командой

Я редко встречал использование таких собеседований при найме людей, но их часто проводят при переводе сотрудников внутри компании. С ними во многом сопряжены те же недостатки, что и в случае проектирования архитектуры, только обычно они не подразумевают оценку навыков. В основном здесь оцениваются личностные качества и то, насколько человек «подходит» команде. То есть тут у нас страдает аспект дифференцирования и отчасти прозрачности. Думаю, такой вид собеседований уместен, когда соискатель имеет твёрдую рекомендацию, и конкурентов на должность мало. Либо у вас может быть какая-то иная причина для высокой оценки навыков этого человека без формального анализа.

Расширенное эссе и примеры работы

Интересный вариант. Такое собеседование я встречал только в компании Oxide Computer Company. Мне этот подход очень нравится. Вот его схема:

1. Соискатель отправляет примеры своей текущей работы (или пишет новые документы специально для собеседования).

2. Далее он пишет подробные ответы на 8 вопросов, касающихся его ценностей, работы, карьеры и целей.

3. Потом ему нужно пройти 9 часов собеседований с несколькими сотрудниками компании.

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

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

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

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

Код-ревью

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

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

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

Каким я вижу более эффективное собеседование

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

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

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

Благодарю за чтение! Надеюсь, эта статья вдохновит вас изменить собственные процессы найма или хотя бы написать в комментариях контраргументы. Также можете написать мне лично на e-mail.

Сноска

1.   Дополнение после публикации: один мой товарищ сказал, что видел, как люди успешно применяют ChatGPT для прохождения собеседований по проектированию архитектуры. Да уж… ↩