Без одной faangи или как я проходил собеседования

Привет! Меня зовут Рустам, работаю программистом 9 лет. 7 лет работал в Контуре и около 2 лет в Яндексе. В этой статье расскажу про свой опыт подготовки и прохождения собеседований в большие технологические компании, поделюсь рекомендациями.

Пробовался в Facebook, Apple, Amazon, Microsoft, Google. Пять попыток: четыре на бэкенд программиста, одна на инженера по инфраструктуре. Два предложения по работе, два отказа, одно потенциальное предложение.

Принял предложение в Amazon. Сейчас в Лондоне.

Синхронизируемся по терминам

FAANG – аббревиатура для технологических гигантов (Facebook, Amazon, Apple, Netflix, Google). Используется так же для обозначения Microsoft и других компаний.

SDE – краткое сокращение Software Development Engineer. В Амазон так обозначают должности программистов.

SWE – краткое сокращение Software Engineer.

SRE – краткое сокращение Site Reliability Engineer. Инженер, обслуживающий инфраструктуру.

Algo (кодинг) – алгоритмическое собеседование.

System Design – собеседование по проектированию систем.

Behave – поведенческое собеседование.

Mock Interview (моки) – тренировочное собеседование с партнером.

Pramp – платформа для Mock Interview.

Hire – решение интервьюера о найме кандидата.

No Hire – решение интервьюера об отказе в найме.

Onsite (онсайт) – серия финальных интервью. Как правило в один день, иногда в два. После ковида проводят виртуально.

Phone Screen (технический скрининг) – первый этап, где определяется имеет ли смысл приглашать кандидата на Onsite.

Online Assessment – этап-тестирование онлайн.

Team Matching – процесс подбора будущей команды для кандидата.

Easy/Medium/Hard – уровни сложности алгоритмических задач на Leetcode.

Offer (оффер)  – предложение по работе.

Preoffer (преоффер) – предложение по работе, не закончившееся формальным оффером.

Signal (сигнал) – данные в процессе интервью, предоставляющие информацию для оценки кандидата.

Опыт и стартовые условия к началу подготовки

8+ лет продуктовой разработки: Desktop/Mobile/Backend. Имелся опыт олимпиад, контестов и хакатонов по программированию на любительском уровне. До профессионалов ACM как до луны, но начал с фундаментом.

Что было в цифрах

• Leetcode: 21 задача уровня Easy, 77 Medium, 9 Hard.

• Курс по алгоритмам в ШАД Яндекс. Часть 1.

• Английский с репетитором 6+ месяцев (3+ месяцев посвятили разбору поведенческих вопросов, написанию электронных писем, резюме)

• Моки pramp.com: 18 Algo, 6 System Design, 3 Behave.

• Видео по System Design: youtube

• Курс Grokking the System Design Interview.

• Около 30 итоговых собеседований с учетом Phone Screen.

Хронология

Первые мысли о переезде в Европу у меня возникли осенью 2020 года, в основном из-за личных амбиций. До июля 2021 года никаких действий не предпринимал, пока не встретился на улице со своим бывшим коллегой. Он находился в процессе подготовки к собеседованиям в FAANG и предложил тоже попробовать. У меня английский в тот момент был на слабом уровне, я оценивал шансы на успех как около нулевые. Коллега подобрал правильные слова и сильно замотивировал меня.

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

В октябре окончательно решил, что буду пробовать. Начал решать задачи на Leetcode. В ноябре готовиться к системному дизайну. Параллельно готовил поведенческое интервью.

В декабре прошел скрининги и онлайн тестирования. В январе 2022 проходил онсайты в Google, Facebook, Microsoft. В феврале прошел онсайты в Amazon и Apple.

В конце февраля принял оффер.

Без учета английского общий срок подготовки составил три с половиной месяца. С английским шесть месяцев.

Результаты

Google (Poland, Warsaw). Преоффер. Остановил процесс на этапе Team Matching, так как получил оффер в Facebook. После оффера от Facebook попросил звонок с рекрутером Google. Мы с рекрутером обсудили вилку, на которую мог бы претендовать — условия были не очень интересные. Учитывая возможную компенсацию и внутренние сомнения насчет Польши, запросил смену локации. Рекрутер ответил, что сейчас бэкенд разработчиков набирают в Варшаву, а в Лондон в основном берут мобильных разработчиков и SRE. На этом моменте принял решение не продолжать. Сейчас Польша запретила визы россиянам, поэтому переезд туда в любом случае не состоялся бы.

Microsoft (Czech Republic, Prague). Отказ. Hire по всем этапам и No Hire по Behave. Это было самое стрессовое из всех интервью: интервьюер перебивал, душил за знания английского, за не совсем правильное использование слов. После отказа, два дня рефлексировал на тему того, что пошло не так. Думаю, интервьюеру не понравилось, что на моей предыдущей работе было нормальным пойти к акционерам/топ-менеджерам напрямую и обсудить какие-то взгляды на проблемы в процессах. По его рассказам и вопросам сложилось впечатление, что культура в Microsoft сильно вертикальная, которая не одобряет инициатив снизу. В целом, спасибо интервьюеру за такой прессинг, извлек много уроков, что во многом позволило получить очень положительные отзывы за все поведенческие собеседования в других компаниях.

Facebook/Meta (UK, London). Offer E5. Самый прозрачный процесс из всех. Это, как мне кажется, очень честно. Facebook осознанно ставит всех кандидатов в равные условия. Рекрутеры профессиональны, держат руку на пульсе: быстро отвечают, адаптируют ответы индивидуально. Все собеседования, за исключением одного кодинга, прошли гладко. В Facebook дают две задачи Medium на алгоритмический этап. На одном этапе мне дали Medium задачу и постепенно усложняли ее до Hard. В оставшиеся 15 минут дали еще одну задачу, я не успел ее закодить: интервьювер при этом написала очень положительный фидбек. Как оказалось, вторая задача и не предполагалась. Оффер прислали через неделю после онсайта.

Apple (UK, London). SRE позиция, не мой профиль. Отказ. Hire по всем этапам, кроме этапа по Linux. Справедливый отказ, на самом деле. Ещё на Phone Screen честно сказал интервьюеру, что у меня почти весь бэкграунд в Windows и на глубокие вопросы или вопросы по командам Linux в деталях ответить не смогу, нет смысла их мне задавать. Меня пропустили дальше, закономерно завалился на Linux на онсайте. Не совсем знал, чего ожидать от собеседований на SRE. Для меня опыт был интересен и полезен. На месте Apple завернул бы себя на этапе Phone Screen. Фидбек не дали, рекрутер запрос проигнорировал. Запросил фидбек напрямую у менеджера, в обход рекрутера. За это Apple минус в карму.

Amazon (UK, London. Локацию можно было выбирать). Offer SDE III. Амазон долго запрягал: больше недели фидбек за онлайн тест, затем больше двух недель ожидания Phone Screen. Онсайт назначили через месяц – написал, что не смогу долго ждать и если будет подходящий оффер, то приму его. Амазону уважение – на эти слова отреагировали, ускорили онсайт и мгновенно дали фидбек на следующий день после него. Оказалось, что собеседовали на SDE II. В разговоре с рекрутером сообщил, что оффер на такую позицию не приму. Мне предложили калибровочное финальное собеседование, пообещали, что уложатся на всё про всё в два дня. Согласился, прошел собеседование на следующий день, еще через день получил оффер. Впечатляющие тайминги.

Переговоры

Обсуждать условия сложно. С этим у меня как-то не задалось. Сразу после оффера от Meta я остановил финальные шаги с Google. Рекрутеру Meta написал, что предложение меня полностью удовлетворит, если поднять компенсацию на 8-10%. Сказал, что буду готов двигаться дальше и не ждать других офферов. Это была ошибка, так делать не стоит. Не пишите, что оффер вам подходит, не торопитесь с решением. Вам не пойдут навстречу чтобы сэкономить время для найма.

Мне отказали в пересмотре компенсации, моя позиция “готов работать у вас” сыграла в минус: рекрутер понял, что я на крючке, и стал меня ненавязчиво подталкивать подписать контракт. В ответ я стал оттягивать решение и ждать онсайт в Amazon. После оффера от Amazon, написал рекрутеру Meta, что у меня есть конкурирующее предложение. Meta мгновенно предложили сопоставимый контроффер. 

Самым сложным оказалось сделать выбор. Раздумывал сутки: определенный пул бенефитов в Meta был важен для моей семьи, решил принимать оффер. Написал об этом Amazon, честно рассказал о причинах, поблагодарил, дал фидбек и извинился. В ответ получил предложение по кастомному бенефиту для нас от нанимающего менеджера. Был приятно удивлен, что BigTech может быть гибким в таких вопросах. Учитывая потенциальную зону ответственности и адекватную команду, принял оффер Amazon.

У меня есть несколько знакомых, кто поднял компенсацию без конкурирующего оффера. Они писали отказ и список причин. Это рискованный путь. Ничто не делает вашу позицию в переговорах сильнее, чем офферы конкурентов. Старайтесь довести процесс до оффера со всеми, даже если поняли, что не хотите там работать. Ведь twenty bucks is twenty bucks.

Размеры компенсаций для каждой компании можно посмотреть на Levels.fyi.

Про резюме и контакты с рекрутерами

В каком-то смысле тут мне повезло. Сам не рассылал резюме и не искал возможность пройти собеседования. За два года на Linkedin у меня накопились контакты с рекрутерами из FAANG. На предложение собеседоваться отвечал: “пока не интересно, но давайте будем на связи, может что-то изменится”. Из-за этого было не сложно запустить процесс собеседований со всеми одновременно.

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

Про моки

Моки — важная часть подготовки, которая дает понять на какие сигналы надо обращать внимание. Ты учишься на своих и чужих ошибках. Кому-то также помогают избавиться от стресса. Обязательно проведите минимум 5-6 по алгоритмам и системному дизайну.

В какой-то момент польза от моков уменьшается, а трудозатраты остаются на прежнем уровне. Алгоритмические моки в части польза/затраты сместились в сторону затрат после десяти моков, моки по дизайну сильно зависели от удачного подбора партнера. Два партнера по системному дизайну попались очень сильные, поддерживаем связь до сих пор. После двух подряд неудачных моков по системному дизайну решил их не продолжать. Поведенческие моки проводил три раза, получилось не очень хорошо по двум причинам: 1. Необходимо, чтобы партнер имел сопоставимый или больший опыт в IT, опыт проведения интервью, чтобы он мог копнуть и вытащить сигнал. На pramp таких партнеров объективно мало, большинство выпускники вузов. 2. Пул вопросов на pramp сильно пересекается, не очень качественный. Tell me about yourself повторяется в каждом наборе и это превращается в рутину уже на втором моке.

Про английский язык

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

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

Английский необходим и для будущей работы. IELTS я сдал на B2 – такого уровня достаточно для интервью, но маловато для свободной коммуникации на работе.

Этапы собеседований

Здесь я собрал описание этапов собеседований и мои рекомендации к ним.

Вводный звонок с рекрутером

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

На этот этап подготовьте рассказ о себе на 2-3 минуты. Ничего лишнего, просто обозначьте свой опыт этим рассказом. Четко обсудите на какую позицию претендуете, чтобы не было сюрпризов в дальнейшем. Рекрутер вам вышлет материалы по подготовке, используйте их: они соответствуют критериям оценки интервью.

Можно сказать, что вы с рекрутером в одной лодке. У вас одна цель – успешный найм. Не стесняйтесь коммуницировать. К рекрутерам я ходил с просьбами об ускорении и замедлении процесса, переносил онсайт в день онсайта из-за болезни, задавал разные вопросы. Всегда старались найти варианты решения.

Online Assessment

Тестирование онлайн. У меня было в Microsoft, заменяло технический скрининг, и в Amazon, как первичный отбор до технического скрининга. В Amazon в дополнение к задачам было порядка нескольких десятков поведенческих вопросов-ситуаций. Задачи дают разные: кто-то говорит что чаще попадаются аналоги Easy/Medium Leetcode, у меня были Medium/Hard. На этом этапе можно попробовать списывать, но решайте сами, нужно ли оно вам. Решение Hard задачи после этапа не смог загуглить ни для Microsoft, ни для Amazon. Пул задач временами меняют. Мне удалось набрать 100% за решение задач, но по опыту знакомых, дальше пропускают с результатами от 60-70%.

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

Технический скрининг

В большинстве компаний это упрощенный кодинг с Easy/Medium задачами и вопросами про опыт. Были исключения: скрининг на SRE – дополнительные вопросы по системам, железу и сетевым протоколам, а также скрининг в Amazon – 30 минут поведенческих вопросов до кодинга.

На этом этапе достаточно решить задачи вслух и проявить общую адекватность.

Кодинг

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

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

Пример с Google. На одном собеседовании на мое уточнение о входных данных ответили “может предложишь варианты, как бы решал подобную задачу, если она попадется тебе в работе?”. Я порассуждал и предложил данные, которые однозначно были бы в похожей реальной задаче. В ответ получил, что  “нет, так не пойдет, мы не можем иметь такие входные данные, это будет нечестно и слишком просто”. В итоге сошлись на топорных входных данных, которые логично было бы использовать в задаче, если сформулировать ее как абстрактную, а не практическую. Это отняло 5-7 минут от времени на решение. Критическое время для сложной задачи.

Есть такой приём, когда сложность некоторой задачи увеличивают за счет путаницы в условии. Google активно применял такую технику, уводил в сторону и смотрел, как подобного рода ситуации (“distractors”) разруливаются. В других компаниях тоже может присутствовать нечто аналогичное, поэтому не усложняйте, концентрируйтесь на сути и обязательно доводите задачу до решения. Не уходите в разговоры, на уточнение условия тратьте не более 2-3 минут.

Подготовка на Leetcode для кодинга была максимально полезной. У меня куплена премиум подписка — однозначно рекомендую, это инвестиция в вашу карьеру. Прошел карточки Explore и разбирал решения с замочком, разборы многих задач доступны только по подписке. Контент на Leetcode очень компактный и очень качественный, особенно видео, всё таки ресурс ориентирован на успешное прохождение алгоритмического интервью.

Серебряной пули по количеству решенных задач нет. Метрика количества задач в разрезе Easy/Medium/Hard слабо коррелирует с критериями интервью. Оценивайте свое знакомство с каждым подходом. Про подходы можно почитать в Competitive Programming Book. Можно использовать временную метрику: Medium задача по каждому подходу должна решаться за 20-30 минут.

Кандидату, который целится в определенные компании, имеет смысл прорешать топ 30 из их списка. Сложные задачи не будут лишними. Помимо Leetcode прорешал 20+ задач в ШАД Яндекса. На Leetcode задач такой сложности не встречал, что-то типа Hard+. Некоторые из них не удавалось закодить за вечер, даже если в голове был безошибочный алгоритм. Такие задачи дают сильный буст в подготовке.

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

Чеклист для этапа:

• Задать уточняющие вопросы по задаче и входным данным: соотношение входных данных, дубликаты, отсортированность и т.д.

• Обратить внимание на ключевые слова типа “maximize”, “minimize”, “count”. Эти слова помогут распознать задачу на динамическое программирование.

• Думать вслух. Обсудить и предложить несколько решений задачи.

• В оценке сложности учесть все входные данные и их соотношение.

• Уточнить у интервьюера, нормально ли использовать рекурсию. Объяснить trade offs: память, stack overflow и т.д.

• Выделять функции, не усложнять вложенность. Писать максимально понятный и аккуратный код, насколько позволяет опыт.

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

Системный дизайн

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

Мне в подготовке помогли видео в youtube. Также, когда-то читал “Книгу с Кабанчиком”, Google SRE Books. Подготовка поможет разобраться в верхнеуровневом дизайне, но будут трудности с детальным дизайном. Это нормально, тут очень большую роль играет опыт и практика. Не надо сильно переживать, что не можете объяснить все детали сложной распределенной системы. Такую систему надо спроектировать и закодить самому, поддерживать под ростом нагрузки, набить кучу шишек. Далеко не у каждого кандидата есть такой опыт.

Чеклист для этапа:

• Уточнить функциональные требования, фичи.

• Уточнить нефункциональные требования: Scalability, Availability, Performance, Consistency, Durability, Cost etc.

• Если задача того требует, то уделить внимание расчетам. Не в каждой задаче это нужно, надо смотреть на условие.

• Дизайн API, дизайн БД. Тоже оцените условие, иногда у вас уже может быть API, а хранение в БД может быть не так интересно в рамках 45 минутной сессии.

• Нарисовать высокоуровневый дизайн.

• Распознать основные компоненты, распознать bottlenecks, распознать потенциальные trade offs и детально обсудить эти моменты.

• Убедиться, что ни одно из требований не упущено.

• Драйвить разговор, быть ведущим в процессе собеседования. Именно это и показывает опыт.

Поведенческое интервью

Интервью о ваших прошлых рабочих ситуациях. На основе вашего прошлого опыта прогнозируется как вы будете действовать в будущем. Оценивается подходите ли вы под критерии должности. Также оценят вашу способность работать в команде. Мне поведенческие интервью и подготовка к ним понравились больше всего. Подготовка помогла пересмотреть свой предыдущий опыт.

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

В процессе подготовки узнал об англоязычном понятии “oversharing”, когда рассказываешь больше, чем от тебя ожидают. Не совершайте такой ошибки, будьте честны, но не выходите за границы вопроса. Не рассказывайте личные вещи, не обобщайте, не давайте оценку если не просят, излагайте факты как есть. Всё лишнее может стать причиной отказа в найме. Если с человеком на другом конце экрана не случился правильный контакт, то лучше потенциально чувствительные истории обойти. Потом уже принимать или отклонять оффер, в зависимости от того, был ли это случайный собеседующий или ваш будущий менеджер.

AdHoc интервью

Это те интервью, которые не совсем укладываются ни в System Design, ни в Algo. Формат может быть произвольный. Такие интервью были в Microsoft и Amazon. Ключевые слова: OOP, Concurrency, Threading, Linux, Windows. Мне кажется, к таким интервью сложно подготовиться специально, и я до конца не понимаю по каким принципам такой этап может затесаться в онсайт. У моих знакомых и коллег не было таких этапов ни в Microsoft, ни в Amazon. Осторожно предположу, что подбирают под резюме: интервьюеры из Microsoft были с ним знакомы в деталях. При сильном бэкграунде в том, что вы указали в резюме, проблем с этими собеседованиями не будет.

Просто имейте в виду, что какой-то этап может быть не стандартный. Задайте уточняющие вопросы и поймите, что от вас ждут, возьмите ход процесса в свои руки.

Мысли и выводы

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

Прозвучит банально, но рекомендую тоже спокойно получать удовольствие от процесса. Расслабляйтесь, будьте позитивны. Вас собеседуют такие же люди, с похожим опытом. Иногда вы будете ошибаться, иногда они, иногда у вас просто не случится “химия”. Так бывает, достаточно отрефлексировать причины и двигаться дальше.

Составьте для себя план, распределите подготовку и собеседования так, чтобы не перегружать себя. Запрашивайте отзывы после всех онсайтов. Их могут не давать, либо могут давать без деталей. Рекрутеры избегают озвучивания детальных отзывов и оценок за интервью. Для компании присутствуют юридические риски. Просите фидбек в телефонном разговоре, а не по почте, так больше шансов, что раскроют детали. Используйте отзывы для работы над ошибками. Видел рекомендации проходить собеседования сначала в менее интересные компании, но, как мне кажется, куда важнее удобное расписание и правильное распределение сил.

Как видно из моего списка итогов, один No Hire приводил к общему No Hire. Не допускайте слабых интервью, выжимайте максимум из каждого. Не повторяйте одни те же ошибки – паттерны. С ними можно получить общий No Hire, даже если по всем интервью Hire.

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