Немного о собеседованиях и совсем чуть-чуть о тестовых заданиях
Так уж сложилось, что в последнее время, я и моё ближайшее окружение активно проходим собеседования как в компании представляющие страны пост-СНГ , так и в ближнее зарубежье, что, вкупе с моим предыдущим опытом «по ту сторону» собеседования, и побудило меня к написанию данной заметки.
Здесь и далее пойдёт речь либо о моём личном опыте, либо о моих коллегах и друзьях, работающих в сфере IT. Общий знаменатель — бэкенд / фуллстек разработчик с 6–8 годами опыта. Возможно, для супер-сеньоров / техлидов / архитекторов ситуация отличается, но, пока что, это мой список боли. Текст носит сугубо субъективный характер, и не претендует ни на что, кроме как выражения личных негодований, наблюдений и пожеланий к процессу интервью и части тестового задания в частности.
Структура интервью
В условиях пандемии, более-менее стандартное интервью — это полностью онлайн общение + 4 основных структурных кита:
Общение с рекрутёром или кем-то, где фигурируют слова Human или Resource. Здесь всё стандартно. Определение ваших ожиданий и проверка «матчинга» на «подходит ли в компанию», знание иностранных языков и, иногда, «проверка на дурака» — действительно ли ВЫ составляли резюме и попытка определить — понимаете ли, что там написано, хотя бы в общих чертах.
1 или 2 технических интервью различной продолжительности и степени сложности с разным количеством людей. И вот тут уже начинаются вещи, степень странности которых варьируется от «лёгкое недоумение» до «надо прощаться и уходить / отключаться» (об этом поговорим отдельно в пункте).
Тестовое задание или / и Live Coding сессия. Здесь разнообразные продолжительность и формат. Вот эта часть, на которой я бы особенно хотел остановиться, потому что здесь можно встретить вообще всё. И, очень часто, случается, что происходят просто несуразные вещи.
1 или 2 интервью с менеджером проекта / подразделения / продукта еще чего-то. Эту часть я называю «колодец желаний». О чём бы вы не подумали (максимально позитивное или негативное) — возможно всё и даже больше чем всё. На этой части я тоже остановлюсь, но без подробностей, ибо, как мне кажется — это неисчерпаемая тема.
Итак, казалось бы, по структуре всё стандартно, но нет. Даже сама схема интервью часто вызывает вопросы. Далее, я вкратце опишу пограничные ситуации, возникающие в процессе интервью, которые вызывают, мягко говоря, недоумение.
Всё и сразу. Довольно часто возникают моменты, когда в процессе интервью компания делает «всё по максимуму», вдобавок, подкрепляется тем, что многие (если не каждый) из этапов переходит все мыслимые и немыслимые временные границы. Случались ситуации, когда общение (пункты 1, 2, 4), в сумме, занимало около 10 часов. Возможно, для «синьор полиглот архитекторов» это и нормально, но, наверное, теоретическая часть, в моей голове так думается, не может занимать столько времени, особенно, если ты в активном поиске, это не единственный потенциальный работодатель, с которым ты «в процессе», и обе стороны об этом уведомлены.
Последовательность собеседования. Здесь тоже случаются неприятности. Моё личное убеждение заключается в том, что продолжительность выполнения тестового задания должна находиться в интервале 2–6 часов. 6–8 лет опыта никак не удастся уместить ни в 2 часа, ни в 3 рабочих дня выполнения вашей задачи. Для этого у работодателя есть испытательный срок, где за 3 месяца, всё более-менее должно стать понятно. Поэтому, тестовое задание — это тоже, по сути, «проверка на дурака». Но всё-таки случается, что соглашаешься на тестовое задание, которое занимает 2 полных выходных дня «с хвостиком», а после 15 минут технического собеседования понимаешь, что, наверное, если бы я не потратил столько усилий на тестовое задание, то попросил бы заканчивать общение.
Здесь, я нашёл для себя оптимальную формулу. Выслать кандидату до общения небольшое техническое задание (2–4 часа активного кодинга). На технической части обсудить вопросы по коду и предложить запилить минимальное улучшение / изменение в во время интервью. Далее общаться по теоретическим вопросам с возможными отсылками к вашему коду. Находясь по обе стороны интервью, я пришёл к выводу, что данная схема хорошо работает как для интервьюера, так и для собеседуемого. Первый получает возможность выяснить уровень знаний и «вширь» и «вглубь» (насколько это возможно), а второй находится в достаточно комфортных условиях, потому что есть контекст задачи.
Предупреждайте. Это обращение, в первую очередь, к рекрутерам. Предупреждайте, пожалуйста, кандидата о том, по какой схеме будет проходить интервью, и сколько времени каждый этап будет занимать (хотя бы предварительно), особенно, в тех случаях, когда кандидат говорит, что находится в активном поиске. Выбивают из колеи ситуации, когда ультимативно назначают финальный созвон на 9.00 вечера твоей часовой зоны, ты закрываешься в закутке чтобы не мешать домашним, а потом, оказывается, что интервью продлится два с половиной часа, тебе будут задавать вопросы, дублирующие предыдущие части и попросят написать код в блокноте и скомпилировать его по памяти.
Теперь о пунктах интервью отдельно.
Техническое интервью
Здесь, наверное, помогает большое количество статей о том, как «надо» и как «не надо», и почти не сталкиваешься с вопросами про шары для гольфа в багажнике. При этом всё равно возникают ситуации, вызывающие смятение:
Количество собеседюущих. На одном из технических собеседований у меня было 6 технических интервьюеров. Мне остаётся лишь догадываться зачем так много, но каждый из них задавал вопросы.
Мне кажется, со стороны это выглядело именно так.
Контекст. Этот пункт частично связан с предыдущим, хотя, иногда, для этого достаточно и 1 человека. Очень часто сталкиваешься с ситуацией, когда вопросы идут совсем вразнойбой. Например: что-то про оптимизацию БД, буква D в аббревиатуре SOLID, сложность поиска в связном списке. Обычно так происходит, когда интервью проводят несколько человек, которые отвечают исключительно за свою область.
Вопросы Да / Нет. Если вы задаёте бинарный вопрос и ожидаете неких объяснений — предупредите об этом собеседуемого. Несколько раз получал отзыв от рекрутёра, о том, что ожидали от меня большей проаквтивности именно в вопросах такого формата. По возможности старайтесь избегать таких вопросов.
«Мы ищем специалиста под наши нужды» или «Не читали резюме». Очень часто, во время интервью, получаешь пачку вопросов по тонкостям работы библиотеки, фреймворка, СУБД и т.д. На мой вопрос, — «А почему вы спрашиваете про это, если у меня в резюме ни строчки нету об этой технологии?» — «Да потому что у нас такое используется.» — «Может лучше просите про похожее, я с этим много работал?» — «Нет, нам надо это.»
Тестовое задание
Вот здесь сталкиваешься с потрясающим разнообразием всего. Я прекрасно понимаю, что придумать хорошее тестовое задание достаточно сложная задача, а если вы ещё и большая компания, то это превращается в постоянную рутину, потому что есть вероятность, что задание ваше утечет и придется придумывать что-то новое. Классические ситуации наподобие: -«Вот недельное тестовое задание, сделайте фичу» — я опускаю. Далее некоторые интересные случаи:
Мы (не) подразумевали. Бесчисленное множество раз я сталкивался с ситуацией.
— «Мы подразумевали, что вы сами поймёте, что надо покрыть всё тестами, прикрутить DI и использовать ORM. Очень часто видишь обратное.»
или
»- В описании написано ровно то что надо сделать, сделаете больше — вы молодец, но обсуждать мы будем только то, что написано в требованиях.»
Если вы всё-таки подразумеваете — дайте намёк.Ленивый интервьюер. Немного переплетается с предыдущим. Постарайтесь описать, что вы ожидаете увидеть в тестовом задании. Если задача реализовать фичу — напишите, что на собеседуемого ложится задача продумать функционал этой фичи с пограничными ситуациями и т.д. Если вы ждёте, что человек, следуя TDD, реализует класс или метод и не более — дайте намек, что вот, достаточно, чтобы все тесты были зелёными.
Сегодня на завтра. Особенно нравятся ситуации, когда рекрутёры пишут что-то наподобие.
— «У вас завтра интервью в нашей компании, вот тестовое задание, сделайте до завтра, чтобы было о чём поговорить.»
Я же наверное назначил интервью на завтра, потому что сегодня занят? Нет?
Если вы переживаете что кандидат будет делать задание дольше, чем вам бы хотелось, оговорите этот момент. Что вот, за день до интервью будет выслано тестовое задание, давайте спланируем с учётом этого фактора.Напишите алгоритм [X], где [X] — это некая академическая задача. Это для меня вообще загадка. Что мне делать? С одной стороны «всё уже украдено до нас» — и тогда я могу просто найти существующее решение, но это не моя работа, и что вы собираетесь узнать обо мне? Но если я напишу всё сам — то в какой момент мне остановиться, и использовать ли самописную очередь, либо подтянуть реализацию структуры данных из стандартной библиотеки и т.д.?
Ваш код не компилируется. Это моё любимое. Касается лайв кодинга. — «Вот вам задача, запрограммируйте её в блокноте, за 30 минут, а мы пока что, посидим, посмотрим». По результатам 30 минут вам предлагают скомпилировать ваш код (горит одна из точек опоры). И разочарованно констатировать что не работает, а после — «Вы использовали слишком новую версию языка, наша тестовая среда поддерживает только предыдущую».
Расскажите о том, что вы уже рассказывали предыдущему собеседующему. Всё просто — была теоретическая часть, вы пообщались с человеком, выполнили тестовое задание, общение по результатам которого, свелось к вопросам, которыми вам мучали 3 часа позавчера в 10 вечера по местному. К сожалению, такое тоже не редкость.
Поговорим с менеджером
Здесь я не буду много рассказывать о всяких интересностях. Из глобального, я наблюдаю 2 проблемы этого этапа.
Здесь я задаю вопросы. С этим я связываю ситуацию, когда собеседующий не может ответить на ваши вопросы. До этого он много спрашивал про ваши достижения, работу в команде, скрам, код ревью и прочее. Но когда вы уточняете, что-либо, или идёте по своему списку вопросов, то ответа вы и не получаете, потому что и код-ревью у нас нет в «классическом понимании», и задачи у нас стоят другие, и пул проектов у нас есть, но мы пока не знаем что вам предложить.
Имитация важности. Это когда менеджер проверяет как ты «умеешь думать» и «подходишь ли ты в команду». В этом случае стоит обратить внимание на такие вопросы как «Как ты объяснишь ребенку что такое СУБД» или «У нас не успевает зарелизиться соседняя команда, что конкретно ты, как разработчик, готов сделать чтобы успеть». Такой случай, лично для меня, является важным индикатором в дальнейшем принятии решений. Того гляди, с такими вопросами каждый день приставать будут.
Получилось не немного, но как есть. Повторюсь ещё раз: это мои личные впечатления, которыми я решил поделиться. Всё что написано выше не призывает никого оскорбить и унизить, это моё личное мнение и никого ни к чему не призывает.
