Главная » Хабрахабр » [Перевод] Senior Engineer в поисках работы. Как я прошел 15 технических собеседований и что я об этом думаю

[Перевод] Senior Engineer в поисках работы. Как я прошел 15 технических собеседований и что я об этом думаю

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

Я получил кучу положительного фидбека в личку, мне написали бывшие коллеги, которых я последний раз видел лет 5 назад; героини некоторых историй; парень, которому я несколько недель назад продавал системник через OLX (аналог Slando, — прим. К моему удивлению, предыдущая статья о собеседованиях с рекрутерами и HR вызвала неожиданный интерес: более 100 000 просмотров по всем источникам. 250 человек зачем-то добавились ко мне в LinkedIn :). пер.); барабанщик с которым мы в прошлом году играли метал в гараже, и, как это ни странно, довольно много рекрутеров, которые поинтересовались моими мыслями касательно тех или иных аспектов собеседований и найма.

Перед тем, как перейти к делу, отвечу на самые популярные вопросы и личных сообщений и комментариев.

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

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

Несколько мыслей касательно рекрутинга

Я ни в коем случае не даю советов рекрутерам о том, как им делать их работу. Я не профессиональный рекрутер, и не знаю как работает их внутренняя кухня. Когда мне нужно было искать себе персонал (не только проводить технические собеседования, а именно искать и нанимать — полный цикл), то это были 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 базу данных.

Мне прислали задание сделать Vagrant конфигурацию из нескольких виртуальных машин, среди которых должны были быть веб-сервера со статикой, балансер для них и Jenkins. Позиция DevOps Engineer. А теперь представьте — я никогда не использовал Vagrant, Chef и не настраивал те веб-сервера, которые требовались в задании. Все это нужно было устанавливать и конфигурировать с помощью Chef. Я примерно понимаю как оно все работает, имел дело с похожими инструментами, но никогда не использовал конкретно эти.

Основная сложность состояла в том, что у меня старый MacBook Pro 15-го года, который просто физически не успевал рестартовать контейнеры а так же в том, что я не имел опыта работы с Vagrant. Мне пришлось за ночь сесть, установить все это, собрать кучу граблей и в итоге все-таки выполнить задание.

Остальное время (7 с хвостиком часов) я потратил на установку всего инструментария, рестарты—ребуты, тыкание по конфигам в попытках понять, почему оно не работает и так далее.
То же самое задание на Docker Compose я бы сделал, наверное, за час, может даже меньше. На суть задачи — разобраться как что устанавливать, — у меня ушло наверное с полчаса. Мне кажется, что можно. Можно ли было не ограничивать кандидата инструментами?

Однозначно да! Было ли это задание полезно для меня? Теперь я буду знать что от Vagrant и Chef нужно держаться подальше 🙂

Потрачено времени — 8 часов.

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

В чем суть? «Вот ссылка на сайт с тестами — пройдите их» — очень классный вариант. Дальше вы просто идете по заданиям, исправляете существующий или пишете свой код, запускаете его и смотрите результаты. Есть SaaS, которые позволяют конфигурировать набор практических и теоретических вопросов, и для решения предоставляют REPL и редактор кода прямо в браузере, а так же дают возможность запустить верификационные тесты. Почему этот вариант нравится мне больше всего? Сами тесты от вас спрятаны, вы видите только результат (passed/failed) и короткое описание теста, которое одновременно может быть подсказкой. Мне лично даже интересно было проходить эти задания. Потому что есть однозначный критерий качества выполнения задания, и кандидат точно знает, сколько балов он набрал, работает ли его решения и так далее. Единственное, я не вижу смысла в теоретических вопросах вроде «что будет, если выполнить этот код» — они легко гуглятся.

Мне присылают ссылку на сайт TestDome, естественно, на кастомный тест. Позиция Ruby Software Engineer. Мне дают 2. Я кликаю, попадаю в собственно тесты. На самом деле, мне очень понравилось, я давно уже не проходил такие штуки. 5 часа на прохождение всего набора, по 5-20 минут на каждый вопрос. Прошел с большим удовольствием. Особенно пришелся по душе TDD-подход: закодил, запустил, посмотрел что упало, кодишь дальше.

Однако тот факт, что сразу же можно проверить, работает ли решение, очень помогает. Сами задачи были довольно простыми: исправить код (Ruby/JS/CSS/HTML), написать валидаторы (Ruby), реализовать структуры данных (Ruby), ничего особенного.

К сожалению, этот результат совсем мне не помог в дальнейшем. Я справился с заданием на 93/100 балов всего за час.

Ради такого можно было и месяц подождать — в итоге я получил свою порцию допамина (отлично справился с заданием) и адреналина (часики тикают, времени все меньше!). TDD помогает в решении, не нужно тратить время на подъем инфраструктуры, репл прямо в браузере — короче говоря, очень круто.

Потрачено времени — 1 час.

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

Мне он не очень нравится, потому что можно посмотреть, как выполняли задание другие кандидаты (если они были). «Вот репозиторий, там задание, присылайте Pull Request с решением» — такой вариант мне не попадался, но его использовали мои коллеги.

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

Это уже лучше, потому что тут с самого начала создаются рамки, в которых можно работать. «Вот репозиторий, там код, отрефакторите его насколько можете» — вариация предыдущего. Как говорил Егор Бугаенко, любая программа содержит бесконечное количество ошибок, и исправлять их тоже можно бесконечно.
Авторы задания наверняка имели что-то в голове, когда создавали его, одного мы скорее всего так и не узнаем, что именно для них было главным. Недостатки те же: непонятно, когда нужно остановиться. Например, «есть код, он на таком вот железе выдает вот такое результат по быстродействию, отрефакторите, чтобы работало в два раза быстрее». Если бы задание имело четкий критерий, тогда это было бы круто. В реальной жизни, в реальной работе, мы всегда имеем рамки и ищем оптимальное решение, руководствуясь этими рамками и здравым смыслом. Без критериев работать сложно. Основная работа разработчика — как раз прочувствовать этот баланс и подобрать соответствующее решение.

Разве что могу вспомнить те тестовые, которые я делал много лет тому назад. К моему огромному сожалению, никто больше не давал тестовых заданий, поэтому выборка у меня совсем маленькая. Интересно, что я их выполнял в те времена, когда GitHub еще не был таким популярным и нужно было пересылать решение в zip-архиве почтой 🙂 Все они были первого типа — нужно было сделать проект.

Мои рекомендации по тестовым заданиям?

  1. Не нравится — не делайте. Если задание, например, заверстать целый сайт или написать круд — ну его в баню. Задания должны быть короткими и сфокусированными на создании контекста для последующей дискуссии, а не просто тестом на то, как вы умеете делать скаффолдинг.
  2. Если задание первого типа — добавьте в репозиторий readme, где в деталях опишите инструкцию для запуска, короткую аннотацию о том, почему вы сделали такое решение, какие в нем есть недостатки, что вам понравилось или не понравилось, как бы вы решили задание, если бы у вас было больше времени, и так далее. Не знаю, помогает ли это реально, но, как интервьюер, я бы однозначно отметил такое документирование решения.
  3. Пишите нормально, но не стоит тратить кучу времени на вылизывание деталей. Как по мне, достаточно просто перечислить в readme все, что вы бы улучшили, если бы это был боевой код.
  4. Обязательно подумайте, какие вопросы к вам могут возникнуть по реализации и почитайте дополнительно документацию о том 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 минут до звонка, а там уже как-то будет.

Я знаю, что у меня есть много слабых сторон (как со стороны технаря, так и со стороны менеджера). Поймите меня правильно: я не нарцисс или балерина «кружите меня, кружите». Перечитать CV, возможно посмотреть ссылки, которые там есть, подготовить примерный список вопросов и сократить общее время разговора. Я не ожидаю, что интервьюеры будут на меня смотреть, как обезьяны на Обелиск.
Я не требую, чтобы мне пели дифирамбы и высказывали уважение с первых минут разговора.
Я всего лишь ожидаю от людей профессиональной подготовки, тем более, что она занимает всего 10 минут.

К сожалению, нормальное резюме у нас почти никто не умеет готовить, так что задача непростая. Лично я всегда читал CV перед собеседованием и продумывал, что меня будет интересовать в разговоре с кандидатом.

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

Вы никому не нужны

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

Несколько раз мне говорили, что нужный человек был в отпуске, или не успел приехать, или занят, или еще что-нибудь. Я убежден, что это были люди, на которых просто повесили обязанность проводить собеседования. Из этого следует проблема: интервьюеры не рассматривают вас как человека, с которым им нужно будет работать, а просто пытаются оценить, нормальный вы или нет с их точки зрения. У них и так куча своих дел, проблемы на проде, не успеваем спринт, митинги с клиентом, а тут опять очередной кандидат приперся, что с ним делать, а? Достаточно частой была ситуация, когда «ой тимлид сейчас занят, поэтому собеседование будет проводить другой человек».

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

Вы не будете разговаривать со своим будущим боссом или тимлидом

Это следствие из предыдущего. Я глубоко убеждён, что вы должны говорить с тем, кому вы потом будете подчиняться, формально или неформально. Во всех организациях есть какая-нибудь иерархия, будь это Scrum-команда или кровавый энтерпрайз. Везде есть человек, который будет присматривать за вами (как минимум на старте).

Егор Бугаенко в своем посте «Why I Don’t Talk to Google Recruiters» очень хорошо описал эту ситуацию. К сожалению, вы ничего не сможете с этим сделать. Если вы будете требовать разговора со своим будущим боссом — вы просто не попадете ни на какое собеседование.

Возможно, это продиктовано спецификой проектов — аутсорс, где люди что-то делают на потоке. Мне кажется, что сейчас это одна из самых больших проблем найма у нас. Я думаю что нашим компаниям понадобится еще много времени, чтобы прийти к этому и сформировать правильную культуру. Возможно, в целом плохой культурой общения и мизантропичной ментальностью, я не знаю.
В англоязычных блогах часто пишут, что найм является одним из ключевых направлений, жизненно необходимых для построения успешной компании. А пока что приходится аутсорсить это заказчикам.

Когда я нанимался на текущую работу, то разговаривал непосредственно с CTO и CEO. Немного из прошлого опыта. В результате мы отлично сработались, да и собеседование было одним из лучших, которые я проходил. Я должен был бы быть первым инженером в стартапе, поэтому и отношение ко мне было очень скрупулезным и серьезным. Мы обсуждали не только технические детали, но и первые шаги и планы на несколько месяцев вперед.
Даже если собеседование проводить будет не ваш непосредственный руководитель, обязательно требуйте долива пива после отстоя общения с ним перед тем, как принимать предложение (конечно, если удастся пройти все этапы).

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

SAP HANA: где и как эффективно использовать big data и машинное обучение

На парковке аэропорта установлены 20 шлагбаумов для въезда. Рассмотрим конкретный кейс. Зима. Чтобы отслеживать нарушителей, камера распознавания номерных знаков строго фиксирует номер автомобиля, и только после этого открывается шлагбаум. Все номера автомобилей в снегу. Ухудшение погодных условий. Как итог — ...

[Из песочницы] Haiku β1 — сделаем /b/ OS великой снова

Совсем недавно (почти 4 месяца назад) вышла новая Haiku (далее — просто BeOS, ибо проект гораздо удачнее ReactOS — настолько, что разница между Haiku и BeOS уже пренебрежимо мала). Да и недавно прочитанный киберпанк-роман Александра Чубарьяна давал понять, что BeOS ...