Как я отказался от миллионных RSU или опыт собеседования в Ozon

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

Disclaimer: В данной статье не раскрываются подробности компенсации и детальные формулировки вопросов на собеседованиях (намёки - наше все =) )

Данный текст появился как результат моего желания дать Ozon развернутый честный фидбэк о процессе собеседования и примерное описание чего же ждать на разных этапах интервью своим коллегам-соискателям ввиду скудности предоставленной информации от самого Ozon. Приступим!

История о том, как всего этого могло бы и не быть, она же Общение с HR

В одно хмурое осеннее утро в Telegram от рекрутера Ozon я получил сообщение об открытых вакансиях. Описание меня заинтересовало, поэтому сразу согласовали время звонка на вечер. Вечером звонка не последовало, однако, спустя несколько часов рекрутер попросил перенести звонок на следующий день (бывает у каждого, подумал я). Утром пришло сообщение о просьбе снова перенести звонок на другое время, что не вызывало никаких проблем. Но в назначенное время - снова тишина, и тут я уже подумал, что не судьба мне узнать хоть что-то об Ozon, но через 25 минут от запланированного времени звонок состоялся. Общение прошло на позитивной ноте, и мы предварительно договорились о моей готовности пройти интервью, в случае если моя кандидатура устроит технических специалистов. 

По описанию процесс интервью выглядел следующим образом:

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

2. Техническое интервью (1.5 часа). Проводит представитель целевой команды. По обещаниям, самый жесткий и суровый этап. Так как интервью team-specific, то его структура может варьироваться в зависимости от команды. Но, как правило, это микс из задач(на алгоритмы и многопоточность) и технических вопросов из вашей доменной области.

3. System-design (1 час). Интервью с “боссом”, как я мысленно называл его про себя. Проводит руководитель руководителей и оценивает вашу способность к решению архитектурных задач. Данный этап не проводится для кандидатов уровня ниже Senior. 

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

История о том, как я “влюбился”, она же Скрининг

Учитывая опыт общения с HR, я пребывал в уверенности что данный этап случится с вероятностью в 50%, несмотря на имеющуюся ссылку для видеоконференцию в Teams. К тому же я не получил материалы для подготовки к интервью, поэтому решил, что характер данного интервью будет “слабо техническим” с бОльшим уклоном в сторону опыта (давно я так не ошибался),  а материалы мне пришлют после данного этапа. 

Одним словом, к данному этапу я подошел в  состоянии максимальной расслабленности и слабой подготовленности в рамках повторения тех.части. 

Встреча началась ровно в назначенное время. Интервью вел тимлид одной из подгрупп достаточно “хардкорного” проекта. Оказалось, что данный этап полностью технический,  из-за чего я немного растерялся. Мой интервьюер это сразу подметил (поверьте, это редкость, когда  технический специалист интересуется почему вы волнуетесь и т.д). 

Удивление мое не заканчивалось, так как технические вопросы были не из многострадальной подборки “Java. Многопоточность. 100 Вопросов”, а касающиеся либо самого проекта, либо моего опыта. Также обсуждался GC, но не в контексте сырой теории, а именно с точки зрения практического опыта, что делало данное собеседование как минимум нестандартным. Отвечая на каждый вопрос, я понимал для чего это спрашивают, так как все интервью было построено по формату “рассказ о части проекта, функционала - логически вытекающий вопрос”. Также, на сколько возможно в наше ограниченное время, был проверен мой кругозор в теории архитектуры баз данных и других популярных систем. Кроме того, все мои ответы на вопросы записывались, для того, чтобы сформировать комплексное представление от других потенциальных интервьюеров. 

Данный этап оставил приятное впечатление и понимание того, что я потенциально буду делать, работая в данном проекте. Интервьюер показал себя профессионалом, как с технической стороны, так и со стороны “софт-скиллов”(не смог подобрать лучшего определения), так как в ходе разговора возникали какие-то несогласия по некоторым темам, которые были мастерски урегулированы.

В результате данного интервью я стал жалеть, что так наплевательски отнесся к подготовке, упущенная возможность работать “рука-об-руку” с таким профессионалом не могла не расстраивать. Я понимал, что если бы, мне прислали офер после этого этапа, я бы скорее всего его принял, таким мощным было впечатление.  

История о том, как leetcode чуть меня не погубил, она же Coding

По результатам скрининга я получил положительный фидбэк, поэтому попал на второй этап, на котором меня должна была ждать “более углубленная технически беседа: с задачками, кейсами” с тем же интервьюером. Наученный собственным опытом, я решил еще раз уточнить чего мне стоит ждать (на прошлом этапе я получил информацию что меня ждет  2 задачи: одна с уклоном в многопоточку, другая в алгоритмы) и где я буду писать код. Данная информация подтвердилась, для кодинга предполагалось использовать - Яндекс.Код (хотя здесь он и не упоминается). Получив ссылку на встречу в Teams, я надеялся на продолжение прошлой беседы и некую возможность реабилитироваться за прошлые несовершенства перед прошлым интервьюером.

В назначенное время я встретился со своим интервьюером… Это был абсолютно новый тимлид из той же группы проектов. Куда делся ожидаемый мною интервьюер так и осталось загадкой (но к этому времени я, признаюсь, привык к сюрпризам).

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

Так как первая половина интервью шла с небольшим скрипом, ко второй половине моего энтузиазма и сил поубавилось. В качестве алгоритмической задачи я получил популярную system-design задачу в FAANG-собеседованиях, однако упор был сделан на ее алгоритмическую часть. К моему сожалению, я не смог идеально описать требуемый от меня алгоритм, хотя, скорее всего, в грязь лицом не упал. Также с интервьюером обсудили технические и архитектурные аспекты данной системы, что, думаю, позволило мне поднять свой уровень. 

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

История о том, как я проектировал “сферического коня в вакууме”, она же System Design

На 3 день после прошлого этапа я получил приглашение на system design интервью. Пройдя по уже привычной немногословной ссылке Teams я встретился с руководителем всей группы проектов(в моей голове - “тимлид тимлидов”, он же обещанный “Босс”) и моим потенциально будущим менеджером. 

К моему огромному удивлению я получил задачу спроектировать одну из стандартных для FAANG собеседований систему, которая, на мой взгляд, подходила бы для более “бизнесовых” проектов, нежели для того пула, в который проходил интервью я. Однако, собеседующий больше фокусировался на технической стороне вопроса и не заострял внимания на бизнесовой стороне, что позволило глубже обсудить используемые технологии, их недостатки и преимущества. Также отмечу, что по моим впечатлениям интервьюер понял что я достаточно хорошо знаком с архитектурой данной системы, и предложил спроектировать уже не такую популярную фичу для системы другого рода. Здесь мне удалось сгенерировать несколько неплохих идей и подходов, но, как известно, лучшие решения приходят в первые 10-30 минут после собеседования… Следует отметить, что при проектировании обеих систем, несмотря на их весьма “бизнесовую” сущность, упор был сделан на используемые технологии и их краткое обсуждение. 

Однако, несмотря на то, что мы обсуждали используемые технологии мы не смотрели в глубину их устройства, хотя, на мой взгляд, специфика проекта требовала такого углубления. К примеру, если компания разрабатывает свою распределенную базу данных было бы очень полезно знать какие подходы и алгоритмы из этой области известны кандидату(сonsistency hashing, virtual nodes, gossiper и т.д), с какими схожими системами он работал, что он знает про их внутренности и т.д; если же компания разрабатывает LoadBalancer, вполне позволительно углубиться в теорию их алгоритмов, принципы отказоустойчивости, специфику сетевого взаимодействия и т.д.

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

И снова про HR(и не только)

По сложившимся обстоятельствам в данный момент жизни я не смог принять предложение от Ozon, на что мой рекрутер постаралась повлиять всячески раскачивая мой “маятник сомнения”(с пониманием отношусь к таким приемам ввиду специфики найма). Однако, после окончательного аргументированного (на мой взгляд) ответа, рекрутер просто исчез (предполагаю, что просто удалил наш чат в Телеграмме, в котором происходило абсолютно все взаимодействие). Признаться, я думал, что формальности в виде пожелания удачи и того, что в случае чего-то, с тобой будут рады возобновить общение, не так важны, однако, не получив их, мне  стало немного грустно.

Также будет нечестным не отметить одну странность, исходящую от менеджмента (или людей согласующих зп). Во время первой беседы с HR я отмечал, что уровень зп не будет являться главным фактором при выборе места работы. После всех этапов на вопрос, есть ли у меня другие офферы, я ответил утвердительно. HR убедила меня назвать уровень предложенной компенсации в другом оффере, чтобы предложить конкурентную зп, несмотря на то, что другой оффер был нерелевантным возможному офферу Ozon по ряду параметров. Спустя несколько дней мой HR попросила прислать скрины данного оффера, так как озвученное мною было неубедительным для менеджмента. Признаюсь, что на этом моменте я призадумался о целесообразности продолжения общения, но мое впечатление от технических интервью победило, и я отправил скриншоты(которые по идеи мог бы и нарисовать…). Я понимаю, что зачастую кандидаты блефуют, дабы поднять уровень зп, но в моем случае были нюансы, которые делали бы блеф крайне неразумным, а такое недоверие при общении с кандидатом все же может склонить чашу весов не в пользу компании. 

Всякие разные соображения

Для соискателей:

• Не быть таким как автор(весьма логично). Если есть непонятные моменты относительно характера интервью - выяснять все до последней интересующей детали.

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

• Внимательно слушать интервьюеров. На текущем этапе могут быть “подсказки” (просто обозначенные темы) для следующих этапов.

• Всегда помнить что “ваши ожидания -  это только ваши ожидания”

Для собеседующей меня группы проектов:

• На мой взгляд, второй этап должен стать первым со следующими модификациями: 

  • Возможность разделить на две логических части (подинтервью)

  • Первая часть - задача + теория многопоточности, специфики языка (60-75 минут)

  • Вторая часть - алгоритм и дизайн системы(30 минут)

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

• Третий этап - тот же system design, только более domain-specific системы.

• Я бы придумал какой-то псевдоним слову “тимлид” и использовал его, так как в конце процесса невольно вспоминалась эта картинка))

Для Ozon:

• Актуализация карьерного сайта, включающая добавление информации про Яндекс.Код как возможно используемого редактора, формате интервью, группах проектов и полезных ссылок для подготовки (какая-то информация присутствует, но, к примеру я собеседовался как специалист, имеющий опыт в Java, но про нее вообще забыли). 

• Система, собирающая фидбэк от кандидатов (пусть даже просто почта, на которую можно отправить свой опус). 

• Не использовать Телеграмм для всего. Хотя я сам активный его пользователь, для меня немного странно обсуждать какие-то детали найма или получать оффер в мессенджере с опцией удаления и исправления сообщений. 

• Предоставление более детальной информации о предстоящем митинге, а не только ссылки на него. 

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

Послесловие

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

Также приятной деталью в офере являются не очень распространенные в России RSU, сумма выдачи которых оговаривается на 4 года. Отмечу также что при обсуждении дохода Ozon оперировал окладом, RSU и входным бонусом. Отсутствие годовых премий, которые как-то зависят от твоих показателей, для кого-то может показаться минусом, но для меня это положительная деталь. Тем более многие компании оперируют такими премиями, как частью твоего финального дохода, который на деле оказывается гораздо меньше (привет компании из предыдущей статьи).