Фуф, вчера был мой день Х, а именно техническое собеседование в Амазон. Забавно, что вся эта движуха началась в начале сентября. Казалось бы, времени навалом, целых 2 месяца, а потом раз - и вот оно. Кстати, если вы пропустили начало истории, то оно
тут.
В целом, назвать это собеседованием трудно, скорее целый собеседовательский марафон, который продлился без малого 5 часов (4 секции по часу с перерывами в 15 минут), с 19.00 почти до полуночи. Каждая секция была с разным человеком, но содержание было примерно одинаковым - несколько вопросов по лидерским принципам амазона (об этом далее), техническая задача (все задачи внизу поста) и возможность самому задать вопросы. Последняя секция была на дизайн системы, а не решение кодовой задачки.
Происходило все это в Chime (амазоновский аналог скайпа) с включенной вебкой и на амазоновской платформе для лайв-кодинга.
Впечатления смешанные. С одной стороны, было очень интересно. Время пролетело незаметно. Были небольшие нервы, однако помог проверенный внутренний механизм - как только я начинаю говорить, все нервы мигом уходят, фокус смещается на разговор. Даже общение на английском не доставило каких-то существенных проблем. Реально, я впервые в жизни так много говорил на инглише, что тоже было своеобразным вызовом. Следуя советам самого амазона, старался улыбаться и говорить во время написания кода, озвучивая свои мысли.
Что касается негативных моментов, то стоит отметить то, что я остался недоволен своими ответами во время задачи на дизайн системы. Я изначально больше всего опасался этого этапа, т.к. у меня мало опыта в этой области. А на голой теории, которую я перечитал несколько раз, далеко не уедешь. Не сказать, чтобы это был полный провал, но ощущение того, что можно было выступить гораздо лучше, не покидает до сих пор.
Со второй технической задачей (про платформы) тоже вышла накладка - я полностью проговорил решение вслух, благо оно не такое сложное, но не успел написать код до конца.
Отдельно стоит упомянуть вопросы про лидерские принципы амазона. Условно говоря, это так называемые кейс-вопросы из серии:
- Расскажите про ситуацию из вашего опыта, когда ваши стандарты написания кода кто-то оспаривал?
- Расскажите про ситуацию из вашего опыта, когда коллега говорил, что ваше решение недостаточно хорошо работает?
- Расскажите про ситуацию из вашего опыта, когда сложное решение удалось заменить простым и элегантным?
- Расскажите про ситуацию из вашего опыта, когда вам удалось спасти котенка и старушку из горящего дома?
Ладно, последний вопрос я выдумал. Думаю что общая суть понятна. Подобные вопросы спрашивали на каждой секции, к концу меня уже, признаться, это порядком подзаебало. Иногда приходилось повторяться и, чего уж греха таить, немного приврать в некоторых местах. Тут надо было рассказать о том, что ты заботишься о пользователях, умеешь вести себя в конфликтах и так далее. В общем, ты за все хорошее и против всего плохого. Не знаю зачем им задавать прям настолько много вопросов на эту тематику, думаю что им виднее.
Также удалось самому задать несколько вопросов разработчикам, которые меня собеседовали. Они рассказали, что у них нет каких-то глобальных стандартов по написанию кода (к примеру, у гугла они есть), в каждой команде свой контроль качества и тулы для анализа, а также имеются какие-то внутренние амазоновские тулы. Еще один чувак занимается разработкой внешнего API для клиентов амазона, рассказал о том, как они делают ревью изменений и поддерживают версии своего API с учетом такого большого количества клиентов (десятки тысяч). Было довольно интересно.
Есть определенный разрыв шаблона - условные люди из фаангов мне иногда казались какими-то небожителями, которые смогли пройти серьезный отбор и делают какие-то мегасложные штуки, недоступные для ума простых смертных. А тут перед тобой сидят такие же разработчики, которые точно также пилят код. Такие же люди, как и ты.
Стоит еще отметить сам процесс организации интервью и работу рекрутера. В прошлый раз я не упомянул об этом, но рекрутерша прям моментально затыкалась даже на полуслове, как только я начинал говорить что-то. Тут она подключалась в перерывах для проверки того, все ли у меня ок. Сами интервью шли четко по времени без задержек. Ну и удивительно было, что не задали ни одного вопроса по джаве, в то время как в снг конторах всем пофиг на твои лидерские принципы и знания алгоритмов, нужны знания джавы и поглубже :)
Извиняюсь за некоторую сумбурность повествования, еще не прошел заряд адреналина. После окончания собеса ни о каком сне не было и речи. Не знал чем себя занять и ходил туда-сюда. Наверное, если бы я был курильщиком, то вчера вечером ушла бы половина пачки, а то и вся целиком. Находиться дома было невмоготу, поэтому сходил за продуктами до ближайшей круглосуточной пятерочки (неожиданно выяснилось, что в районе полуночи у них технический перерыв), подышал воздухом и еще часок посидел, смотря какие-то рандомные видосы на ютубе. Только после этого немного отпустило и удалось заснуть.
Вроде как ответ должны дать спустя 1-2 дня, однако понимаю, что он вторичен. Весь этот опыт очень крутой и интересный, независимо от того, что мне скажут. Исходя из моих впечатлений, думаю что шансы примерно как у АК против QQ.
Далее опишу задания из технической части, под спойлером мои ответы. Признаюсь, я ожидал куда худшего и более сложных заданий.
1. Написать интерфейс для пакета (package), который можно установить. Пакет, в свою очередь, может зависеть от других пакетов. Данный интерфейс будет использоваться другими командами. Пример
А зависит от B
B зависит от С, D и F
С зависит от F
F зависит от G
Здесь не так сложно - нужно подумать о том, возможны ли циклические зависимости между пакетами, что делать если какой-то пакет не смог установиться, уже был установлен, что надо сделать интерфейс максимально гибким и так далее. Какого-то однозначно правильного ответа нет, тут скорее написание кода и обсуждение вариантов.
2. Есть набор платформ с координатами (х,y). Некоторые соединены лестницами. На одной из платформ со стартовым индексом N (имеется в виду индекс в общем списке всех платформ) стоит игрок. На какой-то другой платформе с индексом M находится изумруд. Игрок может передвигаться по лестницам или прыгать с платформы на платформу, максимальное расстояние прыжка - D. Нужно определить - можно ли игроку достичь платформы с изумрудом и какое минимальное время для этого потребуется (любое перемещение между платформами занимает одну единицу времени)
Можно заметить, что “прыжок” с какой-то платформы в данном случае это те же самые лестницы, которые соединяют текущую платформу со всеми другими в радиусе прыжка. Соответственно, задача сводится к поиску кратчайшего пути в невзвешенном ненаправленном графе, решается обычным
BFS.
3. Дан массив из слов, в нем необходимо найти все фразы (стоящие рядом слова) длиной ровно N слов, которые встречаются не менее M раз. К примеру, для фраз длиной 2 слова и вхождением не менее 2 раз при списке
[туз, туз, два, на, флопе, туз, туз, в руке, на, флопе, все, хорошо, на, терне, все, хорошо, ривером, переехали] искомыми фразами будут [“туз туз”, “на флопе”, “все хорошо”]
Дополнительный вопрос - сделать это для всех фраз, длина котоых не менее N слов.
Тут можно спросить про проверку аргументов на неотрицательность, надо ли учитывать регистр.
Решение весьма простое - бежим по списку, для каждого окна в N слов делаем фразу и считаем ее частоту (обычная мапа строка - число, если по данному ключу уже есть цифра, то увеличиваем ее на 1).
Затем бежим по всем фразам и фильтруем по необходимой частоте.
4. Нарисовать дизайн бэкенда системы, которая занимается обработкой запросов с мобильных приложений для вызова экстренных служб. Система должна быть highly available, scalable. Юзеров миллионы.
Тут правильный ответ у каждого свой.
А в целом ситуация не очень хорошая. Навредить такая инициатива не может, я бы сказал что ты в данной ситуации делаешь все правильно (исходя из написанного тобой). Самое плохое что может случиться - в подобной атмосфере ты перестанешь запариваться на ревью, развиваться, искать лучшие варианты и станешь таким же ватным чуваком. Держаться исключительно на жестком самоконтроле в нетребовательной команде (такое было у меня) довольно сложно и точно не лучшее решение на дистанции.
Ну и да, есть шанс оказаться Валерой в данной ситуации.
Разумеется, никто (особенно из менеджеров) не будет тебе говорить что у них там клепают говно, так далеко не уедешь. Такие вещи сразу можно пропускать мимо ушей и узнавать самому, решается это несколькими вопросами будущим коллегам/лиду про ревью, quality gates, деплои и так далее. При четкой, понятной и продуманной структуре ты всегда услышишь внятный и развернутый ответ. В конторах с огромным количеством проектов (типа епама) в разных проектах все по-разному, поэтому в таком случае надо просто принять это как факт.