Я несколько лет провожу технические интервью frontend‑разработчиков и за это время, на основе общения с кандидатами, а также обратной связи от них, выделил для себя наиболее частые проблемы, с которыми сопрягается проведение технических собеседований, — как со стороны соискателей, так и со стороны компании‑нанимателя.
Хочу поделиться мыслями о том, как можно решить эти проблемы или хотя бы минимизировать причиняемый ими урон. Возможно, мои наблюдения пригодятся тем, кто ищет новое место работы или сам проводит технические интервью и считает, что что‑то в нашем мире нужно менять.
Дисклеймер: статья отражает личное мнение автора и может не совпадать с видением компании, в которой он работает. |
Проблемы, с которыми сталкиваются интервьюеры
№ 1. Вранье соискателем в резюме, большое количество вкатунов
Большая часть вкатунов отсеивается до проведения технических собеседований, но иногда такие кадры доходят и до них. Важно помнить, что даже если человек решил по методичке все задачи, это не гарантия того, что он разбирается в предметной области.
№ 2. ИИ на собеседовании
Иногда на собеседованиях люди начинают юлить, а через некоторое время выдают дословное определение из документации, что, естественно, не может не вызывать подозрений. Навык использования ИИ, конечно, полезен. Однако есть база, которую важно знать, для нахождения на определённых должностях. Обман на интервью — это «red flag» (сразу представляется, что такой человек подставляет команду не выполнив обещания, или написав код низкого качества).
№ 3. Поиск задач, отражающих реальную специфику работы
Хороший спец скорее всего, сможет и на алгоритмы порешать задачи, и ответить, сколько раз в спецификации ECMAScript повторяется словосочетание «event loop». Но эти навыки и знания не смогут гарантировать, что он сможет корректно выполнять свои трудовые обязанности. Поэтому одни из моих любимых видов задач — рефакторинг или поиск багов. Вне зависимости от специфики проекта, этих видов работ не избежит ни один разработчик.
№ 4. Специфичная для некоторых должностей проблема: понять, насколько соискатель умеет в AI‑assisted разработку
Крупные компании уже активно внедряют в свои процессы ИИ‑агентов. Единого стандарта рынка нет — все пробуют разные подходы и набивают шишки. Но в любом случае эти инструменты с нами уже навсегда, и требования по навыкам работы с этими инструментами будут только расти. Ну а после того, как крупные компании смогут получить положительный эффект и наработать определенные good practices, их будут просто обязаны применить и компании поменьше, если захотят выжить.
Все еще открытый вопрос: а нужно ли проверять на собеседованиях навыки AI‑assisted programming?
Мы же не проверяем все технические навыки соискателя, а полагаем, что он умеет пользоваться Git, IDE, Docker и, в конце концов, операционной системой выдаваемого корпоративного оборудования? Пока мы собеседуем людей на должности разработчиков, проверять этот, хоть и полезный, но дополнительный навык на интервью излишне.
Разработчик должен если не сам написать код, то полностью его провалидировать. Бигтех никогда не позволит выпускать в прод сгенерированный код без проверки человеком, пока не будет 100%‑й уверенности в том, что агенты работают на уровне реальных программистов, а это пока недостижимо. Не думаю, что какая‑то компания будет недовольна сотрудником, который не использует ИИ‑агентов, но перформит на уровне коллег.
Ну и в любом случае научить хорошего разработчика использовать ИИ гораздо проще, чем научить мастера нейронок кодить. Возможно, в обозримом будущем ценность навыков будет переоценена. Для специфичных должностей, требующих навыков AI‑assisted‑разработки, ещё предстоит выработать методику оценки соискателей.
Проблемы, с которыми сталкиваются соискатели
№ 1. Не получается вовсе попасть на техническое собеседование
Раньше ваше резюме мог отсеить HR, слабо разбирающийся в технических вопросах, и, возможно, неверно оценивший ваш опыт. Сейчас из‑за большого количества откликов ваше резюме может и не попасть к HR. Чаще всего предварительную проверку выполняет нейросеть, критерии работы которой ещё менее прозрачны, чем работа HR. Отсюда достаточно большая вероятность не только не попасть на техническое собеседование, но и вообще не получить обратную связь.
Для молодых специалистов самый простой путь в данной ситуации — вложиться в оформление резюме специалистом (привет hh, зарабатывающему на предоставлении услуг обеим сторонам, ака оружейный барон, продающий вооружение обеим сторонам конфликта) — главное не перейти к искажению истины. Для уже более опытных наиболее верный вариант — использование реферальных ссылок: если кто‑то поручится, что у вас есть реальный опыт, это поможет пропустить проверку нейросети и подняться в очереди у HR.
Если же вас всё равно не зовут на технические собеседования, возможно, просто нет открытых вакансий (наличие открытых вакансий на сайте или каком‑то агрегаторе не гарантирует их реальное существование, иногда они используются HR для анализа рынка) и стоит попробовать поменять свою специализацию. Не обязательно кардинально — не стоит сразу идти сварщиком, если до этого вы 10 лет были крутым специалистом в другой нише, но можно рассмотреть смежные специализации, поменять стек, рассмотреть вакансии инженера по ИБ или DevOps.
№ 2. Интервьюер забывает, что соискатель также формирует мнение о работодателе
К сожалению, часто, особенно в современных условиях рынка труда «работодателя», техническое интервью напоминает экзамен на первом курсе, где «серьезные дяди» пытаются подловить соискателя на несущественной перестановке слов в определении.
При этом наиболее квалифицированные специалисты понимают: атмосфера в коллективе и взаимоотношения коллег — одни из основных факторов, которые нужно оценивать при трудоустройстве. Соискателям можно порекомендовать только не тратить время и силы на подобных работодателей и сразу уходить с таких собеседований. А интервьюерам важно оставаться адекватными людьми, с которыми приятно вести диалог несмотря на свое психологическое состояние (без обид, у всех бывают плохие дни). Ведь на интервью вы представляете всю вашу компанию.
№ 3. Миллион этапов собеседований
Опять же, в текущих условиях работодатель сделает всё, чтобы взять самого талантливого сотрудника за самую маленькую ЗП. Для этого иногда искусственно вводятся разные этапы собеседований (хорошо, что ещё никто не додумался давать задачи из ЕГЭ на собесах). Соискателям рекомендую выяснять у HR'ов всю процедуру собеседований сразу и трезво оценивать своё время — стоит ли оно этого рабочего места.
Если же изначальный план HR'а начинает резко меняться, это повод переключиться на другие вакансии. По моему мнению, для вполне корректной оценки соискателя достаточно трех этапов:
Скрининг HR — базовое тестирование, чтобы понять, что в компанию обращается не дорвавшийся до телефона пациент психбольницы.
Общее техническое интервью, на котором решаются некоторые типовые задачи, на основании которых оценивается опыт соискателя по работе с инструментами, используемыми в компании: примерный грейд, сильные и слабые стороны.
Собеседование в конкретную команду, на котором в первую очередь определяется, насколько комфортно общаться и выстраивать отношения, происходит знакомство с продуктом (помним, что соискатель тоже оценивает команду), а также уточняются некоторые технические навыки, специфичные для конкретной команды.
Для маленьких компаний 2 и 3 этапы можно объединить.
Как же провести хорошее техническое интервью?
Сложно дать простой ответ на этот вопрос. На основании опыта можно выстроить некоторый примерный план проведения технического собеседования, который затронет все необходимые аспекты. В этой статье я поделюсь планом, который использую в своей работе.
Здесь стоит сделать ремарку о том, что разработка этого плана не является заслугой автора — план был выстрадан десятками интервьюеров. Вклад же самого автора относительно невелик и заключается в разработке некоторых задач и тем для обсуждения.
Давайте вспомним основную цель технического интервью — понять, что соискатель подходит для решения определенного спектра задач команды.
Дать правильные ответы на технические вопросы, конечно, будет серьезной заявкой на успех, но на передний план выходят софт скиллы: как он будет контактировать с коллегами, будет ли врать (соврал в резюме = соврет и при выполнении работы), насколько чувствует ответственность за продукт и как будет организовывать свою работу чтобы укладываться в сроки? Умеет ли пользоваться современными инструментами, готов ли учиться, сможет ли привнести что‑то новое в команду?
Чтобы всё это проверить будет недостаточно решать типовые задачи на «event loop» и контекст. В своей работе мы придерживаемся примерно следующего плана.
№ 1. После знакомства и озвучивания плана встречи идет небольшой рассказ о специфике работы: какие инструменты используем и какие виды задач в целом решаем
Это нужно больше для того, чтобы расслабить кандидата. За это время проходит первый мандраж и можно приступать к «допросу».
№ 2. Общение по резюме кандидата
Базово проверяем, что не врет: просим рассказать о конкретных тасках, какие инструменты использовались и почему. NDA нарушать не призываем, но, наверняка, по какой‑то из своих работ можно рассказать пару интересных кейсов. Также по ответам можно уже сложить некоторое мнение: что человеку нравится, а что нет, в каких задачах силён, а где не очень.
№ 3. Решение 2–3 несложных задач
Желательно незаезженных вдоль и поперек, с которыми должен справиться любой разработчик в компании. В нашем стеке React, и мы стараемся давать задачи, хоть как‑то приближенные к реальным: обработка форм, реализация компонента с определенной логикой, реализация кастомной хуки (например, для автоматического скролла страницы на начало или реализации дебаунса).
Во время решения можно обсудить множество задействованных аспектов: когда происходят лишние ререндеры, как мемоизовать компоненты, как обработать событие на стадии погружения, какие ограничения на использование хуков в React, как реализовать лениво подгружаемый компонент и так далее. Иногда добавляем в заготовки наших задач несколько багов, чтобы посмотреть на реакцию соискателя и на то, как он будет локализовывать проблему.
Также хорошо во время собеседования найти область, в которой у соискателя нет 100%‑х знаний. Мы смотрим, как человек на это реагирует. Если начинает что‑то придумывать — это вызывает настороженность. Если честно признает, что не знает, но может сделать предположение на основе своего опыта — идеально. Мы продолжаем общаться на эту тему и вместе приходим к какому‑то решению.
Чтобы соискатель не впадал в панику после первого же вопроса, на который не смог ответить, можно немного подсказать и в разумных пределах даже дать правильный ответ (естественно, с пометкой для себя). Так можно перейти к следующей задаче без негативного осадка, да и соискатель, возможно, узнает для себя что‑то новое.
№ 4. Задача на рефакторинг
Даём код условного джуна с большим количеством косяков, которые нужно исправить. Чем больше проблем найдет соискатель, тем лучше. Но не стоит сводить эту задачу к проверке «нашёл все проблемы / не нашёл». Анализировать чужой код, тем более в стрессовой ситуации под надзором незнакомых людей — очень непросто. После того, как соискатель исправит всё, что сможет, стоит пройтись по всем оставшимся проблемам в коде наводящими вопросами — с высокой долей вероятности человек просто что‑то пропустил.
Стоит ли давать задачи на алгоритмы? Если это не FAANG, то нет — в повседневной работе решать такие задачи не придется, а проверять творческие навыки в ситуации повышенного напряжения — неблагодарное дело (хотя, наверное, имеет место для специфичных должностей).
А как хорошо пройти техническое интервью?
Помимо базового «надо знать» дам ещё несколько советов для соискателей, которые могли бы помочь многим из не прошедших наши собеседования:
Не страшно что‑то не знать — это нормальная ситуация. Иногда ответы «Не знаю, но при необходимости посмотрю в документации» или «Никогда так не писал и надеюсь, что вы не пишите — код становится совсем нечитаемым» могут подчеркнуть ваш профессионализм, а не поставить его под сомнение. А если нет, возможно, вы найдете место получше.
Старайтесь быть максимально честными и проявить лучшие человеческие качества.
Проявите заинтересованность — вряд ли кто‑то захочет взять на работу апатичного выгоревшего разработчика.
Помните, что все мы люди: мы субъективны, часто ошибаемся и не знаем наизусть все спецификации. Интервьюеры не исключение.
Заключение
Процедура найма, особенно в крупных компаниях — сложный процесс, зависящий от многих людей и подверженный случайным факторам, вызывающим различные ошибки. Все мы винтики в этом большом механизме, и всё, что мы можем сделать для того, чтобы он работал на комфортном для всех (от соискателя до директоров компании) уровне — это серьезно подходить к своей зоне ответственности.
Надеюсь, мои советы заставят кого‑то переосмыслить свой подход в проведении/прохождении интервью и каким‑то образом его улучшить.
Отдельно хочу выразить благодарность моему напарнику по проведению технических собеседований @Barakex, вместе с которым мы постоянно ищем как можно улучшить нашу работу, и всем интервьюерам в нашей команде, которые привносят свой вклад в наше общее дело.
Читайте также:
