#34: Спэшл: Подготовка к FAANG и важность алгоритмов

[01:00] Александр: Сегодня у меня в гостях Дима — ведущий подкаста Java Swag, а ещё он один из лидеров комьюнити FAANG Talks. Там ребята собираются и обсуждают, какой у них опыт прохождения собеседований, вместе к ним готовятся. Дима прошёл не одно интервью в FAANG, получил не один оффер, и поэтому сегодня мы с ним про это поговорим. У меня есть интересный вопрос, который может сбить тебя с толку, но я его задам: как ты здесь оказался?

[01:21] Дмитрий: Конкретно здесь, в подкасте у Саши Пахомова? Можно и так интерпретировать. Саша меня позвал, до этого Саша был у меня в подкасте Java Swag, и вообще мы периодически переписываемся, обсуждаем подкасты, YouTube. Я не мог отказать, потому что доверяю продакшену Сашиного подкаста: я видел, как он подходит к делу, как пишет сценарии, как записывает видосы, — мне очень нравится. Поэтому я уверенно иду в подкаст, зная, что всю чушь он вырежет, а самое классное оставит. Ну или наоборот — оставит чушь и чуть-чуть подрежет. В общем, оказался тут благодаря тебе, Саша, и нашим с тобой подкастам.

[02:18] Александр: Класс. Кстати, да, всем советую подкаст Java Swag — ссылки будут, вот здесь появится картинка, посмотрите, послушайте. Подкаст отличный. Когда я говорил в видосе, что перестал слушать подкасты и слушаю сейчас всего несколько, Java Swag — один из них, честно.

[02:37] Александр: Почему я позвал именно тебя, а не кого-то другого? Мне кажется, тебе интересна тема работы в так называемой аббревиатуре FAANG. Это немного хайповая тема последний год-два, а может и больше, — просто я в ней варюсь последние два-три года, поэтому тебе, наверное, интересно про это поговорить.

[03:03] Дмитрий: Я хочу об этом поговорить. Расшифрую для слушателей: FAANG расшифровывается как Facebook, Amazon, Apple, Netflix и Google. Компаний на самом деле больше, но именно эта пятёрка склеилась с аббревиатурой, и теперь многие разработчики называют FAANG’ом big tech-компании — вот эту четвёрку-пятёрку. Если хотите что-то про это посмотреть, просто вбейте на YouTube «FAANG interview» — и сразу всё поймёте.

[03:31] Дмитрий: В последнее время ещё называют MANGO — аббревиатура с тех пор, как Facebook переименовался в Meta. Могу рассказывать про большие компании в целом, на примере других ребят, с которыми мы общаемся. У нас есть чатик по подготовке к интервью в FAANG, и там все грязные (иногда не очень грязные) инсайды про разработку в больших компаниях и про подготовку к интервью — потому что это весьма специфичный процесс, думаю, мы об этом ещё поговорим.

[04:01] Александр: Ты, можно сказать, из всех моих знакомых настоящий эксперт в собеседованиях и подготовке к big tech. Ты же сам проходил этот процесс, верно? Со сколькими большими компаниями у тебя вообще был опыт взаимодействия?

[04:54] Дмитрий: Смотря за какое время. Мой путь начался с того, что я вообще узнал: оказывается, можно работать в больших компаниях, у них есть вакансии, можно прийти на интервью и попробовать пройти. Лет пять назад я пробовался в Apple, в Amazon — и отскакивал с такой скоростью на первом же прескрине, просто со свистом, потому что не знал некоторых лайфхаков прохождения интервью. И ещё хочу кое-что уточнить. Ты сказал, что я эксперт по прохождению интервью, — тут я бы разделил. В интернете экспертов очень много: погуглите, поищите на YouTube — их толпы. Так вот, я не эксперт. У нас просто есть чат с ребятами, где мы обсуждаем эти вопросы; из этого чата человек пять-шесть попали в несколько компаний FAANG. Я не предлагаю консультации, услуги и всё такое — я могу рассказать историю, как нужно готовиться и что делать, чтобы ваши шансы пройти такое интервью отличались хотя бы от нуля. Потому что если прохождение интервью просто в компанию — это стресс, то интервью в иностранную big tech-компанию такого уровня — это стресс, умноженный на стресс и ещё раз на стресс. Если ваши шансы хотя бы больше нуля, хотя бы 10%, то, подавшись в 10 компаний, вы уже имеете неплохой шанс пройти. Мы работаем именно над увеличением вероятности прохождения интервью в такие компании.

[06:39] Александр: Ты сказал, что ты не эксперт, который что-то может продать. Как считаешь, нужны ли в целом среднестатистическому разработчику — миддлу из какой-нибудь компании в России, который хочет выйти на рынок, — буткемпы, платные курсы, консультации? Или всё есть в открытом доступе и достаточно чуть-чуть поресёрчить и подготовиться самому?

[07:44] Дмитрий: Сложный вопрос, но хороший. Знаете, как в программировании: «it depends», — и задумчивые сеньоры уходят от кулера, считая, что они самые умные. Я тоже хочу ответить «it depends», но чуть разверну. По моему опыту, есть ребята, которые прошли этот путь полностью сами, а есть те, кто проходил его с помощью буткемпов и компаний-помощников. Это очень сильно зависит от вас. Когда вы учите новый язык программирования или какой-то скилл, многие просто открывают YouTube, хоп-хоп — сами составляют план, идут по нему, пишут об этом в Твиттере. У некоторых стиль обучения самодостаточный: они умеют следовать графику, сами смотрят лекции, сами делают домашки. А есть ребята, которые просто не могут освоить это в одиночку, — им нужна группа, нужны помощники. Вот я, когда изучаю новый язык, ни за что не пошёл бы на платный курс: мне достаточно своих знаний, чтобы пройти путь самому. А некоторым сильно нужно комьюнити. То есть ты платишь за друзей, за помощников, а output в конце примерно одинаковый. Если вам проще заниматься в группе, иметь чёткое расписание и ментора — идите в буткемп. Но обязательно посмотрите отзывы. Интервью в FAANG — лотерея: какие вопросы попадутся, какая задача, какой найм. Очень много неизвестных. Идя в буткемп, вы умножаете это на ещё одну неизвестную — можете и деньги потерять, и никуда не попасть, а потом начать винить не себя, а компанию, которая не устроила вам дополнительный воркшоп по той задаче, что как раз попалась. Тут нужно подойти к себе: какой стиль обучения вам нужен, и от этого отталкиваться. Но, честно, каждый раз, когда я смотрю на эти FAANG-буткемпы, у меня улыбка: ну вот ещё один эксперт, их развелось очень много, — так что будьте внимательны. Мой стиль — проходить с единомышленниками, но не в буткемпе: просто найти товарищей, с которыми будешь этим заниматься.

[09:58] Александр: Раз уж мы у меня на канале, я могу довольно открыто высказать своё личное мнение. Мне кажется, если тебе нужно, чтобы кто-то провёл тебя за ручку через прохождение собесов большой компании, то, возможно, ты его и пройдёшь, но как ты потом будешь строить карьеру? Там за ручку тебя уже никто водить не будет. Отсутствие самостоятельности и такого предпринимательства — «я сейчас это изучу, построю план, пройду по нему и попаду на собеседование» — это же тоже часть собеседования, часть фаервола. А ты платишь, чтобы этот фаервол тебе помогли пройти, — а за ним-то что? За ним настоящая работа, там помогать не будут. С моей точки зрения, если человеку кажется, что легче заплатить кому-то и пройти, то, возможно, он пока не готов к big tech, и надо просто набраться опыта, научиться делать вещи самостоятельно — и уже потом самому пройти этот путь. Но это моё личное мнение. Sorry, если кого-то обидел.

[11:02] Александр: Я тебя слушал, и мне кажется, что собесы в FAANG по вайбу очень похожи на подготовку к ЕГЭ. Как будто это экзамен: попадётся мне в части А вот такое задание — классно, я его знаю; не попадётся — ну, попробую решить. Насколько это правдиво?

[11:32] Дмитрий: По моему опыту это так не работает. Очень много раз было, когда я знал, как решать задачу, но на интервью всё равно не мог её решить. Напомню: для FAANG есть несколько этапов интервью — обычно нужно пройти два алго-интервью, одно behavioral и одно по system design. Два алго-интервью — это, как правило, две задачи, ограниченные по времени, примерно две с LeetCode уровня medium. У многих варьируется: где-то одна hard, где-то medium, потом с усложнением hard. Так вот, у меня часто бывало, что я знаю, как решать задачу, решал её несколько раз, а на интервью не мог — там были другие неизвестные. Ты запинаешься на объяснении. Иногда не видишь паттерн: на LeetCode у тебя была лягушка, которая прыгала, а тут не лягушка, а яблоко, которое катится. И это лишь маленькие нюансы. На LeetCode задачи даются с уже «программистским» условием — суть на поверхности. А на интервью та же задача может занимать целый лист A4, и тебе нужно выудить оттуда этот маленький алгоритм.

[13:08] Дмитрий: Я бы не сказал, что это часть А из ЕГЭ; скорее часть Б, где тебе ещё нужно объяснять условие. Многие запинаются на том, что могут решить, но не могут объяснить; другие могут объяснить, но не могут решить; кто-то вроде решает, но код пишет — а он не работает; многим не хватает времени. Это отдельный скилл прохождения именно алго-интервью, и к нему нужно готовиться, тренироваться. Это как слепая печать: ты либо печатаешь не глядя, либо нет. Можно ли без этого обойтись? Безусловно. Но как классно, когда кто-то очень быстро печатает или мастерски владеет Vim’ом. Это навык, который можно развить, но, к сожалению или к радости, он используется только в этом узком сегменте — в прохождении алго-интервью.

[13:49] Александр: Раз уж мы про алго — насколько решает бэкграунд? Готовиться, я так понимаю, нужно более-менее всем, но степень подготовки варьируется.

[15:07] Дмитрий: Безусловно, алгоритмический бэкграунд вообще решает. Я знаю многих ребят, которые занимались олимпиадным программированием даже в школе, не обязательно в университете, — и они щёлкают эти задачи гораздо быстрее, чем те, кто только в 30 лет решил подготовиться. Бэкграунд очень сильно решает: если он у тебя есть, проходить интервью гораздо проще. Это как настольный теннис — я играл в него в школе, и сейчас, взяв ракетку, всё равно хорошо перекидываю мячик через сетку; я просто не могу забыть этот навык. Как езда на велосипеде или плавание — ты умеешь это делать. Качество — уже другой вопрос: какой у тебя топ-спин, как ты тянешь руку в баттерфляе, — но базово ты умеешь. Есть и разные типы бэкграунда. Допустим, ты не алгоритмист, а девопс — или вообще из другой сферы — и хочешь пройти в FAANG. Тебе в первую очередь нужен язык, чтобы решать алго-интервью, и знать его досконально.

[16:11] Дмитрий: Ты не можешь прийти на собеседование, если твой язык Java, и не знать, какая сложность операций у HashMap, у ArrayList, у LinkedList. Это нужно знать обязательно. То есть для алго-интервью тебе нужно быть ещё и экспертом языка программирования. Здесь эти интервью пересекаются с обычными: когда ты приходишь Java-программистом, у тебя спрашивают размеры примитивов, размеры объектов, какую-то внутрянку. Если ты не помнишь, как пишется метод, — это съедает столько мыслетоплива, что ты просто застреваешь. И несколько таких застреваний — не вспомнил, length там или size, — и всё, очень видно, как ты тормозишь. Знание языка нужно просто выгрузить на кончики пальцев, чтобы даже не задумываться, какие функции и структуры данных ты используешь, и сконцентрироваться только на задаче. Бэкграунд важен, но это всё подтягивается: можно стать специалистом своего языка, просто нужно тренироваться.

[17:57] Александр: Да, я в последнее время тоже замечаю, что уже совсем не думаю о языковых приколюшках — они, что называется, на кончиках пальцев. Выгрузил их из головы на кончики пальцев, и они делают механическую работу, а голова придумывает решение и видит более высокую картину.

[18:41] Дмитрий: Отличный стек со слепой печатью: сидишь как Максим, что-то фигачишь, а сам думаешь над решением. Но это действительно опыт. Причём его можно набрать специально, чтобы подготовиться к интервью: два года изучаешь тонкости языка, нарешал 150 задач всех уровней — и оно у тебя на кончиках пальцев. А можно просто за счёт работы: если много пишешь кода, то даже когда делаешь скукотищу — перекладываешь JSON, пишешь метод, аннотации, — оно всё равно врастает в эти кончики пальцев и потом помогает на собесах.

[19:01] Александр: Про алгоритмическую часть следующий основной вопрос: сколько нужно времени, чтобы к ней подготовиться? Хочется услышать какой-то конкретный пример.

[19:45] Дмитрий: Конкретно у меня это заняло около 9 месяцев, можно сказать, почти год, — и это решение задач просто на LeetCode. Не скажу, что не смог бы пройти интервью через три месяца, — возможно, и смог бы.

[20:57] Александр: А какая интенсивность? Давай на конкретном случае. Вот я, Саша Пахомов, хочу пойти в Netflix. Что мне делать?

[22:00] Дмитрий: Во-первых, зайди на их сайт, посмотри, что за вакансии, почитай, какой у них технологический стек. Может, ты и не хочешь в Netflix, может, тебе там не понравится. Второе — узнай, какое у них интервью, посмотри примеры задач. Netflix входит в FAANG под буквой N, но это условно: интервью у всех разное. Например, в Google, по слухам, не спрашивают динамическое программирование, — но, возможно, конкретно тебя спросят. У каждой компании свои заморочки. Поэтому про Netflix я бы сначала почитал, изучил, хочешь ли ты туда вообще. И даже если очень хочешь именно туда, я бы не целился в одну компанию, а взял пул: отсортировал бы по тем, которые не очень хочешь, и тем, которые очень хочешь. Сначала проходишь собеседования в те, что не сильно хочешь, — тренируешь скилл прохождения, — а в конце оптимизируешь под компанию мечты. Некоторые вообще увольняются с работы и три месяца решают LeetCode. Я так не могу — у меня едет кукуха, физически не могу интенсивно по 8 часов в день что-то решать. Мой путь — это марафон. Есть два типа бегунов: спринтеры, которые стометровку бегут очень быстро, и те, кто бежит 20 километров — не так быстро, зато долго. Я бы оптимизировал под ваш стиль обучения. Любите сесть и за три дня выучить всё перед экзаменом, прийти с красными глазами, но загруженным информацией, — или готовитесь долго, чтобы в голове что-то постепенно оставалось? Мой подход — готовиться к марафону. Слишком интенсивно готовиться я бы не стал и текущую работу не бросал бы: вдруг вы её любите и не против остаться. Я вот обожаю писать базу данных, это одна из лучших работ.

[24:09] Александр: Надеюсь, менеджер тебя сейчас смотрит. Смотри: ты сказал, что спринтеры — это условно по 8 часов в день, бросаешь работу и фигачишь. А марафон — это по сколько часов в день или в неделю?

[24:29] Дмитрий: Я бы сказал, где-то по часу в день, и, наверное, по выходным проходить какие-то контесты на LeetCode. Опять же, чтобы не пугать всех и не говорить, что это год: через три месяца вы уже готовы. Просто закладывайте на то, что иногда компании не отвечают, иногда нужно найти рефералов, иногда нужно выстроить компании в расписание. Это такая игра в стратегию, даже RPG: ты размечаешь, когда у тебя интервью в какие компании, чтобы офферы пришли примерно одновременно и ты мог один оффер приносить в другую компанию и торговаться за больший. Часа-двух в день хватает. Мне, например, ещё нужно было подтягивать алгоритмы — деревья, обходы в ширину и в глубину, всякую теорию, — не то чтобы я был так свеж. На это тоже нужно время. Есть ребята, которые сразу бегут решать задачи на LeetCode, а я, например, взял два курса Седжвика на Coursera и прошёл темы по computer science. Потому что я всё-таки верю: FAANG — компания мечты, но не всегда компания мечты — это то, о чём вы действительно мечтаете. Мне интересен computer science сам по себе. Если вам нравится решать задачи — попробуйте получить от этого удовольствие, играйте вдолгую: и кукуха будет получше, и компаний на интервале хватит, чтобы не сильно переживать. И если за год что-то не получилось, следующий цикл подготовки вы начнёте уже с другого уровня, и времени понадобится меньше. В случае, если ни одного оффера не выйдет и мне скажут «Саша, ты не умеешь в динамическое программирование», весь накопленный бэкграунд послужит хорошей базой в следующем году. А если я поиграл в спринт и ничего не получил — во-первых, мне нужен будет как минимум кукухотерапевт, а во-вторых, эти знания грузились в краткосрочную память, и в следующий раз базы будет не так много. Поэтому если я захочу через год работать в Netflix, мне уже сейчас стоит потихонечку что-то читать, изучать, смотреть.

[25:44] Дмитрий: Ещё я не упомянул: в какой-то момент я делал это один, но потом нашёл единомышленников — 10 ребят в чате. Мы создали свой чат, два раза в неделю созванивались и рассказывали друг другу задачи с LeetCode. Я со всеми провёл интервью. По итогу трое из нас, включая меня, оказались в FAANG: один — в Amazon, одна разработчица — в Google, я — в Meta. Это неплохой процент. Опять же, всё сильно зависит от рынка: можно готовиться, а потом рынок упадёт, и просто не будет открытых вакансий. Но идея такая: если не хотите платить за буткемп — соберите свой. Найдите товарища на работе, которому тоже нравятся алгоритмы, и в обед заходите в переговорку или в Zoom на час и вместе решайте LeetCode. Мы, например, готовили презентации в Google Jamboard: на трёх слайдах рисуешь задачу, рассказываешь про неё, приводишь минимум два подхода и показываешь код. На удивление, это супер сработало. Начали мы готовиться в 2021 году, а созваниваемся с этим чатом до сих пор — уже пишем целый подкаст под названием FAANG Talks, настолько нас это вштырило. Сейчас мы обсуждаем уже не LeetCode, а проблемы system design, прохождение system design интервью, — это уже вторая часть: когда с алгоритмами всё хорошо, постепенно переходишь к подготовке к system design. Это дизайн системы целиком за ограниченное время, часто минут за 40.

[28:56] Дмитрий: Мой совет тебе, Саша, который хочет в Netflix: как только по алгоритмам начнёт хорошо получаться — ты чувствуешь, что задачи решаешь, на контестах из четырёх часто берёшь две-три, — стоит плавно начинать подтягивать system design. Только не «переучивай» LeetCode: у тебя может быть 500 нарешанных задач, но чем больше нарешал, тем больше шанс, что просто не повезёт. Я бы не доводил до момента, когда ты супер-готов, — проходил бы интервью, когда чуть-чуть не дотягиваешь, чтобы не замылить мозг и оставить гибкость.

[29:04] Александр: Если нарисовать линию подготовки, она идёт плавно-плавно, а потом всё медленнее и медленнее: чем больше решаешь задач, тем меньше результата получаешь. А потом, если нарешал полторы тысячи, она, возможно, и вниз пойдёт. Завершая алгоритмическую секцию — топ-3 ресурса, которые можно брать в подготовку?

[31:23] Дмитрий: Точно брал бы LeetCode — аналога просто нет. И мой совет — взять премиум. Заплатив за сервис и зная это, вы получаете временное ограничение: купите на три месяца или на год — будет дедлайн, к которому нужно подвести итоги. Я бы вложился в LeetCode. Но если пока не хотите вкладываться — ничего страшного: в бесплатном LeetCode на форумах просто кладезь информации, местами лучше, чем в премиуме. Это первый ресурс. Второй — какой-то теоретический курс по алгоритмам, который вам нравится: Coursera, Stepik, любимый блогер на YouTube. Я, например, взял бы курс Павла Маврина из ИТМО — смотрю и пересматриваю. Мне очень нравится этот лектор и их подход: они пишут алгоритмы так, что оптимизируют не только решение, но и скорость написания кода, — потому что в олимпиадном программировании нужно писать не только правильно, но и очень быстро.

[33:38] Дмитрий: Третье — я взял бы что-нибудь по алгоритмам в виде книги, просто чтобы отдыхать от компьютера. Например, «Cracking the Coding Interview» — хоть это и база, и банальность, мне она понравилась, и до сих пор считаю её неплохой. Или любую другую книгу по алгоритмам — просто чтобы сменить источник информации с написания кода и просмотра видосов на чтение. Вам нужно распределить внимание так, чтобы все чувства воспринимали, — всеми чувствами готовились к интервью. Вот такие советы по ресурсам.

[34:39] Александр: Супер, я примерно этого и ожидал. «Cracking the Coding Interview» — такой common sense. Я её тоже читал, когда был, наверное, миддлом. Она идеально подходит и для подготовки к алгоритмическим секциям в русских компаниях, потому что там тоже иногда спрашивают алгоритмы, и знания этой книги прям хватает: базовые вещи — строку перевернуть, палиндром проверить, оценить сложность. Это книга, а не компьютер — можно почитать с телефона в метро. Всё очень просто, но очень важно. Джуниорам и миддлам я крайне советую.

[35:59] Александр: По поводу LeetCode: а чем отличается премиум от бесплатного, за что мы платим?

[38:09] Дмитрий: Там есть сортировка по компаниям и по самым часто спрашиваемым вопросам, есть премиальные решения задач. Если готовишься в Netflix — заходишь, выбираешь задачи по Netflix и решаешь их. У некоторых задач в бесплатной версии даже не будет доступно условие. Конечно, можно нагуглить задачу на GitHub или на форуме, но проверить-то её не сможешь. А тут ты в одной платформе: и статистика твоя, и любимые зелёные квадратики как в GitHub — смотришь на них и думаешь: вот ещё один день, вот ещё семь квадратиков. Одна платформа, которая закрывает всю подготовку: решаешь задачи, проходишь контесты, решаешь по паттернам. Там есть даже курс по структурам данных — правда, скорее «вспоминательного» качества: если ты уже знаешь основы, по нему можно освежить. А когда изучаешь с нуля и вообще не в курсе происходящего, лучше взять основательный курс и заложить на него время. Если взяли курс на месяц, а потом ещё решаете LeetCode, — берите лучше два-три месяца. Умножайте время: подходить нужно бережно, лучше взять больше времени. Компании никуда не денутся, а вот ваши нервы могут пострадать — процесс нервный. Я бы оптимизировал вдолгую.

[41:26] Александр: Такой common sense, говоришь очевидные вещи, но правда важно иногда услышать очевидное, чтобы подтвердить своё мнение. В общем, если хочется куда-то отнести деньги — лучше отнести их в премиум-подписку LeetCode, она точно того стоит. Допустим, я подготовился, прошло 6 месяцев, я с платной подпиской решаю по 4 задачи в день и чувствую, что готов. Какой мой следующий шаг?

[43:26] Дмитрий: Я уже говорил — составить лист компаний, в которые хочешь. И я бы тут сделал небольшую паузу и похвалил себя, что ты уже 6 месяцев решаешь задачи, — это нелегко. Даже если никуда не пройдёшь, за эти 6 месяцев ты увидишь, как изменился твой стиль написания кода: динамическое программирование, генерация тестовых данных. Ты начинаешь не гуглить библиотеку для генерации тестовых данных, а быстренько накидывать функцию сам. Нужно обойти что-то в XML — ты такой: «хопа-на, XML это же граф, давай-ка я не буду качать библиотеку, а сам по-быстрому накидаю». И кажется уже, что в проекте можно поиспользовать свои скиллы. Если вы зажглись алгоритмами, вы начинаете видеть их везде и пытаетесь использовать в коде. Про system design мне кажется, что он немного переоценён. Если у вас достаточно опыта и вы дизайнили большие системы с приличным количеством пользователей, я бы вообще отвёл system design на последний этап. Часто ему уделяют много времени, хотя до него можно даже не дойти: бывает, ты такой «всё, алгосы я повторил, начну готовиться к system design», начинаешь готовиться — алгосы подзапускаются, а перед интервью, когда начинаешь их вспоминать, они уже не так идут. Я бы оптимизировал на алгосы, чтобы первые две части пройти ещё лучше. А system design у вас всё-таки есть в каком-то виде: если вы Java-разработчик — у вас есть Spring, компоненты, база данных. Наверняка вы до интервью дизайнили какие-то системы, микросервисы, и у вас есть понимание, что данные-картинки нужно хранить в отдельном хранилище. Из ресурсов, конечно, есть книга Алекса Сюя (Alex Xu) по подготовке к system design интервью — по ней точно нужно пройтись. Либо на GitHub много ресурсов, и на LeetCode тоже: если готовишься в Netflix, погугли «Netflix System Design» — будут вопросы, которые он спрашивает.

[45:30] Дмитрий: Ещё, самый важный пункт, который я не назвал, — моки. Вот вы научились решать алгосы с компьютером, LeetCode всегда зелёный, всё сабмитится — обязательно нужны моки. Попросите товарища выбрать задачу из пула и порассказывайте ему на английском, что вы делаете. Есть куча ребят, которые задачки щёлкают, но рассказать не могут. Это совершенно другой скилл: печатать, рассказывать и создавать план решения. У вас две задачи по алгосам за 40 минут, каждую нужно решить минимум минут за 15, чтобы осталось время на вопросы. За 15 минут ты на LeetCode решаешь шустро. А теперь попробуй за 15 минут решить, ещё и рассказывая, что собираешься делать, и предложив два варианта решения. До кода нужно проверить, какие ограничения в условии. Есть целый алгоритм из 5-7 шагов: убедиться, что понял условие правильно; спросить про ограничения; сказать, каким способом решаешь; предложить brute-force; предложить, как улучшить. И за 15 минут это сложно. Причём всё на английском, через интернет: у вас может тормозить редактор, что-то не печататься. Это прям скилл. Моки обязательны: идти на алго-интервью нужно не когда вы просто решаете алгосы, а когда на моках из пула в 100-200 задач под вашу компанию друг задаёт вам две задачи подряд, и вы решаете их всё чаще.

[46:07] Дмитрий: Интервьюер, который смотрит, как вы решаете, имеет что-то вроде графы — я предполагаю, что он проставляет чекпойнты, пишет на вас ревью. Решил ли задачу — тик. Протестировал — тик. Проверил ограничения — тик. Написал код — тик. Знает ли язык — тик. Вот эти пять-шесть галочек и есть ваше интервью по задаче. Если вы не задали дополнительный вопрос — «а какие входные данные?», «а давайте после правильного кода теперь подебажим вместе» — этой галочки в ревью не будет. И получится, что по двум задачам вы наберёте меньше баллов, чем человек, который решил не так круто, но в конце сказал «а давайте подебажим», а интервьюер ответил «слушай, нет времени, я вижу, что ты решил, всё круто» — но он спросил. Моки очень важны, и начинать мокаться лучше даже параллельно с алгосами.

[47:18] Дмитрий: Перейдём к system design. Там тоже есть моки — по каждой теме, которую часто спрашивают в вашей целевой компании, обязательно проведите мок. Задизайнить за 40 минут очень сложно: идёшь в Netflix — надо задизайнить стриминговую систему. Интервьюер либо продвигает тебя к следующему этапу, если устраивает предыдущий, либо оставляет. Нужно пройти по 6-7 пунктам. Первое — узнал ли ты про функциональные и нефункциональные требования. Второе — посчитал ли back-of-the-envelope estimation: сколько данных, сколько пользователей, сколько видосов, нужна ли вообще распределённая система. Третье — нарисовал ли high-level диаграмму. И всё это нужно проговаривать и записывать, потому что интервьюер после интервью пойдёт пить кофе и садиться писать ревью; открывает ваш черновик — а вы сказали ему про non-functional requirements, но не записали, — и он может забыть и не поставить галочку.

[50:59] Александр: Давай я проговорю то, что запомнил. Первое — функциональные и нефункциональные требования, по сути, что от нас хотят. Если так подумать, я как архитектор иногда решаю такие задачи и в целом прохожу тот же путь, когда дизайню фичу, — просто он растянут во времени: не 40 минут, а 40 часов и больше. Путь тот же, просто менее осознанный и менее глубокий. Второе, если не ошибаюсь, — подсчёт на салфетке: сколько данных вообще. Нужно понять, что использовать в качестве очереди — кластер Kafka или в целом хватит single instance, какой-нибудь Queue в Java, — нужен нам монолит или распределённая система, и по какому критерию распределять.

[53:53] Дмитрий: Ещё про функциональные требования часто забывают — очень важно спросить, что мы дизайним, а что нет. Если дизайните Netflix, хорошо сразу вынести за скоуп: про видео — да, а систему авторизации и security договоримся не дизайнить, и пишем, что out of scope. Чтобы уже на этом уровне интервьюер видел, что туда вы не пойдёте и даже не будете это рисовать. И про подсчёты на салфетке иногда слишком увлекаются: не нужно считать, например, сеть, если вы не собеседуетесь на сетевика. Из functional requirements вы вытащили цифры — 20 миллионов пользователей, — и должны прикинуть, сколько данных это займёт, сколько нужно серверов. Это спорный вопрос, кому и когда это нужно. Сколько мы храним данные — 7 лет, год, сразу пропадают? Отталкиваться нужно от конкретной проблемы. В Netflix метадата фильма — не самое интересное, самое тяжёлое — сами фильмы: сколько вариаций энкодингов, сколько нужно сторожей. У Netflix, допустим, 10 тысяч новых фильмов в год. Нужно посчитать именно самую сложную часть: сколько занимает один фильм, сколько ему нужно кодировок, и прикинуть, сколько серверов нужно, чтобы хранить всё, — например, один сервер на 20 терабайт. Не нужно запариваться, нужно показать, как сильны твои лапищи.

[56:41] Александр: Дальше третья часть — верхнеуровневый дизайн, если правильно помню. Мы рисуем квадратики: вот система контент-деливери, географически максимально близкая, вот система подачи субтитров, синхронизации…

[58:39] Дмитрий: Саш, я тебя перебью — это уже слишком серьёзно. Какие квадратики надо рисовать? Один квадрат: в него влево стрелка, вправо out. Условно: пользователь хочет фильм, вот сервер, отдаёт ему данные. Для Netflix — пользователь хочет фильм, ты отдаёшь ему количество метаданных, какие есть варианты этого фильма; даже JSON не надо — просто выбери формат, в каком смотреть, какое расширение. Потом переключаешь пользователя на какой-то сервер, чтобы закачивать бинарные данные. Для high-level подошла бы диаграмма с load balancer, metadata-сервером и сервером фильмов. Тебе нужно эту схему подтвердить с интервьюером: чем больше нарисуешь, тем больше у него будет вопросов. Нужно как можно быстрее закоммититься на high-level дизайне и опускаться в конкретную часть. На high-level ищем минимум и коммитимся: окей — идём дальше; не окей — добавляем ещё квадрат. И так, пока не увидим, что интервьюер согласен.

[59:27] Александр: Окей, получается, следующий, четвёртый шаг — low-level дизайн. Мы начинаем каждый квадратик прорабатывать детально. Если это load balancer — по какому принципу балансим, round-robin или ещё что-то, как сервера будут выбираться. Затем форматы передачи данных: метадату мы как передаём — RPC, JSON или что-то ещё? Начинаем прорисовывать сами протоколы, технические решения: по какому полю шардировать, как разбивать на чанки, как синхронизировать чанки, аудио, видео, субтитры. То, что мне на самом деле нравится делать на работе, — вот именно такие штуки. Это прям интересная часть.

[1:02:17] Дмитрий: Можно добавлю? Про low-level ты всё верно рассказал, но старайтесь не приходить к какому-то одному протоколу. Как мы переходим от high-level к low-level? Мы начинаем «скелетить» систему. Был один load balancer — ты рисуешь поверх него ещё один квадратик, и в терминах system design это значит, что у тебя несколько load balancers. Дальше говоришь, что может быть load balancer седьмого уровня, четвёртого уровня, — предлагаешь варианты, через чёрточку пишешь, какие они могут быть. Если про видео — можешь написать «video codecs and protocols», не называя их. Если про чанки — не нужно называть размер, но ты знаешь, что нужен chunk server, который знает о кодеках. Ты должен предлагать варианты всех компонентов, но не углубляться в специфику. Как только ты сказал «Kafka» или назвал конкретный формат вроде mp4, mkv, а рядом chunk server, — знающий интервьюер тут же может тебя спросить какой-то нюанс: «а вот в таком формате нельзя просто поделить на чанки, там такая-то проблема», — и вы встрянете. Придавайте вариативность, но не называя имён. Можно сказать Kafka, но так: «ставим систему очередей на основе логов, типа Kafka», — и обязательно приписать «Kafka alternatives», потому что иначе можно наткнуться на вопрос «а почему Kafka?», — а на это людям не хватает даже всего времени в YouTube. Опускайтесь в low-level, но не до специфичных деталей; в specific — только если об этом просит интервьюер.

[1:03:33] Александр: Я понял, мой Netflix будет работать на Ignite.

[1:05:00] Дмитрий: Это очень хороший point — использовать те технологии, которые вы знаете. Если вы знаете Ignite, знаете, что это система кэшей, — можете говорить: «здесь я хочу использовать такую систему кэшей, потому что в ней разбираюсь лучше всего; наверняка есть другие, но вот здесь я бы взял такую». Хороший аргумент. Но я был бы очень осторожен с именами: могут спросить «а что это такое?», и придётся тратить время, объясняя интервьюеру, что за Ignite. Тут два момента: интервьюер может офигеть, как хорошо вы шарите, и спросить деталь, на которую вы не ответите, — упс; либо наоборот, интервьюер не знает и попросит объяснить, а вы не готовы — тоже упс. А ещё третий момент: это крадёт время, а время ограничено — вам нужно систему задизайнить, а не 20 минут рассказывать, как Kafka работает внутри. Поэтому важно двигаться очень аккуратно.

[1:07:57] Александр: Мне понравилось, что ты несколько раз сказал «максимально аккуратно». Это ещё и игра: в целом задизайнить я могу, но насколько мы с интервьюером пройдём это интервью вместе и какой он оставит обо мне фидбэк — это немножко другая лига. Не хуже, не лучше, просто другая, и в ней надо уметь играть. Мы обсудили всего четыре основных момента, ещё три осталось?

[1:08:34] Дмитрий: На самом деле ты прав. Я сказал «семь», но в книге Алекса Сюя и в советах по system design иногда функциональные требования складывают в одно, и, возможно, у нас на самом деле пять. Также при low-level мы уже параллельно начали скейлить, а иногда скейлинг выносят в отдельную часть: нарисовали low-level, а потом — что, если пришло больше пользователей, если выросла юзербаза? Про скейлинг: нужно понять, откуда основная нагрузка. Если Netflix — фильмы выходят каждый год, вроде немного, но интервьюер скажет «как немного, давай посчитаем»: пусть 300 фильмов в год, а в многих кодировках это как раз много. Точно не нужно погружаться в те зоны диаграммы, которые вы в начале вынесли из скоупа: если сказали, что не обсуждаете security и авторизацию, — забудьте о ней. Первый лайфхак — увеличиваем количество квадратиков: звучит глупо, но это сложная инженерная задача, поверьте; архитекторы не просто так свой хлеб едят. Второй лайфхак — там, где стрелочка, дорисовать ещё один load balancer или cache. Cache в любой системе: поставите — система хуже не станет, будет сложнее инвалидировать, но вы показали, что думаете о перформансе. И если нужно скейлить географически — вот вы дизайнили всё на US, а теперь выходите на другой рынок, в другую страну: дорисовываете гео-распределённую штуку, когда пользователь заходит — узнаёте страну, находите ближайший сервер. Вариантов скейлинга несколько — они сводятся к вертикальному и горизонтальному, плюс фишки вроде гео-скейлинга и шардирования базы. Вы штампуете квадратики, стрелочки делаете ветвистее, и схемка превращается в дерево с многими веточками. Звучит просто, но нарисовать стрелочку в нужном месте — сложная проблема. Вот и закончили со скейлингом.

[1:09:35] Дмитрий: По behavioral — это ещё одна часть, к которой нужно готовиться, но не так сильно. Наверняка есть ребята, у которых с алгосами всё круто, им нужно только тренировать system design и behavioral. Но в большинстве случаев у ребят из русскоязычных стран с system design и behavioral всё неплохо — нам бы алгоритмы подтянуть тем, у кого нет бэкграунда, таких много. Behavioral я бы готовил в самый последний момент, когда уже точно не можешь готовиться ни к чему другому. Из чего оно состоит? Нужно понять, в какую компанию вы собеседуетесь. Например, у Amazon есть свои leadership principles, и интервью очень специфичное: в каждой истории нужно показывать один из этих принципов. Вам задают вопрос «как вы решаете конфликты?» — а про какой это принцип? В ответе вы должны заматчить его на принципы, рассказать историю про один-два. Каждый раз это декодинг и игра в кошки-мышки: я спрашиваю про проблемы, которые ты решал, а ты отвечаешь так, чтобы в тексте были те самые leadership principles.

[1:11:36] Дмитрий: В других компаниях примерно так же — нужно знать, что они ищут. Мой подход: берём компании, у них часто пересекаются принципы — умение решать конфликты, софт-скиллы, leadership. На любой из этих вопросов, или на их пересечение, вы открываете Google Doc и пишете небольшую историю про то, как вы что-то сделали. Самое важное — рассказываете её по методу STAR: погуглите подход STAR. S — Situation, T — я не помню точно, что это, возможно Task; A — Action или Approach; R — Result. То есть сначала обрисовать ситуацию, рассказать, какая была проблема, какое приняли решение и какой был результат. Каждая история должна ложиться на этот паттерн, иначе интервьюер запутается. По этому подходу и много дизайн-доков пишется — очень хороший подход для сторителлинга. И интервьюер будет задавать уточняющие вопросы.

[1:13:00] Дмитрий: Важно, что я не сказал в начале: иногда алгоритмическое интервью бывает на уровень миддла или джуниора; system design иногда спрашивают на миддла, но не так строго оценивают. А если собеседуетесь на сеньора — у вас обязательно должны быть очень хороший system design и behavioral. По behavioral оценивают, проходите ли вы на сеньора, на что-то большее или меньшее, — потому что там спрашивают, какие у вас были проблемы на работе и как вы их решали. По уровню проблем понятен уровень человека. Если ты просто фиксил баги, немного что-то дизайнил, а фичи и баги приходили от кого-то, — это, наверное, middle-уровень. Если рассказываешь о проблемах целого сервиса, микросервиса, платформы — например, в твоём случае, Саш, целой платформы Ignite: сколько пользователей, сколько скейлилось, как вы спорили по дизайн-решению, — это уже сеньорская позиция. А если говоришь с точки зрения департамента, продукта, фич, продаж — это уже что-то после сеньора, staff-инженер. Уровень проблем, которые ты описываешь, меряет твой грейд. Истории нужно написать и уметь рассказывать так, чтобы они от зубов отскакивали, потому что вас будут сбивать дополнительными вопросами: на каком стеке было написано? Кто был в команде? Куда вы уходили, на какой рынок? Эти уточнения проверяют самое простое — что вы не врёте. Интервьюер изучил ваше CV, увидел, какие у вас крутые проекты, как без вас никто не работает и мир останавливается, если у вас выходной. Истории должны вытекать из CV и матчиться. Я советую написать Google Doc страниц на 10, желательно по две истории на вопрос: можно повторять одну историю на разные вопросы, но подсвечивать её с разных углов.

[1:16:00] Дмитрий: И это приходит, когда вы уже прошли алгосы и более-менее system design. Для некоторых behavioral — просто разговор, как и с алгосами у олимпиадников: «пришёл, прошёл, откликнулся, через два дня оффер». Кто-то говорит «мы просто поболтали по душам» и про system design. Но я всё равно предлагаю паттерн подготовки. На всех буткемп-курсах вас будут учить примерно тому же — не дословно, но цель та же: ответить на вопросы и показать скиллы. Как в алгосах есть 5 шагов, а в system design — 7 пунктов, так и в behavioral есть тики, которые нужно покрыть: рассказал историю, рассказал по STAR, показал leadership, problem solving, communication skills. Многие пишут в резюме «great communication skills, я great communicator».

[1:18:02] Дмитрий: А на behavioral, увидев это, вас могут спросить: расскажите историю, когда именно ваши great communication skills помогли решить проблему. И тут сложно сказать «ну, Виталик был против запилить фичу, сначала гасился, потом мы сходили покурили, я ему всё рассказал, как надо, и Виталик пошёл и сделал». Это не та история. С некоторой точки зрения это действительно communication skills, но рассказать её нужно так же, но с большими подробностями: и Виталик из другого департамента, и у вас было cross-department взаимодействие. Те же истории нужно рассказать по-другому, и они должны быть. У многих ребят их просто нет, и они теряются: «а что я расскажу? Ну, поспорили из-за линтера, из-за кодинга». Когда пишешь этот док, начинаешь задумываться о размере и уровне проблем, которые решаешь. Это очень хорошо с точки зрения карьерного роста — понять, где ты находишься. Некоторые, начиная писать док, думают: «блин, у меня даже истории нет, я баги фиксил, которые Санёк мне кидает, потому что сам не может решить, вообще не люблю эту работу», — и понимают, что для перехода в big tech им, может, надо сначала сменить компанию на более крупную — на какой-нибудь Яндекс или что-то большое из российских, — чтобы решать большие проблемы, хотя бы быть рядом с ними.

[1:20:04] Александр: Много поговорили про behavioral. Открываем Google Doc, задаём себе подобные вопросы. Если ты пишешь в резюме, что отлично решаешь конфликты, — будь добр, парочку конфликтов опиши по STAR, подумай так, чтобы это были реальные конфликты, и будь готов ответить. И про любую другую не-hard вещь в резюме ты должен ответить по той же системе, тоже прописать в доке.

[1:22:01] Дмитрий: Да, но я бы не акцентировался именно на резюме — это был пример. Ничего не мешает просто спросить какие-то вопросы. Если собираешься в Netflix — погугли «Netflix behavioral interview», и там наверняка будет список вопросов, по которым нужно подготовиться. Я знаю, что ты очень любишь писать тексты и сценарии, готовиться к подкасту, — тебе нужно будет просто по всем этим вопросам написать несколько историй. Не надо расписывать на полстраницы: по STAR у тебя должно быть два предложения на Situation, на T (мы так и не выяснили, что это, — на Task), и буквально по два-три предложения на каждый пункт. Что было, где было, кто решил, как выяснилось и в чём была проблема. Это поможет даже решить какие-то проблемы на текущей работе и взглянуть на ситуацию с другой стороны. Очень интересное упражнение, советую его сделать, даже если не собираетесь в FAANG: STAR — проверенный временем метод написания любых текстов.

[1:24:00] Александр: Как будто мы прошли все основные этапы интервью — алгосики, behavioral и system design. С каждым разобрались, поняли, с чего начать и как отточить навык. Вопрос к тебе: задрочив всё сказанное, готов я на все 100%, — как понять, на какую позицию целиться? Ты сказал, что алгосы плюс system design — это где-то middle, а если в behavioral начинаешь говорить, что сделал market research, понял, что продукту не хватает фичи, задизайнил и предложил, — то ты явно уже не middle. Но есть ли ещё что-то, от чего зависит, куда стрелять?

[1:26:52] Дмитрий: Есть несколько подходов. Правильный — поговорить с кем-то с точки зрения career development, есть ассистенты, но это не для нас: мы не любим тратить деньги, если это не LeetCode. Мой подход: даже по написанным behavioral-историям видно, какие проблемы вы решаете. Взаимодействие в англоязычной компании для многих проблема; если это первая такая компания, то на сеньора может быть страшновато — другая среда, другая страна. Возможно, есть смысл пойти сначала на миддла, освоиться и расти. Если идёте на миддла, вряд ли вам предложат сеньора — компании выгодно взять разработчика за меньшие деньги: пусть растёт у нас. А если ты уже staff-инженер седьмого-десятого-двадцатого уровня, зачем тебе приходить, чтобы расти до кого? Поэтому большие компании часто любят немного задаунгрейдить человека. Многих это задевает: «я сеньор, а вы мне миддла предлагаете!» — а многие относятся нормально. Судить стоит по себе. Для меня разница между миддлом и сеньором не такая большая: прийти на сеньора — сначала стрессово, зато не надо промоутиться, ты сразу на своей позиции; а на миддла — легче и спокойнее, просто решаешь таски и осваиваешься. Обычно в таких компаниях к этому относятся спокойно. Если идёте на сеньора и не дотягиваете, рекрутер на вашей стороне — предложит миддла, потому что ему надо закрыть позицию. Я бы откликался просто на все интересные вакансии. Грейд — это хорошо, но проект важнее: можно попасть сеньором в так себе команду, а можно миддлом — в супернскую, где кайфуешь. Много неизвестных. Странно, если у тебя куча опыта, а ты откликаешься на интерна, но плюс-минус один уровень — это нормально, никто неудобных вопросов не задаст.

[1:28:44] Александр: Смотри, когда говорим про позиции — middle, senior, — уровень задачи решает, уровень стресса решает, но решают и деньги, которые мы в итоге получаем. Сколько, на каких грейдах и по каким вилкам платят в big tech?

[1:31:36] Дмитрий: Очень хорошо, что пару лет назад пришлось бы мямлить, а сейчас есть отличный ресурс — levels.fyi. Заходите, открываете интересную компанию и обязательно открывайте location, потому что в разных регионах платят по-разному. Зная грейд и location, вы получаете вилку максимально точно. Даже в русскоязычной компании много информации закрыто — приходится спрашивать у друга друга, «намекни, ты примерно столько зарабатываешь?». А levels.fyi предоставляет обезличенную информацию, очень полезно. Нужно понимать, что в big tech, помимо просто зарплаты, есть стоки, бонусы — несколько механизмов регулирования. Но есть и налоги: часто big tech-компания в стране, где налоги вы платите сами, — а программист из русскоязычных стран привык, что налог за него платит работодатель. Видим число, умножаем на рубли, сравниваем — «ого-гошеньки, я богат, я увольняюсь». Посмотрите, какой налог; есть ресурсы, где можно его посчитать. Сколько будете тратить на жильё, какой уровень жизни — есть калькуляторы. Важный нюанс: зарплата считается в год, а не в месяц, ребята, — в России ты считаешь месячную. Стоки очень важны: растут они или падают? После пандемии всё росло, потом начало падать, и многие заджойнились, когда упало и снова начало расти, — можно на акциях получить гораздо больше, чем с зарплаты. Неизвестных очень много, но я бы в среднем отталкивался от числа на levels.fyi: это средняя, посчитайте налоги, посмотрите стоимость жилья в городе. Посмотрите среднюю зарплату в этом location в обычных компаниях — big tech точно платят не меньше среднего, а как-то больше: не то чтобы кардинально, но больше. Потому что интервью зубодробительное, и многие идут туда, потому что проблема денег если не решена, то ты получаешь достаточно для нормального жилья в этом городе, плюс бенефиты. Там завтраки, обеды, ужины включены — как это посчитаешь? Некоторые ребята завтракают, обедают и ужинают в офисе — а почему нет? Кто-то оплачивает проезд. Сильно зависит от так называемых бенефитов и перков, насколько вам это важно. Компании ещё немного соревнуются: бесплатные тренажёрные залы, бюджеты на мероприятия, спорт. Это добавляет сложности при сравнении с российской компанией. Но сравнивать точно можно с компаниями, которые работают в том же городе.

[1:33:03] Александр: Как обычно, ничего конкретного, но есть на что посмотреть и куда поресёрчить. Были ли у тебя лично или в вашем сообществе какие-то удивительные, кринжовейшие случаи со стороны собеседуемого или собеседующего? Какая-то история, которая кажется тебе весёлой.

[1:36:12] Дмитрий: Ты рассказал, что вейпят на интервью? Нет-нет, где-то я это слышал. Ну, наверное, кто-то в подкасте у Java Swag рассказал, что кто-то начинает вейпить на интервью. Есть куча кринжовых приколов. Мне очень нравится, когда интервьюеры меняются сторонами: ты нарешал задачи, и такой «слушай, давай я тебе задачу спрошу». Я кайфую от таких историй — когда ты быстро решил, а потом «давай я тебе тоже задам». В смысле, на реальном собеседовании, не на моке? Да, есть такие истории в чате. Но в основном бывает сложно, потому что интервьюеры пропадают: уходят в отпуск, увольняются, забывают про тебя. Это сложный с точки зрения менеджмента процесс. Приходят, не знают, кто ты и куда, не читают твоё CV — как и ты можешь не знать, в какую компанию пришёл. Спрашивают «почему вы решили работать в нашей компании?», а ты «очень хорошая компания, вы… стабильная, давно на рынке», и в этот момент начинаешь гуглить, что там за имя такое. В основном big tech стараются унифицировать процесс, сделать его менее болезненным. Самое болезненное — когда интервьюер пропадает, и нет ни привета, ни ответа, ни фидбэка. А обычно вы сразу приходите, знаете, что будет: сколько задач, вам присылают ресурсы, где подготовиться, статьи на Medium. Интервьюер на вашей стороне: «how are you, all okay, I’m doing well» — и погнали решать задачу. С этой точки зрения они, возможно, даже лучше, потому что хорошо унифицированы. Но и тут кто-то может выпасть из цепочки, не передать вас другому, и становится обидно: это же моя любимая компания, я всем сказал, что иду в Netflix, что прошёл интервью, а про меня забыли. Совсем кринжовых историй нет — только из подкаста Java Swag, когда люди вейпают на интервью, но это наше интервью, не big tech.

[1:38:35] Александр: По поводу релокации — мне кажется, это важная тема для русскоязычных, для СНГ-пространства. Я так понимаю, это тоже зависит от компании и даже от конкретного офиса. Последние новости с полей — что там по релокации, предлагают или нет?

[1:41:31] Дмитрий: Да, конечно, это ещё один плюс: если тебя перевозят, компания готова платить и выдавать релокационный пакет. Раньше как было — тебе вообще ничего не надо было делать: приезжает компания, привозит коробки, ты складываешь всё в 20-30 коробок, они забирают, покупают билеты на самолёт, ты прилетаешь — всё перевезено. Как в детский лагерь. Сейчас из-за войны эти цепочки разорвались: стало сложнее платить, например, картой из-за рубежа — какая-то компания не может ни через какого посредника заплатить. За нормальный переезд приходится платить самому, а потом возвращать. Ничего страшного, но у вас должно быть какое-то количество денег на переезд. Если собираетесь переезжать вообще без денег — лучше не надо; почитайте в чатах, обычно это несколько зарплат на несколько месяцев, и чем больше запас — на полгода, — тем спокойнее. Большие компании тем и хороши: релокационный пакет хорош, в первый месяц выдадут жильё в квартире или отеле, помогут найти квартиру. Многие жалуются, что «ассистент мне ничего не сказал, не отвечает», но, по мне, это уже когда ты сильно привык. Знаете, в big tech шутят, что смузи стал жутковатым, бананы зеленоватые, рыба недостаточно красная, — какие-то вещи, к которым привыкаешь и забываешь, что где-то этого вообще нет. Не стоит думать, что везде так. Но в любой сфере есть топ-компании, куда все хотят попасть, как лучшие команды в футболе. Про то, что внутри, часто ходят легенды, потому что наружу ничего нельзя говорить. Но это действительно топ-компании на рынке, и тут ничего не поделаешь: плохой или хороший, он остаётся топом, потому что нет компаний, которые сместили бы его хотя бы по каким-то критериям.

[1:43:43] Александр: Про релокацию получается, что сложнее сам переезд, какие-то усложнения бывают, но всё равно предлагают: топ-компании так или иначе визу тебе сделают — приезжаешь в Англию, сделают английскую, в Евросоюз — европейскую, с Америкой та же история.

[1:46:39] Александр: Очень плотно поговорили, кучу инсайтов и ресурсов намайнили — всё будет, если не в описании, то в закреплённом комментарии. Смотрите зарплаты, покупайте подписки на LeetCode, все книги будут в описании. Точка старта отличная, и мотивация — мне как минимум захотелось для себя попробовать: купить подписку на LeetCode, скачать последнее издание «Cracking the Coding Interview», взять все книжки и просто пройти этот путь. Даже не ради смены работы, а чтобы прокачать себя, — очень важный инсайт, который я сегодня словил и не думал, что мы к нему придём: подготовка к интервью прокачивает тебя как специалиста и на текущем месте. Ты лучше решаешь задачи, быстрее получаешь повышение, становишься более серьёзным инженером, пишешь код быстрее, с меньшим количеством багов. Если пишешь код в Google Docs, ты забудешь про дебаггер — будешь дебажить в голове. Кстати, про дебаггер: я им не пользуюсь уже давно, считаю переоценённой вещью. Знаешь, когда пишешь for loop, ты не думаешь, как он работает, — просто пишешь for i, и это на автоматизме. Так же с паттернами и структурами данных: когда они упаковываются в голову, у тебя есть ArrayList, а есть класс Graph, который ты написал, — его нет в стандартной библиотеке, но ты пишешь его за пять минут и обход дерева ещё за две. У тебя в голове загружена реализация структур данных, и в тестах это просто потрясающе: не надо гуглить, как сгенерировать входные данные. Нужно обойти граф — «а что такого, обойду-ка я». Раньше проблемы, которые ты не замечал, теперь замечаешь, и видишь больше способов применения алгоритмов: где-то заменю LinkedList на ArrayList, или HashMap на какую-нибудь Int2Int-структуру. Зная алгоритмы и структуры данных — не обязательно нарешанные на LeetCode, просто знай их, — ты больше их видишь вокруг и применяешь. Прикольный инсайт: в целом становишься лучше как разработчик.

[1:47:49] Дмитрий: Ты всё верно сказал, я рад, что получилось донести эту мысль: готовиться к интервью просто полезно и интересно, и от этого можно научиться кайфовать, что задачи решаются на LeetCode. Очень много людей решают их уже после того, как прошли FAANG и даже уволились, — просто потому, что это кайфово и интересно. Хотят футболку с LeetCode, которую можно получить, только решая контесты или задачи очень много дней подряд, — и ни у кого такой футболки нет, только поэтому. Многие говорят: «зачем мне эти алгоритмы, эти деревья вертеть? Я на работе деревья не верчу». Чувак, ты их поэтому и не вертишь, что не умеешь. Научись — и будешь, ё-моё.

[1:48:04] Александр: Как банально это ни звучит, ты просто не замечаешь, какие возможности перед тобой есть. Взял библиотеку, засунул туда параметры со Stack Overflow, оно работает — и слава Богу. С одной стороны, да, работает. Но тебе, инженеру, который любит развиваться, неужели не хочется узнать, а как оно реализовано? Может, я сам рядом 100 строк кода напишу, оформлю в тестовую библиотечку, добавлю точки расширения под наш проект — и пускай все пользуются. Это же супер, это и есть кайф инжиниринга. Ради этого-то мы и развиваемся, а не ради того, чтобы скопировать решение, которое подсказывает Copilot. В общем, классный инсайт, ты меня замотивировал. Наверное, после того как сделаю третий сезон подкаста про распределённые базы данных, я начну немножко увлекаться собесами, потому что это просто интересно, как я сегодня понял. Спасибо тебе, Дим, большое! Спасибо, Саша, что позвал. Надеюсь, ещё увидимся в какой-нибудь студии и обсудим твои офферы — в какой из FAANG ты всё-таки решил пойти. Было очень интересно. Класс!