Не так страшен найм в Яндекс, как о нём пишут на Хабре

Когда мне в мессенджер постучала рекрутёрка с парой вакансий из Яндекса, то я был несколько озадачен. С одной стороны, я искал работу, и предложение было очень кстати, да и сама вакансия выглядела интересно. С другой стороны, все отзывы о найме в Яндекс вызывают, мягко говоря, смешанные чувства. В топе неизменно висят две статьи с говорящими названиями «Театр абсурда» и «Внутренний Я (ндекс)». Ну, была не была — решил я попробовать. 

1. Первичное общение с HR

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

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

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

2. Архитектурная секция

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

Интервьюер произвёл на меня очень приятное впечатление, был максимально корректен и оставил у меня ощущение не экзамена/собеседования/проверки, а скорее обсуждения задачи с более опытным коллегой — на равных.

По моей собственной оценке, я показал себя не очень хорошо: меня сопровождало постоянное чувство неуверенности в принятых решениях, я довольно много закапывался в детали, и в результате о некоторых вещах (об отказоустойчивости, о железе и ещё о чём-то, кажется) особенно поговорить не успели. Поскольку я довольно сильно сомневался в конкретных технологиях, вместо того, чтобы выбрать БД, я просто обозначал требования к ней. В целом у меня было ощущение, что я подтормаживаю на совершенно очевидных вещах, и с собеседования я ушёл, задержав его почти на 15 минут, с ощущением если не провала, то скорее «середнячка». По сравнению с эталонным решением, приведённым в статье, это и было вполне себе середнячковое. 

Каково же было моё удивление, когда на следующий день я получил обратную связь и приглашение на следующую секцию. Сама обратная связь была подробная и структурированная, меня оценили по шести параметрам, и в числе прочего было отмечено «внимательны к деталям», «подробно и продуманно», «учитываете краевые случаи». Даже то, что я считал минусом — отсутствие конкретных технологий — было расценено и в плюс тоже: «вместо конкретной СУБД перечисляете список требований к ней, что весьма ценно». 

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

  • утром в день собеседования я подтвердил, что всё в силе,

  • в назначенное время меня никто не пустил во встречу,  

  • через четверть часа выяснилось, что «хотели быстро найти замену, но не получилось».

Я в тот день выглядел вот так

Я в тот день выглядел вот так

На следующий раз всё прошло почти гладко (кроме того, что HR не сразу запустила встречу, но это уже такие мелочи).

Для меня это было скорее спортивное состязание — «а вот это ты знаешь? А может и это ты знаешь? Ну круто, тогда вот тебе ещё глубже вопрос». Мы говорили будто бы обо всём айтишном на свете, начиная от особенностей работы сетевых протоколов (включая поля заголовка TCP, которые я вспомнил почти все, но забыл флаги. Впрочем, интервьюер их тоже забыл), файловых систем и прочих низкоуровневых вещей и закончили где-то обсуждением уязвимостей веб-приложений и SSO (я честно ответил, что с этим не сталкивался, однако из первых принципов вывел практически такую же схему, знание которой от меня ожидалось). В принципе, по каждому вопросу мне было что сказать (спасибо ежедневному чтению Хабра за кругозор), и в результате за полтора часа мы прошли только половину списка интервьюера. 

Я на собеседовании на разработчика бекенда в ВК

Я на собеседовании на разработчика бекенда в ВК

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

3. Лайвкодинг-1

Лайвкодинг на секции в Яндексе максимально приближен к написанию кода на бумажке — есть общий веб-редактор с подсветкой синтаксиса, но ничем более пользоваться нельзя. В качестве справочника по функциям выступает интервьюер. Все эти условия подробно оговариваются в начале интервью (хотя то же самое написано в уже упомянутой подробной презентации). Сначала нужно рассказать общий ход решения, согласовать гарантии по сложности (время, память), а потом уже писать. После этого решение «сдаётся» (я говорю интервьюеру, что я сдаю), он очень внимательно на него смотрит и принимает или говорит «тут что-то не то».

Задачек на лайвкодинге было две, но я сейчас помню только одну — сделать то, что называется merge sorted arrays, но только со строками в файлах, которые целиком в память не помещаются. Решил я её быстро, и по итогу немного обсудили, как переделать решение так, чтобы оно было более универсально (т. е. изолировать чтение файлов от собственно логики объединения).

Поскольку после решения обеих задач осталось ещё две трети времени, мы очень приятно побеседовали: говорили и о моём опыте, и о том, чем предстоит заниматься, и об общих подходах, и о факапах, а ещё оказалось, что интервьюер — потенциально мой будущий руководитель (привет, @nProfessor!) и я каждый раз радовался, когда находил какую-то общность взглядов. С интервью я ушёл очень довольный и слегка удивлённый тем, что процесс с лайв-кодингом прошёл настолько просто.

Тем временем…
лайвкодинг в ВК прошёл примерно так же —, но только никакого выполнения кода в голове не было: интервьюер писал тест-кейсы и тут же их выполнял в веб-интерпретаторе. Задачек, опять-таки, помню только одну, то, что на leetcode называется merge intervals. После завершения «задачной» части мы переключились на архитектурное интервью, и времени поговорить не осталось. Да и на самом проектировании распределённого сервиса (вот сюрприз) меня всё время подгоняли.

Ах да, и встречу опять перенесли из-за «накладок», правда, всего на два часа, а не на день.

4. Лайвкодинг-2

После положительной обратной связи (на этот раз без подробностей, просто «фидбек очень позитивный, очень здорово») мне сразу же назначили интервью следующего уровня. В своей обратной связи я посетовал, что задачки какие-то уж очень простые, на что получил ответ: «третья секция у нас считается очень сложной, на ней действительно интересные задачи», и когда я попросил примеров — Кристина прислала мне ссылку на специальный тестовый контест. 

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

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

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

Из приятно удивившего было такое: я решал задачу на PHP, и по условию нужно было возвратить искомую пару значений, если она присутствует. При её отсутствии я написал return false и мне был задан вопрос, который мне очень понравился: «Я не слишком хорошо знаком с PHP, а это идиоматично, что мы возвращаем или пару чисел, или false?»

После решения задач осталась ещё примерно половина времени, и тут было самое интересное: обсудили, что мы оба любим Rust, но разработчиков на нём слишком мало, чтобы писать на нём, перешли на то, как мы учились алгоритмам (оказалось, что оба решали один и тот же задачник Шеня), поговорили немного про особенности управления и целеполагания, про команды, про процесс ревью и много всего. Опять-таки, общение ничем не напоминало экзамен, а ощущалось просто как беседа коллег. 

После этого интервью в течение получаса я получил подробную обратную связь и приятный риторический вопрос от Кристины-HR: «Где вы все время прятались от Яндекса?»

Мои ощущения

Мои ощущения

5. Встреча с руководителем

Следующий (заключительный) этап — встреча с руководителем. Поскольку мы уже пересекались на одном из интервью, мы просто продолжили приятную беседу о разных вещах. Из того, что меня удивило более всего: у меня в резюме много лет написано, что я, вообще-то, гуманитарий-музыковед, и что я с удовольствием расскажу, почему музыковедение и разработка во многом близки по методологии, и об этом обычно никто не спрашивает. Но мой будущий руководитель спросил и с интересом выслушал мои объяснения. В этот момент я окончательно растаял.

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

Вопрос был такой: как ограничить количество запросов от клиентов в API? Вариант обеспечить рейт-лимитинг на уровне nginx был отброшен, и мы дошли до обсуждения алгоритма leaky bucket. Поскольку именно этот алгоритм я (с небольшими модификациями) написал за несколько лет до того, я совершенно был уверен, что для хранения данных по одному клиенту нужна константная память, но объяснить это у меня никак не получалось. Для сравнения, моему коллеге я это объяснил за пару минут без всяких вопросов.

Скрытый текст

Как реализовать leaky bucket на константной памяти без дополнительного таймера:

  1. Считаем, что целевой RPS — X, дополнительно у клиента есть «ведро» ёмкостью L, до «наполнения» которого запросами-«каплями» скорость не ограничивается (в терминологии nginx это называется burst)

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

  3. Вместо этого можно хранить то, что не меняется — момент времени, когда ведро будет опустошено (если оно уже пустое, этот момент в прошлом)

  4. Каждый запрос отодвигает момент опустошения ведра вперёд (на 1/X секунды), и если он отстоит от текущего момента более чем на L/X секунд, то вместо обработки запроса отдаём клиенту 429 Too Many Requests

  5. Периодически нам нужен GC, вычищающий давно опустевшие вёдра

6. Ожидание оффера

Сразу после заключительного интервью ко мне вновь пришла Кристина-HR, и мы ещё раз обсудили вопрос об окладе, а также то, какие материалы я использовал для подготовки к интервью.

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

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

А что там ВК? А там, как говорится, обещали перезвонить, но обещания не сдержали.

Итоги

Две упомянутые в начале статьи сформировали у меня следующее представление о найме в Яндекс:

  1. В найме неадекватно много этапов, особенно с алгоритмическими задачами

  2. Алгоритмические задачи никак не связаны с реальностью

  3. Интервьюеры могут быть предвзяты и необъективны

  4. Процесс найма забюрократизирован и непрозрачен

Каждое из этих сомнений было опровергнуто реальностью…

  • Алгоритмические задачки, конечно, не совсем то, с чем приходится сталкиваться в реальности, но мне-то они в принципе нравятся (и в школе я ездил на олимпиады по информатике). Кроме того, выполнять код в голове в работе приходится довольно часто (например, на код-ревью), и этот навык тоже востребован. А благодаря этому формату у меня осталось много времени поболтать о том о сём — и особенно приятно, что количество задач зафиксировано, и тебя не заваливают всё более и более сложными вопросами (как это было в ВК).

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

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

P. S.

Вообще-то эту статью я хотел написать сразу по получении оффера, но всё откладывал и откладывал. Теперь уже и испытательный срок пройден, и я доволен как слон. Работа непростая, но зато интересная и увлекательная, а самое главное — прекрасная атмосфера общей доброжелательности и профессионального уважения. Ну или мне просто так повезло с Едой.

© Habrahabr.ru