На этой неделе у нас выступала Ава Катушка — тренер в Verbetcetera.

Verbetcetera — буткамп для тех, кто хочет подготовиться к интервью в Большой пятерке — Google, Amazon, Facebook, Apple и Microsoft. Менторы Verbetcetera распределены по 5 странам, уже работают в компаниях-таргетах, знают все про специфику работы и требования к кандидатам на разных рынках.

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

---

Меня зовут Ава Катушка. Я училась в МФТИ, на факультете computer science, который называется ФИВТ. Мой третий курс был довольно сложным, у меня было много стресса, экзамены, навалились проблемы со здоровьем, семейные проблемы.

Я помню, я зашла в книжный магазин и увидела книгу «О чем мечтать». Мне стало интересно; я помнила, что когда-то о чем-то мечтала, но не помнила, о чем. Я раскрыла эту книгу, и прямо там, в «Библио-Глобусе», начала выполнять упражнения из этой книги. И оказалось, что я выполняла ожидания всех людей вокруг – моей семьи, учителей, кого угодно, кроме своих собственных. Я тогда сильно разозлилась. Мне стало интересно – чего же я, собственно, сама хочу. Позже я сидела в Парке Горького и думала об этом. Я поняла, что хочу путешествовать, хочу завести друзей – у меня была с этим проблема – и хочу с нуля написать свой вебсайт. И у меня, как по волшебству, в том году все начало сбываться.

Оказалось, что есть такой способ путешествовать, где тебе еще и заплатят за это: стажировка. Так я попала в Google в Нью-Йорке, там у меня была стажировка. Где-то в середине стажировки меня спросили, хочу ли я остаться на fulltime. Я подумала – почему бы не попробовать, хотя я и не думала, что меня возьмут. Но меня взяли, и я переехала в Мюнхен. Я работала в качестве software engineer в течение трех лет, у меня довольно разнообразный опыт в этом качестве. Сначала я работала и стажировалась как SRЕ (site reliability engineer) – делала много всего интересного, там была сестринская команда. Но скоро мне показалось, что мне хочется писать больше кода. Я перешла в команду SVI, там мы писали тревел-сайт внутри самой компании, для гуглеров. И под конец я еще узнала, что есть такая специальность — UXE, UX-инженер. Стала изучать немного UX и перешла туда, пытаясь объединить два мои интереса по рисованию и программированию. Получилось у меня довольно средне, но это тоже опыт в области.

Сейчас я не работаю в Google, я как бы решила взять время на то, чтобы узнать, что мне нравится, пробовать всякие гипотезы. В частности, мне хотелось попробовать работать на себя. Я начала вспоминать, что мне в жизни нравилось, и оказалось – мне очень нравился процесс подготовки к интервью. Когда я подавала в разные компании, взаимодействовала с людьми из этих компаний, решала задачи. Это был очень светлый период в моей жизни. Я тогда говорила с другом и узнала, что не у всех этот период – светлый, люди стрессуют на интервью, и потом – «слава богу, это закончилось, я наконец-то работаю». Мне показалось, что я могу, наверно, поделиться чем-то позитивным, превратить этот процесс поиска работы и интервьюирования во что-то приятное, о чем хорошо вспоминать с удовольствием.

Сначала я хотела сама консультировать, но я нашла совет в книге по бизнесу: если хочешь сделать что-то, то сначала найди людей, которые уже это делают что-то хорошее, и ты сможешь у них очень много чему научиться. Тогда я нашла компанию Verbetcetera, там ребята уже занимались тем, чем хотела заниматься я. Там был уже круг менторов; software-engineering-направление было довольно свежее, то есть, оно началось только в 2020 году Но с 2018 существовало менторство PM-ов, которое протекало довольно хорошо. И мне оказались очень близки ценности этой компании: все менторы прошли путь, сами работают в области. Это были ребята, близкие мне по духу, все были (и есть) из FAANG (Facebook, Apple, Amazon, Netflix, Google). Очень классная собралась команда, было интересно присоединиться и попробовать себя в роли ментора.

Я хотела бы рассказать про технологические интервью, ответить на вопросы. Я буду рассказывать про определенную структуру в интервью, останавливаться, смотреть на вопросы, отвечать и идти дальше. Я бы хотела поговорить о coding-интервью: какие вопросы на них задают, какие мифы с этим связаны, как выглядит, в общем, процесс поиска работы с точки зрения компании и кандидата; что такое system design interview, на что оно влияет и какие там есть мифы и популярные заблуждения.

Coding-интервью – что же это такое?

Часто спрашивают, какие вопросы на таких интервью задают. Допустим, один из этих вопросов может быть такой: «на вход поступает зашифрованная строка, раскодируйте ее». Строка может быть такая: 3[A]2[BC]. Раскодируется как AAABCBC. То есть, то, что внутри квадратной скобки, повторяется столько раз, какое число перед скобкой. И вам во время интервью нужно написать программу, которая делает раскодирование.

Такой вопрос действительно задавали на интервью Bloomberg, Amazon, Apple, Cisco, Google, Microsoft; кажется, довольно простой вопрос, даже если вы не связаны с программированием. Но у него может быть двойное дно – например, может быть несколько уровней вложения. Допустим, такая строка: [[[A[[C]].

В таком случае можно сначала расшифровать внутренний слой: ААСС, а потом повторить его три раза – то есть, расшифровать внешний слой (AACCAACCAACC). Написанная программа должна справляться с любым уровнем вложений. Если вы хорошо программируете, это не должно составлять проблему.

Какие темы спрашивают в собеседованиях?

Примеры популярных тем – массивы, строки (как мы уже рассмотрели), задачи на графы. Иногда – сильно замаскированные: например, составить расписание курсов, при том, что у каждого курса есть предварительный курс (пререквизит). Есть задачи на рекурсию: например, есть популярная задача про цены. Даются цены на акцию в течение какого-то количества дней, и нужно придумать алгоритм покупки-продажи для максимального дохода. Иногда встречаются задачи из математики или геометрии, но их не очень много; никаких специальных знаний по этим предметам не нужно, нужны самые базовые, но их тоже хорошо уметь решать. Вообще, очень хорошо иметь фундамент в computer science, ощущать себя комфортно, чтобы решение задач на интервью не составляло проблем.

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

Несмотря на то, что в чистом виде computer science не применяется к работе, базовые знания все равно довольно полезны, когда вы работаете в software engineering. По сути, эти задачи – это прокси дальнейшей работы. Вместо того, чтобы спрашивать, хороший ли вы разработчик, вам дают задачи и смотрят, как вы себя ведете с ними. И хорошие ответы на вопросы коррелируют с тем, что вы – хороший разработчик.

Какие компании задают такие вопросы на интервью?

Довольно много, и не только FAANG (но и они тоже). У меня есть список: Microsoft, Bloomberg, Uber, Adobe, Oracle, ByteDance, eBay, LinkedIn, Yahoo, VMWare, Salesforce, Cisco – на самом деле, я еще многих не вставила. То есть, такие вопросы довольно популярны. Причем, например, в Google и junior, и middle, и senior developer получают одинаковые вопросы, никаких различий нет.

Есть такой популярный миф: важно ли участие в алгоритмических соревнованиях. Меня это сильно волновало: я в них не участвовала ни в школе, ни в институте. Люди часто говорят, что, если ты не участвовал, то твое время уже прошло – ты всегда будешь плохо проявлять себя на интервью. Но это не так. Несмотря на то, что, конечно, участие в соревнованиях вам поможет и будет подспорьем, интервью от них отличаются. Вопросы похожи, вам тоже нужно решить задачу за ограниченное время, но ее решение вы презентуете не системе, которая должна пройти тесты, а человеку. Человек смотрит и пытается по решению задачи оценить, хочет ли он с вами работать. Важно не только то, что вы находите решение, но и то, как вы его находите, как вы думали, сколько вариантов рассмотрели, можете ли вы их донести до человека. Это очень важный аспект.

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

Общий фреймворк для coding-интервью

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

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

Часто люди боятся предлагать решения, которые они придумывают; они думают – зачем это предлагать, это неоптимально, от меня же хотят оптимального. Не надо так. Начинайте с неоптимального решения, говорите о нем интервьюеру: он поймет, что вы уже достигли некоторого уровня понимания. Потом думайте дальше. Возможно, это чем-то вам поможет в процессе. Здесь нет никакого минуса: наоборот, хорошо, что вы сразу увидели решение.

Важно писать хороший, структурированный код – вы хотите показать себя как программиста, который пишет читаемый код. Под конец интервью важно будет оттестировать, для этого можно использовать примеры, которые были придуманы в начале. Так можно отловить ошибки в коде. Потом – надо довольно классно подвести итог. «Я начал так, я придумал такое и такое решение, у них такие и такие преимущества и недостатки, вот такое тестирование, вот так все работает на примерах». Вот такой пример подхода к интервью.

Q: какой уровень английского желателен?

Желательно свободно разговаривать, чтобы свободно понимать интервьюера и выражать свои мысли. Необязательно super-advanced, intermediate должно хватить.

Q: какие изменения произошли в наборе Google по сравнению с тем, что описано в Cracking Coding Interview?

Тут нужно понять, что именно сравнивать с чем. Но я думаю, что основные мысли из Cracking Coding Interview до сих пор актуальны. Не так сильно все изменилось.

Q: где можно поднять свой уровень технического английского?

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

Q: насколько задания с leetcode отражают актуальную специфику задач, которые задают в Google? Актуальны ли задачи с прошлого, позапрошлого года?

Во-первых, вам важно, чтобы задачу, которая вам попалась на интервью, вы не видели раньше. Если задача будет знакомая, и вы будете заранее знать, как ее делать, то это вам не поможет. Это, наоборот, навредит: это будет заметно. Вам нужно иметь незнакомую задачу, но нужно прорешивать много подобных задач. Leetcode для этого хорошо годится; если вы решаете задачи на разные темы, покрываете популярные темы по computer science – в какой-то момент вы станете готовы.

Q: какие языки можно использовать для решения задачи на техническом интервью? Я сейчас решаю задачи с leetcode на JavaScript, но слышала, что нужны Python или C++.

Любой из этих языков – JavaScript, Python или C++ — годится, здесь все равно. Если вы пишете на JavaScript, хорошо, глубоко его знаете, это ваш язык – тогда идите на интервью с JavaScript.

Q: есть ли у вас подход, чтобы правильно оценивать время на каждую задачу на auto code interview, когда есть несколько задач и ограничение по времени?

Не совсем поняла этот вопрос. Ну да, нужно решить много задач, если ограничение по времени, нужно соразмерить свои силы с ними.

Q: задачи, с которыми сталкивался на интервью Amazon и Google, требовали далеко не базового computer science

Ну, я называю это базовым. Мне так кажется.

Q: если кандидатам на junior и senior задают одинаковые вопросы, то как определяют, на какой grade взять разработчика?

Это определяется не по результатам coding interview, а по результатам system design и behavioral interview.

Q: как вообще Google?

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

Далее я расскажу о подготовке к интервью: как готовиться, как компании нанимают разработчиков, сколько потребуется времени

В Google и во многих подобных компаниях процесс выглядит так. Сначала нужно быть замеченным, пройти через рекрутера. Потом идет initial screening, где вам дают 1-3 coding interviews – те самые вопросы, которые мы обсуждали ранее.

Если вы это прошли, то вы переходите на onsite. Там будет большой набор из интервью, обычно от 2 до 4 coding, плюс system design и behavioral. Если вы хорошо показали себя на onsite, то вы получаете offer. У Google в него включается ваша зарплата, relocation bonus – оплата переезда. Часто в offer включат акции компании; я получала такой offer, который их включал – но не сразу, а через год работы.

На первом этапе надо сделать так, чтобы тебя заметили. Я от себя советую попробовать найти кого-то из компании, поговорить с людьми, которые в компании. Так вам станет немного понятна внутренняя культура компании. Кроме того, если вы друг другу понравились, то человек, который в компании, сможет вас порекомендовать – статистика показывает, что рекомендации увеличивают шанс прохождения первого этапа («быть замеченным») в 8 раз относительно заявок через сайт. Ну, для кого-то и заявки через сайт работают.

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

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

• краткость: уложитесь в 1 страницу
• ориентация на результаты: опишите свои достижения — «достиг X, сделав Y с помощью Z»
• ориентация на данные: опишите масштаб ваших проектов – загрузку, прибыль и т.д.
• ссылки: приведите ссылки для демонстрации ваших проектов
• оценка: попросите кого-нибудь оценить ваше резюме перед отсылкой
• меньше специализированных терминов: вас должны понимать

Но, наверно, очень важно сказать, что это довольно сложно сделать одному. По крайней мере, мне было сложно: нужно описывать себя, описывать свои достижения, сделать это хорошим языком, понятным другому человеку. Это хорошо делать с другом, с коллегой; можно прийти к нам, в Verbetcetera, к ментору – попробовать сделать свое резюме так, чтобы его было легко читать, и оно производило хорошее впечатление.

Дальнейшая подготовка обычно состоит из решения задач – например, на том же leetcode – на разные темы, на языке, который вы выбрали. Это может быть JavaScript, Typescript, C++, Java, Python и так далее. Очень многие языки. Еще классно иметь практику в парах – проводить практические интервью для тренировки процесса, это называется mock interview. Вы можете практиковаться с друзьями, есть и специальные сервисы; мы тоже предоставляем такую услугу – можно приходить и практиковаться с ментором. И еще – вы пытаетесь повысить свои шансы получить оффер тем, что вы подаете во многие компании. Проходите интервью, и в итоге куда-то попадаете (туда, куда хотите, я надеюсь); конечно, чтобы эта схема сработала, важно иметь хороший фундамент computer science.

Я интервьюировала нескольких человек, которые недавно проходили в Google, и получалось так: одной-двух недель никому не хватает. Никто не сказал мне, что за две недели подготовился к интервью и прошел. Часто требуется 2-3 месяца, и при этом человек занимается по 8 часов в день. И для этого все равно требуется фундамент – из института, со специальных курсов, чтобы такие задачи не были совершенно новыми. Кто-то на leetcode писал, что весь процесс занял год (правда, этот человек одновременно работал).

Q: какие зарплаты предлагают?

Можете посмотреть на Glassdoor, там можно узнать, какие зарплаты в какой компании предлагаются (в среднем).

Q: Есть ли у вас менторы на .NET-стеке?

Мы как бы не готовим на конкретный язык, у нас менторство по алгоритмам и system design. Конкретный язык для нас не имеет значения, мы не подтягиваем по языку.

Разберем последнее интервью – system design interview. Что это за интервью, какие тут существуют ошибки и мифы, и как к нему готовиться.

Это интервью определяет ваш grade (уровень) в компании. На нем задаются сложные открытые вопросы. Например, «как бы вы написали Google Docs (или Instagram, или Facebook Messenger)». Естественно, для system design interview разные ожидания: если вы junior, от вас практически ничего не ожидается. Но, если вы senior, вы должны классно себя проявить.

Я встречала такое мнение, что к этому интервью бесполезно готовиться: либо у вас уже есть знания и опыт, либо нет. Конечно, знания по system design не появляются сами по себе с наработкой опыта (хотя опыт помогает), но я бы рекомендовала готовиться к этому интервью всем – и junior в том числе.

Структурирование опыта здорово помогает. Вы начинаете видеть за пределами своего маленького кусочка кода, видеть компоненты, видеть целиком процесс, то, как выглядит продукт, из каких серверов, балансировщиков, кэшов он состоит, где в этом продукте могут быть узкие места и уязвимости, как его можно расширить, что делать, если он будет расти. Подготовка к system design interview помогает расти как разработчику, она существенно влияет на offer и позицию. Если вы по сути senior или хороший middle, но вы не готовитесь, то вас, видимо, возьмут на позицию junior, и вам придется уже внутри компании проходить процесс promotion – подтверждения peer review и все остальное, чтобы прийти на позицию, которую вы уже, возможно, занимали в другой компании. Поэтому есть большой смысл готовиться, чтобы сэкономить себе время и получить сразу классный offer. Конечно, offers на позиции senior и junior сильно отличаются – в Google это десятки тысяч евро.

Готовиться к system design interview гораздо сложнее, чем к coding. Нет никакой тестовой системы, которая скажет, что было правильно, а что неправильно. Важно иметь какого-то человека (обычно какого-нибудь senior-разработчика), который бы дал тебе feedback на то, насколько адекватно ты отвечаешь на вопросы. Очень классно иметь базу структурированных знаний и много практиковаться в парах. Можно приходить на system design mock interview, которые мы делаем в Verbetcetera. Также мы думаем когда-нибудь сделать курс по system design.

Общий фреймворк того, как вести себя на system design interview, очень похож на фреймворк для coding interview. Не надо торопиться в начале, надо задавать уточняющие вопросы, пытаться понять, в чем состоит задача. Никогда не нужно сразу начинать решать или давать какой-то ответ, который вы запомнили с какого-то сайта; возможно, в голове у вас и у интервьюера совершенно разные задачи – важно изначально это согласовать, очень много внимания уделять общению и пониманию. Второй этап после согласования задачи – начертить высокоуровневый дизайн для задачи, и его тоже согласовать. После этого надо обсудить, какие в этом дизайне могут возникнуть проблемы, что в нем наиболее интересно, и погрузиться в самую важную и интересную проблему. Под конец интервью надо еще раз пройтись по нему, резюмировать свое решение и предложить какие-нибудь идеи насчет того, что еще может быть сделано и улучшено. И все это нужно сделать минут за 45 (даже меньше, потому что бывают всякие технические заминки) – это очень сложно сделать с ходу, нужно готовиться.

Q: где-то есть профили всех менторов?

Мы пока не делаем этого открыто. Пока могу сказать, что наши менторы работали (работают) в FAANG и не очень заинтересованы в том, чтобы открыто рассказывать о себе. Это может немного смутить, но такой вопрос анонимности.

Q: по каким направлениям ментор оценивает? Только навыки программирования, или еще английский и навыки самопрезентации?

Вас оценивают по навыкам программирования, по умению решать задачи; английский должен быть достаточным для коммуникации (не нужен супер-уровень). Самопрезентация, наверно, тоже влияет, но не так сильно. Наверно, сильнее влияет то, насколько вы адекватный человек? Если вы придете на behavioral interview и говорите, что ненавидите клиентов, наверно, вам не дадут offer, несмотря на навыки самопрезентации.

Q: если senior завалил system design, то предлагают ли ему позицию middle/junior?

Да, обычно просто даунгрейдят. Это распространенная ситуация: senior просто не готовится к system design, заваливает его, и ему предлагают начальную позицию. Но, естественно, если у человека действительно есть level, то он может быстрее обычного расти внутри компании. Немного обидно будет, конечно, что не взяли сразу на senior после интервью.

Q: Эти mock interview по дизайну в РБ (не расслышал название, где и как проводятся, можно более точную ссылку?) у вас проходят на английском или на русском языке? Вообще, менторы у вас из каких стран?

Все mock interview проходят на английском, потому что в реальности они будут проходить на английском. Менторы распределены; я в России, большинство – в Европе, в Англии. Довольно разрозненная компания из разных уголков мира. Ссылка, наверно, будет в описании ролика.

Q: можно ли будет скачать презентацию?

Я не думаю, но можно будет посмотреть в ролике.

Q: mock interview онлайн или оффлайн для москвичей?

Об опции оффлайн мы еще не думали, пока все в онлайне.

Итак, мы сегодня обсудили coding interview – какие вопросы на них задают, популярные ошибки и мифы, как готовиться, сколько времени это занимает (чтобы вы реалистично подходили к процессу и не думали, что у всех это занимает всего 2 недели). И system design – зачем к нему готовиться, и как это вам поможет.

Еще я хотела сделать объявление. Мы хотим набрать курс: если кто-то из ребят хочет разобраться в алгоритмах, которые нужны для tech interview – мы набираем группы, с марта. Группы маленькие, по 3-5 человек или меньше (почти индивидуальные занятия), для работы с менторами из FAANG. Мы в течение трех месяцев будем проходить все основы, которые нужны для подготовки к техническим интервью. Чтобы, если вы чувствуете, что вы на этой теме провисаете, у вас сложился наконец-то хороший фундамент, и вы себя почувствовали уверенно. Это особенно подходит для людей, которые не могут выделить fulltime для подготовки к интервью, которые работают активно — такой формат курса может подойти.

И, если у вас скоро интервью – приходите к нам на mock interview. По алгоритмам, по system design; когда мы его сделаем, будет курс по system design. Я буду очень рада, если вы придете.

Q: будут ли еще наборы, например, в мае?

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

Будьте готовы, вкладывайте в себя и в свои знания. Вы все классные, у вас все получится.