За последние два года я помог более 100 инженерам подготовиться к собеседованию в технологических компаниях. В прошлом году я также вызвался проводить пробные собеседования для новых выпускников. Прежде чем основать свой стартап, я провел собеседование с сотнями кандидатов в Facebook и Microsoft.
Во время этих обсуждений было очевидно, что кандидаты больше нервничают по поводу собеседований по проектированию системы, чем собеседований по кодированию. Я также заметил повторяющиеся ошибки, которые допускают многие кандидаты. В этом посте я собираюсь выявить некоторые из этих ошибок. (Я планирую написать больше о том, что СЛЕДУЕТ делать во время собеседований, но если вы ищете ресурсы для подготовки, я упомянул некоторые ресурсы в конце этого сообщения).
Мы, инженеры, боимся собеседований по проектированию систем, потому что у нас нет возможности проектировать большие системы во время школьных проектов, и даже во время работы у нас редко появляется возможность создать масштабируемую систему с нуля. Обычно мы присоединяемся к устоявшейся команде, и перед нами стоит задача написать функции для определенного компонента. Большую часть времени мы тратим на исправление ошибок, оптимизацию кода и написание тестов. Однако, когда вас просят спроектировать крупномасштабную распределенную систему за 45 минут, вы не хотите тратить время на обсуждение того, как можно сократить время отклика на 20 миллисекунд, избегая копирования из буфера. Вместо этого вам необходимо определить компоненты высокого уровня и описать, как эти компоненты будут взаимодействовать друг с другом.
Сможете ли вы создать Netflix за 45 минут?
Обычно вас просят разработать Netflix (или другой масштабируемый сервис с сотнями миллионов пользователей) за 45 минут. Это, казалось бы, абсурдный вопрос. 45 минут - это слишком мало, чтобы обсуждать детали какого-либо одного компонента. Эти услуги разрабатывались сотнями или тысячами инженеров на протяжении многих лет. Как вы можете сжать всю эту работу и сделать набросок на доске 5x5?
Главное здесь - понять, что ищет ваш интервьюер. Он хочет, чтобы вы дали ему обзор на высоте 50 000 футов, идентифицировали высокоуровневые компоненты и как можно более кратко описали взаимодействия между компонентами. Вот 3 этапа такого обсуждения.
- Нарисуйте большую рамку, представляющую систему.
- Увеличьте масштаб и разбейте эту большую рамку на 5–6 компонентов.
- Кратко обсудите роль каждого компонента, например, вычисления, хранилище, интерфейс, серверная часть, кэширование, организация очередей, сеть, балансировка нагрузки и т. д.
Ваш интервьюер хотел бы, чтобы вы обсудили 1-2 компонента более подробно, и он собирается указать, какой из них. От вас редко ждут, что вы напишете какой-либо код во время этих обсуждений.
Вот несколько распространенных ошибок, которые допускают кандидаты во время собеседований.
Я знаю 20 модных словечек, так что со мной все будет хорошо
Вы можете подумать, что если мне нужно проектировать на абстрактном уровне, я, вероятно, могу наговориться на собеседовании по дизайну. Не так быстро. Ваш интервьюер ищет товарищей по команде, с которыми он будет работать каждый день, и кто-то, кто пытается врать во время интервью, будет делать это снова и снова. Любой опытный интервьюер будет искать людей, которые пытаются использовать такие модные слова, как «No-SQL», «Mongo DB» и «Hadoop». Всегда, всегда ожидайте, что ваш интервьюер попросит более подробную информацию и обоснование. Используйте только модные словечки и модные технологии, например «GraphQL», если вы хорошо их понимаете и можете оправдать и защитить свой подход.
Правило 1. Прочитав статью Высокая масштабируемость за ночь до собеседования, вы не станете экспертом в области распределенных систем.
Я могу притвориться экспертом
Я слышал истории о нескольких очень неловких ситуациях, когда кандидат притворился экспертом в чем-то только для того, чтобы понять, что интервьюер является известным отраслевым экспертом в указанной области. Помимо вышеперечисленных историй (которые я здесь рассказывать не буду), я сам несколько раз попадал в такие ситуации - по обе стороны стола.
В 2006 году я проходил собеседование в Microsoft, и мой собеседник спросил, внедрил ли я B-деревья (или, может быть, B + Trees). Я сказал ему, что знаю, что такое B-деревья, и они полезны в базах данных, но больше ничего не могу вспомнить. Он перешел к другим темам. Позже я узнал, что моим интервьюером был Джеймс Гамильтон, выдающийся специалист по базам данных и распределенным системам. Перенесемся на несколько лет вперед, и мне пришлось реализовать B + Trees (большие B + Trees, содержащие ТБ данных) для Microsoft Azure Storage, и теперь я кое-что знаю о B + деревьях. Даже сегодня мне было бы страшно сказать Джеймсу Гамильтону, что я знаю, что такое B + Tree.
С другой стороны таблицы, однажды собеседник сказал мне, что он реализовал определенные функции в определенной кодовой базе. Ему неизвестно, что я работал над этой кодовой базой до того, как он присоединился к этой команде. Я немного пощупал и понял, что он реализовал клиента только для этой кодовой базы, но требовал гораздо большего.
Очевидно, что подобные инциденты редки. Гораздо более вероятны две вещи:
- Ваш интервьюер может работать над технологиями, о которых вы говорите, и может легко отличить самозванца от эксперта.
- Он, наверное, 1000 раз задавал этот вопрос и хорошо разбирается в возможных решениях. Он быстро поймет, что вы действительно понимаете.
Правило 2. Никогда не притворяйтесь экспертом. Человек, проводящий собеседование с вами, почти всегда разбирается в предметной области лучше вас и может даже быть отраслевым экспертом.
Это действительно моя сфера. Я закончу через 15 минут
Хорошо для вас, но помедленнее. Вместо того, чтобы переходить к уже известному решению, сделайте следующее:
- Соберите требования.
- Задавать вопросы. Ваш интервьюер заинтересован в понимании ваших мыслительных процессов.
- Оцените несколько решений, обсудите плюсы и минусы и посмотрите, к чему вас приведет обсуждение.
На самом деле это хорошая идея, независимо от того, знаете ли вы о домене или нет.
Правило 3. Не спешите с решением. Соберите требования, предложите несколько решений и оцените их. Это должно быть открытое обсуждение.
Бонус: не будь тем парнем
(Отказ от ответственности: ниже приводится гипотетический разговор, и любое сходство с реальными людьми или реальными событиями является чисто случайным.)
Интервьюер: Давайте внедрим Twitter. Как вы собираетесь хранить все твиты?
Кандидат: Я собираюсь использовать базу данных NoSQL, такую как MongoDB.
Интервьюер: Почему не MySQL?
Кандидат: СУБД не масштабируется. Нам нужна масштабируемая база данных, такая как MongoDB или BigTable.
Интервьюер: Но мы в Twitter храним все наши твиты в MySQL, и он очень хорошо масштабируется.
Кандидат: Хорошо, тогда я поправлюсь. Возможно, ваш масштаб не такой уж и большой. Сервисы, которые нуждаются в большем масштабе, такие как Facebook, используют решения NO-SQL.
Интервьюер: Но Facebook также использует MySQL.
Кандидат: Я не знаю, как они могут масштабироваться. Придется поискать. Возможно, у них есть MySQL во внешнем интерфейсе, поддерживаемый BigTable.
Интервьюер: Забудь. Где мы должны хранить наши аналитические данные?
Кандидат: Очевидно, в MySQL.
Интервьюер: Но для MySQL это уже слишком. Мы храним его в HDFS.
Кандидат: Вы, вероятно, начали создавать Twitter до того, как MongoDB стал зрелым. MongoDB может легко обрабатывать как ваши твиты, так и аналитические данные.
Интервьюер: Хорошо, спасибо за уделенное время. Было здорово поговорить с тобой.
Ресурсы для подготовки к собеседованию по разработке программного обеспечения
- Если вы ищете ресурс для подготовки к собеседованию по проектированию систем, посмотрите недавно выпущенный курс Grokking the System Design Interview, который охватывает основы распределенных систем и содержит интерактивные уроки, посвященные проектированию Instagram. , Dropbox, Twitter, Facebook Messenger, Youtube, Facebook Post Search, Typeahead, поисковые роботы, Yelp и Uber / Lyft.
- Если вы готовитесь к собеседованию по программированию, прочтите статью Проведение собеседования по программированию. У него более 80 проблем с кодом на Python, Java, Javascript, C ++ и Ruby . Каждая проблема имеет интерактивную визуализацию для объяснения каждого шага, так что вы действительно понимаете решения, а не просто запоминаете их.
- Составьте эффективный план подготовки. Ознакомьтесь с Coding Interview, чтобы ознакомиться с подробными дорожными картами для подготовки и углубленного изучения собеседований в различных компаниях, включая Netflix.
Фахим является соучредителем Educative. Мы создаем платформу обучения нового поколения для инженеров-программистов и инструкторов. Учащиеся учатся, проходя интерактивный курс. Преподаватели могут создавать и публиковать интерактивные курсы с помощью нашего конструктора курсов. Если вы хотите опубликовать курсы или узнать больше, свяжитесь с нами.
Если вам понравился этот пост, нажмите на значок сердца ниже и подписывайтесь на меня, чтобы увидеть больше.
Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсудить рекламные и спонсорские возможности.
Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!
