Продолжение истории о том, как я проходил собеседования в разные компании на разные позиции. В этот раз закроем несколько вопросов и комментариев касательно первой части и продолжим говорить о тестовых заданиях и технических собеседованиях.
К моему удивлению, предыдущая статья о собеседованиях с рекрутерами и HR вызвала неожиданный интерес: более 100 000 просмотров по всем источникам. Я получил кучу положительного фидбека в личку, мне написали бывшие коллеги, которых я последний раз видел лет 5 назад; героини некоторых историй; парень, которому я несколько недель назад продавал системник через OLX (аналог Slando, — прим. пер.); барабанщик с которым мы в прошлом году играли метал в гараже, и, как это ни странно, довольно много рекрутеров, которые поинтересовались моими мыслями касательно тех или иных аспектов собеседований и найма. 250 человек зачем-то добавились ко мне в LinkedIn :).
Перед тем, как перейти к делу, отвечу на самые популярные вопросы и личных сообщений и комментариев.
Как договариваться о зарплате на собеседовании
Много комментариев касались денег. Я умышленно не уделял этому большого внимания, потому что торги — отдельная тема, однако комментаторы всё равно её затронули и указали на недостатки моей стратегии — например, сразу же называть цену. Вот две хорошие статьи, которые значительно детальнее и профессиональнее рассматривают этот вопрос:
- Как обсуждать деньги на собеседовании: стратегия переговоров для соискателя
- Salary Negotiation: Make More Money, Be More Valued
Рекомендую прочитать перед поисками работы.
Несколько мыслей касательно рекрутинга
Я ни в коем случае не даю советов рекрутерам о том, как им делать их работу. Я не профессиональный рекрутер, и не знаю как работает их внутренняя кухня. Когда мне нужно было искать себе персонал (не только проводить технические собеседования, а именно искать и нанимать — полный цикл), то это были junior-позиции, соответственно, у меня не возникало особых трудностей.
В личных сообщениях у меня спрашивали, каким нужно делать первое сообщение о предложении поработать, чтобы оно выглядело привлекательно и заинтересовало специалиста, как обратить на себя внимание?
Мне кажется, что от рекрутера, к сожалению, ничего не зависит. Все, что может сделать рекрутер — найти как можно больше контактов специалистов нужного профиля и проспамить разослать им всем свое предложение. После этого нужно ждать и надеяться, что кто-нибудь из них или уже колеблется или в активном поиске работы. То есть, тут 20% работы с базой и 80% удачи. В сети много материалов о том, как правильно составлять вакансии и так далее, однако как по мне — ключевой фактор — это именно желание кандидата сменить работу.
Рекрутинг — это продажа вакансии кандидату. Чем быстрее вы это поймете и начнете прокачивать свои навыки продажника — тем лучше. Ой, я же говорил что не буду давать советы :)
Так же я убежден, что во время поисков работы кандидатам нужно браться за все вакансии, которые более-менее подходят, потому что на самом деле выяснить, о чем вакансия, можно только во время разговора с техническими специалистами. В своих поисках я практически не обращал внимания на то, что написано в вакансии, и выяснял нужные детали на этапе технического собеседования. Считаю, что этот способ есть наиболее правильный, потому что так значительно увеличиваются шансы найти крутой проект, который может прятаться за стандартным серым описанием. Мой опыт только однозначно подтверждает этот тезис. Ни одного раза в вакансии не было написано конкретно, что нужно будет делать. Только общие фразы вроде «кодить код, тестить тесты, деплоить деплоймент».
Наниматься в компанию или на проект
В наших реалиях — однозначно на проект.
Как выбирать себе тайтл
Я позиционировал себя как кандидат уровня Senior Software Engineer и выше — Team/Tech Lead, Principal Engineer, Software Architect, Project Manager, People/Group Manager и так далее. Именно это «выше» и имел ввиду под "+" в «Senior+».
Мне кажется, что тайтл ничего не значит. Важно лишь то, чем ты будешь заниматься на самом деле, а это можно выяснить только у того человека, с которым будешь работать.
Итак, дамы и господа, перейдем к техническим собеседованиям.
Этап второй. Технические собеседования
В этой части будет больше моего субъективного опыта и философии, нежели советов. Информации о том, что спрашивают на технических собеседованиях, и как к ним готовиться, в интернете полно.
disclaimer: автор не является турбоинженером-олимпиадником, поэтому некоторые решения или комментарии могут вызвать у соответствующих специалистов улыбку, баттхёрт, желание указать автору на его ошибки или низкую квалификацию. С удовольствием выслушаю конструктив.
Всего я прошел 15 технических собеседований, что, как по мне, не так уж и много. Я мог бы пройти значительно больше, но в среднем ожидал неделю от первого контакта с рекрутером до разговора с техническим специалистом. Это при том, что у меня практически не было ограничений по времени. Всего один раз мне назначили собеседование на время, на которое у меня уже было запланировано другое собеседование. Также замечу, что все компании или рекрутеры выходили на меня сами. Я не посылал CV ни в одну компанию первым. Это к вопросу что не сеньер ищет работу, а работа — сеньера.
Тестовые задания
Много компаний дают тестовые задания перед тем, как перейти к разговору, чтобы отсеять нерелевантных кандидатов. Несмотря на то, что многим не нравится вкладывать свое время в тестовые задания, особенно если они довольно объемные, я все-таки считаю, что это хорошая практика. Рассмотрим, какими могут быть тестовые задания.
«Сделайте проект с нуля (возможно, используя конкретную технологию) и выложите его на GitHub» — как по мне, наихудший вариант. Вы можете много времени потратить на бойлерплейт, на инфраструктуру вокруг решения, а интервьюера, как правило, будут интересовать несколько мелких деталей реализации, заложенных в условиях задачи. Хорошо, если у вас есть под рукой, например, шаблоны проектов и вы можете за 5 минут поднять сервер и быстро закодить что нужно. Иначе, придется все вспоминать и начинать с нуля. Также, плохо, если в задании есть условие использовать внешние зависимости, например, не-embedded базу данных.
Позиция DevOps Engineer. Мне прислали задание сделать Vagrant конфигурацию из нескольких виртуальных машин, среди которых должны были быть веб-сервера со статикой, балансер для них и Jenkins. Все это нужно было устанавливать и конфигурировать с помощью Chef. А теперь представьте — я никогда не использовал Vagrant, Chef и не настраивал те веб-сервера, которые требовались в задании. Я примерно понимаю как оно все работает, имел дело с похожими инструментами, но никогда не использовал конкретно эти.
Мне пришлось за ночь сесть, установить все это, собрать кучу граблей и в итоге все-таки выполнить задание. Основная сложность состояла в том, что у меня старый MacBook Pro 15-го года, который просто физически не успевал рестартовать контейнеры а так же в том, что я не имел опыта работы с Vagrant.
На суть задачи — разобраться как что устанавливать, — у меня ушло наверное с полчаса. Остальное время (7 с хвостиком часов) я потратил на установку всего инструментария, рестарты—ребуты, тыкание по конфигам в попытках понять, почему оно не работает и так далее.
То же самое задание на Docker Compose я бы сделал, наверное, за час, может даже меньше. Можно ли было не ограничивать кандидата инструментами? Мне кажется, что можно.Было ли это задание полезно для меня? Однозначно да! Теперь я буду знать что от Vagrant и Chef нужно держаться подальше :)
Потрачено времени — 8 часов.
К сожалению, больше историй про этот тип задач у меня нет, потому что тестовых в целом давали не так уж и много :(
«Вот ссылка на сайт с тестами — пройдите их» — очень классный вариант. В чем суть? Есть SaaS, которые позволяют конфигурировать набор практических и теоретических вопросов, и для решения предоставляют REPL и редактор кода прямо в браузере, а так же дают возможность запустить верификационные тесты. Дальше вы просто идете по заданиям, исправляете существующий или пишете свой код, запускаете его и смотрите результаты. Сами тесты от вас спрятаны, вы видите только результат (passed/failed) и короткое описание теста, которое одновременно может быть подсказкой. Почему этот вариант нравится мне больше всего? Потому что есть однозначный критерий качества выполнения задания, и кандидат точно знает, сколько балов он набрал, работает ли его решения и так далее. Мне лично даже интересно было проходить эти задания. Единственное, я не вижу смысла в теоретических вопросах вроде «что будет, если выполнить этот код» — они легко гуглятся.
Позиция Ruby Software Engineer. Мне присылают ссылку на сайт TestDome, естественно, на кастомный тест. Я кликаю, попадаю в собственно тесты. Мне дают 2.5 часа на прохождение всего набора, по 5-20 минут на каждый вопрос. На самом деле, мне очень понравилось, я давно уже не проходил такие штуки. Особенно пришелся по душе TDD-подход: закодил, запустил, посмотрел что упало, кодишь дальше. Прошел с большим удовольствием.
Сами задачи были довольно простыми: исправить код (Ruby/JS/CSS/HTML), написать валидаторы (Ruby), реализовать структуры данных (Ruby), ничего особенного. Однако тот факт, что сразу же можно проверить, работает ли решение, очень помогает.
Я справился с заданием на 93/100 балов всего за час. К сожалению, этот результат совсем мне не помог в дальнейшем.
TDD помогает в решении, не нужно тратить время на подъем инфраструктуры, репл прямо в браузере — короче говоря, очень круто. Ради такого можно было и месяц подождать — в итоге я получил свою порцию допамина (отлично справился с заданием) и адреналина (часики тикают, времени все меньше!).
Потрачено времени — 1 час.
Также, большим преимуществом этого типа заданий является то, что их проверка автоматизирована. Все мы знаем как интервьюеры «любят» проверять задания, а тут за них все делает машина — очень удобно, как минимум что ничего не нужно выкачивать код и собирать его. Возможно, буду использовать этот метод при найме в будущем.
«Вот репозиторий, там задание, присылайте Pull Request с решением» — такой вариант мне не попадался, но его использовали мои коллеги. Мне он не очень нравится, потому что можно посмотреть, как выполняли задание другие кандидаты (если они были).
Недостатки такого способа очевидны: проверяющему нужно выкачивать код, собирать, смотреть что там, это долго и скучно. Конечно, можно поверхностно посмотреть код в браузере, однако зачем тогда нужно было задание? Давайте тогда на псевдокоде писать.
«Вот репозиторий, там код, отрефакторите его насколько можете» — вариация предыдущего. Это уже лучше, потому что тут с самого начала создаются рамки, в которых можно работать. Недостатки те же: непонятно, когда нужно остановиться. Как говорил Егор Бугаенко, любая программа содержит бесконечное количество ошибок, и исправлять их тоже можно бесконечно.
Авторы задания наверняка имели что-то в голове, когда создавали его, одного мы скорее всего так и не узнаем, что именно для них было главным. Если бы задание имело четкий критерий, тогда это было бы круто. Например, «есть код, он на таком вот железе выдает вот такое результат по быстродействию, отрефакторите, чтобы работало в два раза быстрее». Без критериев работать сложно. В реальной жизни, в реальной работе, мы всегда имеем рамки и ищем оптимальное решение, руководствуясь этими рамками и здравым смыслом. Основная работа разработчика — как раз прочувствовать этот баланс и подобрать соответствующее решение.
К моему огромному сожалению, никто больше не давал тестовых заданий, поэтому выборка у меня совсем маленькая. Разве что могу вспомнить те тестовые, которые я делал много лет тому назад. Все они были первого типа — нужно было сделать проект. Интересно, что я их выполнял в те времена, когда GitHub еще не был таким популярным и нужно было пересылать решение в zip-архиве почтой :)
Мои рекомендации по тестовым заданиям?
- Не нравится — не делайте. Если задание, например, заверстать целый сайт или написать круд — ну его в баню. Задания должны быть короткими и сфокусированными на создании контекста для последующей дискуссии, а не просто тестом на то, как вы умеете делать скаффолдинг.
- Если задание первого типа — добавьте в репозиторий readme, где в деталях опишите инструкцию для запуска, короткую аннотацию о том, почему вы сделали такое решение, какие в нем есть недостатки, что вам понравилось или не понравилось, как бы вы решили задание, если бы у вас было больше времени, и так далее. Не знаю, помогает ли это реально, но, как интервьюер, я бы однозначно отметил такое документирование решения.
- Пишите нормально, но не стоит тратить кучу времени на вылизывание деталей. Как по мне, достаточно просто перечислить в readme все, что вы бы улучшили, если бы это был боевой код.
- Обязательно подумайте, какие вопросы к вам могут возникнуть по реализации и почитайте дополнительно документацию о том API, которое вы использовали. Допустим, я давно не работал с concurrency. Я уже давно не практиковался в этом, поэтому после решения я быстро прошелся по всем связанным темам, вспомнил все типовые задания и был готов к разговору.
Что ж, тестовое, вы, надеюсь, успешно выполнили, передали эту информацию рекрутеру, и через неопределенное время вас пригласят поговорить лично.
Техническое собеседование. Интро
Начнем с того, что сейчас уже достаточно редко приглашают в офис на собеседования. В офис меня позвали только несколько раз — для интервью на позиции Solution Architect, Tech Lead и один раз — на менеджерскую должность. Все остальные собеседования проходили по Skype, Zoom, Hangouts. Как и на предыдущем собеседовании с рекрутером, рекомендации те же — хорошая камера, хорошая гарнитура, хороший интернет. К этому так же добавлю условие шарить экран. Поэтому убедитесь, что у вас нет открытых рабочих проектов (если это важно) и других персональных вещей, которые не нужно показывать людям на том конце. Держите под рукой чистый браузер без табов и REPL для кодинга на всякий случай (IDE или repl.it).
Из всех способов связи мне больше всего нравится Zoom. Собственно, его и использовали чаще всего.
Важный совет касательно правильного общения в телеконференциях: заведите привычку не говорить и не печатать на клавиатуре, когда говорит другой человек, и разговаривать по гарнитуре, а не, например, через внешний микрофон ноутбука и внешние колонки.
Почему это важно? Чаще всего с вами будут разговаривать двое людей, соответственно, они не будут использовать гарнитуру. Когда вы говорите, то на их стороне софт включает шумодав, который не дает появиться эффекту обратной связи (фон, свист, эхо). Когда включается шумодав, то их микрофон практически ничего не будет ловить, поэтому вы не будете слышать, что вам говорят.
Когда вы печатаете на клавиатуре, то это создает шум, который передается на другую сторону и тоже включает шумодав. В результате этого фразы обрываются, и создается впечатление плохой связи. Поэтому, всегда нужно ждать, пока люди не закончат разговор. Иначе вы просто не услышите, что они хотели сказать (кроме случаев, когда собеседники тоже используют гарнтируру). Как это ни странно, много людей не знают про эти механизмы. Также полезно отключать (мьютить) микрофон на то время, пока вы не разговариваете, чтобы к людям не прорывались звуки из вашей комнаты. Я воспитан годами работы в энтерпрайзе, где эти правила знает каждый, поэтому для меня все это очевидно, но я видел немало ситуаций когда люди не соблюдали этих элементарных правил и грешили на плохой интернет.
Если все ок, прошли пинги туда-сюда, то начнется разговор. Часто интервьюеры сами предлагают план разговора. Бывает, что у них нет плана, однако как минимум одна тема будет актуальной всегда: «Расскажите о себе и о своём опыте».
Перед собеседованием еще раз пройдитесь по вакансии, обратите внимание на требования, которые предъявляются к кандидату и подготовьте спич. Я проходил собеседования на Tech Lead, DevOps/SRE, Ruby/Java Software Engineer и в каждом случае рассказывал разные вещи, которые, как мне кажется, заинтересовали бы интервьюера больше. Старайтесь не углубляться в детали, а предоставлять ту информацию, которая создаст вектор для дальнейшей дискуссии. Не стоит детально говорить о том, что вы делали 5 лет назад (если конечно это не было чем-то экстраординарным).
Я говорил, например, такое: «8 лет работал в энтерпрайз-конторе, в основном с Java. Дальше пошел в стартап, там занимался инфраструктурой. Последние два года пишу в основном на Rails». Все, у интервьюеров есть достаточно информации, и они будут раскручивать разговор в том ключе, который их интересует.
А вот теперь неожиданный факт.
Ваше резюме никто не читает.
Честно говоря, это оказалось для меня большим открытием. Ну хорошо, рекрутеры не читают профиль в LinkedIn, потому что он может быть не обновлен, HR обладает навыком просматривать CV по диагонали, и выделять для себя основное. А вот люди, которые проводят техническое собеседование, уж точно не будут читать ваше резюме. Ни одного, подчеркну, ни одного раза я не почувствовал, чтобы люди хотя бы одним глазом глянули на то, что я там понаписывал. Я подозреваю, что, как правило, они узнавали о том, что нужно проводить техническое собеседование за день до собственно самого собеседования, и решали почитать CV за 5 минут до звонка, а там уже как-то будет.
Поймите меня правильно: я не нарцисс или балерина «кружите меня, кружите». Я знаю, что у меня есть много слабых сторон (как со стороны технаря, так и со стороны менеджера). Я не ожидаю, что интервьюеры будут на меня смотреть, как обезьяны на Обелиск.
Я не требую, чтобы мне пели дифирамбы и высказывали уважение с первых минут разговора.
Я всего лишь ожидаю от людей профессиональной подготовки, тем более, что она занимает всего 10 минут. Перечитать CV, возможно посмотреть ссылки, которые там есть, подготовить примерный список вопросов и сократить общее время разговора.Лично я всегда читал CV перед собеседованием и продумывал, что меня будет интересовать в разговоре с кандидатом. К сожалению, нормальное резюме у нас почти никто не умеет готовить, так что задача непростая.
И снова выскажу свое неудовольствие таким отношением. Я и вы, если вы уже сеньер-помидор, являетесь специалистами относительно серьезного уровня в своей сфере (напомню, у меня это формошлёпство и круды). Таких как мы, не очень много на рынке, поэтому, пожалуйста, проявите уважение, ознакомьтесь с тем, что я делал. Я же прочитал про вашу компанию, проект, клиента. Я ожидаю, что ко мне будут относиться, как к человеку. Почему происходит обратное?
Вы никому не нужны
А вот это меня уязвляет больше всего. В 80% случаев я имел дело с сердитыми, заспанными, уставшими интровертами, которые явно не были заинтересованы в том, что бы кого-нибудь нанимать. Это были технически грамотные люди и хорошие специалисты, но почему-то у них совсем не было желания собственно нанять себе коллегу, не было желания взять себе в команду хорошего инженера который им поможет.
Я убежден, что это были люди, на которых просто повесили обязанность проводить собеседования. Несколько раз мне говорили, что нужный человек был в отпуске, или не успел приехать, или занят, или еще что-нибудь. У них и так куча своих дел, проблемы на проде, не успеваем спринт, митинги с клиентом, а тут опять очередной кандидат приперся, что с ним делать, а? Из этого следует проблема: интервьюеры не рассматривают вас как человека, с которым им нужно будет работать, а просто пытаются оценить, нормальный вы или нет с их точки зрения. Достаточно частой была ситуация, когда «ой тимлид сейчас занят, поэтому собеседование будет проводить другой человек».
У меня было всего несколько разговоров с инженерами, по которым было видно что да, им реально нужны люди, они хотят нанять хорошего специалиста, у них есть план на меня и так далее. А поэтому переходим к следующему пункту.
Вы не будете разговаривать со своим будущим боссом или тимлидом
Это следствие из предыдущего. Я глубоко убеждён, что вы должны говорить с тем, кому вы потом будете подчиняться, формально или неформально. Во всех организациях есть какая-нибудь иерархия, будь это Scrum-команда или кровавый энтерпрайз. Везде есть человек, который будет присматривать за вами (как минимум на старте).
К сожалению, вы ничего не сможете с этим сделать. Егор Бугаенко в своем посте «Why I Don’t Talk to Google Recruiters» очень хорошо описал эту ситуацию. Если вы будете требовать разговора со своим будущим боссом — вы просто не попадете ни на какое собеседование.
Мне кажется, что сейчас это одна из самых больших проблем найма у нас. Возможно, это продиктовано спецификой проектов — аутсорс, где люди что-то делают на потоке. Возможно, в целом плохой культурой общения и мизантропичной ментальностью, я не знаю.
В англоязычных блогах часто пишут, что найм является одним из ключевых направлений, жизненно необходимых для построения успешной компании. Я думаю что нашим компаниям понадобится еще много времени, чтобы прийти к этому и сформировать правильную культуру. А пока что приходится аутсорсить это заказчикам.
Немного из прошлого опыта. Когда я нанимался на текущую работу, то разговаривал непосредственно с CTO и CEO. Я должен был бы быть первым инженером в стартапе, поэтому и отношение ко мне было очень скрупулезным и серьезным. В результате мы отлично сработались, да и собеседование было одним из лучших, которые я проходил. Мы обсуждали не только технические детали, но и первые шаги и планы на несколько месяцев вперед.
Даже если собеседование проводить будет не ваш непосредственный руководитель, обязательно требуйтедолива пива после отстояобщения с ним перед тем, как принимать предложение (конечно, если удастся пройти все этапы).
Пока что все, материалов и мыслей много, опять вышел лонгрид, как бы я не старался. В следующей части продолжим рассматривать тему и перейдем к конкретным вопросам и методикам, которые применяют на технических собеседованиях.
Автор: r0zh0k
