Квест: прохождение интервью в BigTech

Google, Amazon, Facebook, Apple, Tesla — наверное каждый разработчик мечтает попасть в любую из этих BigTech-компании. Это не просто условный престиж или погоня за лучшей жизнью. Это работа в проектах, которые являются лидерами в мировой IT-индустрии. Они задают тренды и развивают новые технологии, которые потом использует весь мир.

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

Мы созвонились с интервьюером, он оказался русскоговорящим и сам предложил перейти к общению на русском языке — это позволит покрыть больше тем. Выяснилось, что он учился в МГУ, запускал несколько стартапов, работал в области искусственного интеллекта, а сейчас является Engineering Manager в Uber в Орхусе, Дания. Помогает управлять сразу несколькими командами, которые занимаются внутренними проектами в компании.

По его словам, Uber делает множество внутренних решений. В частности, та позиция, на которую собеседовали меня, связана с решениями для оркестрации контейнеров. А конкретно контейнеров хранящих состояние (базы данных, key-value хранилища, и пр.). Также есть команды, которые занимаются собственными CI/CD системами, готовят облачные платформы и многое другое. Это все звучало крайне интересно. Затем мы перешли уже непосредственно к собеседованию.

Интервьюер: «Расскажи, пожалуйста, немного о себе. У меня есть твое резюме перед глазами, но было бы здорово услышать чуть более подробный рассказ о твоем опыте и интересах».

Конечно! Спасибо большое, что даете возможность попробовать свои силы на собеседовании в Uber! Это великолепный шанс!

Я из России, но последние 7 – 8 месяцев жил и работал в Армении. Мой основной профессиональный опыт базируется на работе в компании DataArt. Это outsource компания с офисами по всему миру. К нам приходят различные клиенты из множества стран, и мы помогаем им разрабатывать их собственные программные продукты и решения.

Сейчас я работаю Senior-разработчиком на Java, и моим основным полем экспертизы являются e-commerce приложения и системы для доставки сообщений. Два с половиной года назад я присоединился к команде, которая помогала нашему большому клиенту из США разрабатывать их собственную платформу для доставки сообщений о чрезвычайных ситуациях. Это довольно большая система — более 50 миллионов пользователей по всему миру. Мы отправляем в районе миллиона сообщений каждый день. При том, когда я говорю “чрезвычайные ситуации”, то имею в виду в самом деле экстренные случаи: ураганы, наводнения и т.д.

Моя основная роль в этой команде — представлять команду быстрого реагирования на проблемы с production-окружением. Почему это важно: мы говорим о жизнях людей в контексте этой системы. Даже если у вас самые лучшие методологии разработки, великолепная команда оценки качества продукта, всегда здорово иметь команду быстрого реагирования. Она устраняет потенциальные проблемы, которые могут возникнуть у реальных пользователей прямо сейчас, потому что от этого часто зависит их безопасность.

Это что касается моей профессиональной деятельности, но ещё у меня множество и внерабочих интересов. Я более двух лет занимался кикбоксингом с чемпионом мира, запустил каналы на YouTube и Telegram, где доступно рассказываю про IT-темы. Учу иностранные языки. В общем, очень много всего! И я очень рад быть здесь!

Интервьюер: «Очень интересно. А можешь чуть подробнее рассказать, почему ты выбрал именно этот проект по доставке сообщений? Что в нем такого уникального для тебя?»

Да, это в самом деле уникальный проект, я бы сказал. Плюс уникальная команда работает в основном с production.

Больше всего мне нравится здесь, что я все время нахожусь на “передовой”. Мы плотно работаем с командой поддержки продукта, а не техническими людьми. Они взаимодействуют с реальными пользователями и приходят к нам с просьбой решить какие-то технические проблемы, если таковые появились. Как результат, наша работа оказывает непосредственное влияние на реальных людей, потому что они, по сути, часто доверяют нам свои жизни, полагаясь на нашу платформу. Расскажу одну интересную историю, которая со мной здесь произошла. Так будет понятен примерный уровень ответственности, с которым нам приходится иметь дело.

Это случилось примерно полгода назад. В этот момент я уже был team lead команды из пяти человек, и мы все так же занимались поддержкой production-окружения. И ситуация на тот момент была достаточно спокойная: у нас было несколько багов с production — мы ими занимались. Стандартная работа для нас, без жестких дедлайнов.

И я разбирался с одной из этих задач. Обычно команда поддержки создает их в Jira с описанием из разряда: «Что-то сломалось, пожалуйста, почините». Мы, как правило, понятия не имеем, где именно проблема может быть локализована, поэтому владеем довольно широкой экспертизой по всей системе, чтобы быстро сориентироваться, где именно у нас сейчас больное место, опираясь на довольно размытые данные от наших пользователей, столкнувшихся с багом. Однако, чтобы сходу что-то найти, логи — наш главный инструмент.

Я в очередной раз проводил свое утро на Kibana. Пытался найти какие-то записи в логах, которые помогли бы мне раскрутить ту проблему, что у меня была. Но тут произошла очень интересная вещь: пока я смотрел логи, то буквально краем глаза заметил, что некоторые строчки об отправке нотификаций были продублированы снова и снова для некоторых сообщений. Это выглядело очень странно, а значит — стоит проверить.

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

Как это работает в двух словах: когда мы отправляем сообщение, то определенная нотификация обрабатывается на сервере в RAM. Если сервер умирает, то ее текущее состояние должно быть подобрано из базы данных специальным сервисом балансировки и отправлено в RabbitMQ. Оттуда эту нотификацию может забрать новый сервер отправки сообщений и продолжить ее выполнение.

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

Я понял, что это нужно чинить безотлагательно. Быстро сообщил моей команде и команде поддержки, что у нас потенциально есть такая проблема. И сразу начал работать над поиском бага, разбираться, почему все поломалось в такой критической части системы. Да, у меня были и другие задачи, и я знал, что мой беклог немного подрастет, но в данном случае мы говорим о жизнях людей. Мне показалось, что намного важнее переключиться на данную проблему, а затем поработать чуть больше, чтобы закрыть все прочие. Здесь речь идет совсем не обо мне, а о людях, что могут быть в опасности.

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

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

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

И среди них я заметил одно крайне интересное. Одна огромная медицинская организация в Штатах отправляла своему клиенту SMS-сообщение о том, что для него стала доступна донорская почка. Если бы на production не было моего фикса этой проблемы, то мужчина никогда бы не получил это сообщение вовремя.

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

Тогда мы еще некоторое время беседовали о проекте, о различных задачах и вызовах, а также о работе с командой, раз уж я выполнял функции team lead. Однако затем мы перешли к вопросу уже гораздо более интересному для меня. Кстати об этом, много полезной информации об IT-сфере, карьере и жизни — на моем YouTube канале и в Telegram.

Интервьюер: «Расскажи, пожалуйста, приходилось ли тебе в твоей карьере менторить людей?»

Какой замечательный вопрос, ахах! Да, в самом деле у меня был такой опыт именно на работе. Где-то год назад, у нас происходили изменения в команде: некоторые люди ушли, новые пришли. Конкретно появилось три новых middle-разработчика.

Соответственно, моей задачей было не только познакомить их с технической стороной проекта, но и объяснить, чем именно занимается наша команда. Какой уровень ответственности на нас лежит, чем специфика нашей работы отличается от всего, что они, возможно, видели ранее. Это было очень важно — привить им правильное отношение к делу.

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

Но также со многими мы работали и с технической стороны. Например, однажды мы решили создать свой собственный внутренний URL shortener сервис. Я сделал его дизайн вместе с командой, а потом распределил задачи для его разработки. Оказалось, что некоторые технологии и решения, которые мы приняли в момент разработки дизайна, были незнакомы некоторым из наших инженеров.

Распределяя задачи, я также снабжал их набором дополнительных ресурсов, где они могли бы набрать начальные знания по тому или иному вопросу. Например, у одного из разработчиков были проблемы с многопоточностью. Я предложил ему хорошую книгу на эту тему. Также мы провели множество сессий парного программирования, где делали ревью его многопоточного кода, обсуждали возможные проблемы и подходы к их решению. Даже пытались писать свои собственные реализации атомарных типов в Java, чтобы лучше понять, что они позволяют делать.

В результате Shortener был дописан и доставлен на production, а ребята после 4–5 месяцев работы вместе очень положительно отзывались об атмосфере взаимопомощи и постоянного движения вперед, которую мне удалось создать в команде.

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

Интервьюер: «Прости, все правильно? Тридцать? То есть, три, ноль?»

Да, все так.

Интервьюер: «Ахах, это же очень много! Откуда у тебя столько свободного времени?!»

Не знаю, я стараюсь просто грамотно планировать. Пока это работает. Я еще и умудряюсь заниматься спортом, много читать, писать статьи по продуктивности и личной эффективности, вести Telegram-канал, учить итальянский и прочее.

Интервьюер: «Ты серьезно? Как ты к этому пришел?»

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

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

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

Желаю вам таких же захватывающих бесед и интересных историй! Стоит помнить, что они могут появиться только тогда, когда вы постоянно пробуете новое, находитесь в непрерывном поиске того, что вас по-настоящему забирает и вдохновляет. Если еще не нашли, то продолжайте искать каждый день. А если нашли… То не останавливайтесь на достигнутом!