Вопросы на архитектуру систем: Часть 2
Продолжаю свой рассказ об интервью на темы архитектуры систем. Первая часть тут.
Есть ли бонус у архитекторов?
Скажу сразу, я очень теоретически себе представляю, что такое позиция “архитектора”. Но могу сказать, что обычно интервью на архитектуру во всем пакете одно. Редко два (для очень опытных кандидатов). Остальные интервью – это решение задач на алгоритмы и написание красивого, быстрого кода. И если вы отлично сделали вопрос на архитектуру, но слабовато все остальное, то это с очень большой вероятностью значит отказ. В Google нет архитекторов, которые занимаются только архитектурой. От инженеров требуется, что они будут писать много кода, решать сложные задачи и придумывать архитектуру систем тоже. Три-в-одном.
Поэтому если вы сильный архитектор, но уже подзабыли как писать код и решать алгоритмические задачи, то обязательно освежите это в памяти.
Какие вопросы ожидать?
В общем, тут я гарантий не даю и буду излагать исключительно свои соображения на этот счет.
1) Скорее всего вопросы будут более узкие, чем “Design Google Search”. Просто потому, что это очень большой вопрос, а интервью – 45 минут. И за эти 45 минут вы, в лучшем случае, разберетесь какие там есть основные компоненты и как они взаимодействуют. Вряд ли больше. А вот какая-то конкретная часть Google Search – например, кеш – уже вполне имеет смысл.
2) Скорее всего вопросы будут довольно общие. Не “Design Google Talk”, а “Design a messenger”. Просто потому, что не все пользуются Google Talk, и интервьюер вряд ли будет хотеть объяснять, что это такое и чем оно отличается от другого продукта, с которым кандидат хорошо знаком.
3) Возможно, вопрос будет из опыта интервьюера. Вот я ничего не знаю про Search Crawl, например. Я могу придумать кучу всего, но я понятия не имею насколько мои идеи правильные, и нет ли в них чего-то, чего я не учла. И я понимаю, что вряд ли я смогу оценить очень хорошего кандидата по достоинству в этой области (плохих смогу, думаю). Поэтому если я буду интервьюировать опытного кандидата, я ему этот вопрос задавать не буду.
А вот человек, который работал над этим проектом долго, набил все возможные шишки и знает все подводные камни – ему будет очень интересно поговорить об этом. И он реально сможет оценить отличного кандидата – например если тот расскажет о проблеме (и возможностях ее решения), о которой интервьюер в свое время не подумал и из-за этого потерял пару месяцев работы.
4) Задача, вероятно, будет в себе иметь аспект, с которым кандидат хорошо знаком. Например, если у него в резюме есть опыт по “Security”, то, возможно, часть задачи будет хранение данных под грифом “Максимально секретно” или создании системы для банка.
Как отвечать на вопрос?
Тут все зависит от интервьюера, но если бы интервьюировала я, то я бы ждала примерно такого:
1) Важно иметь план в голове – о чем вообще нужно подумать? Я давала примерный список в первой части, но его можно сократить.
2) Важно упомянуть все ключевые части. В очень широких и неконкретных вопросах – а вопросы на архитектуру именно такие – очень просто застрять на какой-то одной детали. Постарайтесь не застревать. Но, конечно, если вы видите, что интервьюер явно хочет обсудить ИМЕННО ЭТО, то, конечно, обсуждайте именно это. Но в целом, постарайтесь посмотреть на проблему с разных сторон.
3) От вас ожидается, что тон дискуссии задавать будете вы. Интервьюер, скорее всего, не будет задавать вам вопросов вроде “Меня интересует система, которая будет работать так и так, и будет оптимизирована под это и это, и пользователи у нее будут такие-то”. Как она будет работать и под что она будет оптимизирована скорее всего решать придется вам.
4) Обратную связь тоже неплохо проверять. Только лучше “Я думаю, что будет иметь больший смысл сделать А, потому, что Б. Вы видите тут что-то, что я не учел?”, чем “Как мне стоит сделать Х?”. И не по поводу каждой мелочи, а в более глобальных вопросах.
5) Объясняйте почему то, или иное решение. Не говорите “А данные мы будет хранить в X”. Говорите “Мы можем хранить данные в A, B и С. А имеет такие недостатки, и они сложно преодолимы. В в нашем случае неприменимо, потому что у нас слишком много данных. С мне кажется самым разумным вариантом. Хотя и у него есть такие и сякие недостатки. Но мы можем их обойти так и так. Как думаете?”.
6) Постарайтесь вести именно дискуссию. Интервьюера наверняка знает о задаче намного больше, чем вы. Поэтому ненавязчиво спрашивайте у него обратную связь. При этом учтите, что тон задаете вы, вы просто хотите удостовериться, что ваши идеи, в целом, на верном пути. Тут интервьюер может сказать что-то вроде “Makes sense” или “But what about <X> problem?”. Оба вариата – это хорошо. В первом случае вы знаете, что все ОК, можно продолжать думать в этом направлении дальше. Во втором – это явная подсказка, что вы что-то не учли. Постарайтесь ее учесть, и объяснить как ваше решение справляется с этой проблемой. Или немного поменять решение, чтобы оно ее учитывало тоже.
Как готовиться?
1) Изучать вопросы, которые уже задавались на подобных интервью. Например, тут. Подумайте сами, что вы бы ответили (желательно со своим списком, какие темы нужно затронуть). Погуглите этот вопрос на других сайтах. Например, если поискать на тему “Design autocomplete for booking.com”, то можно найти это. Неплохо для проверки и углубления своих идей.
2) Почитайте статьи и презентации о том, как создавал свои системы Google. Например, это.
И вот это тоже полезно знать. Не точные цифры, а понимание, что есть большая разница между читать данные из памяти, читать данные с диска, или пересылать данные по сети.
3) Погуглите полезные советы. Навскидку – раз, два, три, четыре.
4) Определите ключевые области, которые нужно знать хоть как-то для решения таких задач. И удостоверьтесь, что вы знаете хотя бы базовые вещи. Пример областей – databases, load balancing, networking, RPC, good API, архитектура компьютера… Если вы будете думать о задачах из п.1, то наверняка у вас возникнет много вопросов на тему “А как это делают на самом деле?”. Просто идите за этими вопросами и пытайтесь разобраться в деталях.
5) Еще есть книга на русском Таненбаума – “Распределенные системы“. Я ее давно не читала, но из университетских лет помню, что тогда она мне показалась очень полезной. Необязательно ее всю читать, конечно. Но просмотреть какие проблемы затронуты и как примерно их можно решать будет очень полезно. Например, там есть анализ реальных систем с разных точек зрения. Системы уже давно устарели, но вот анализ почитать будет все равно полезно.
6) И вот еще неплохая книжка.
7) В комментариях к предыдущему посту порекомендовали хороший сайт: highscalability.com
Ну и опять же – чем больше лет опыта у кандидата, тем выше планка ожиданий в вопросах понимания архитектуры систем. Тем более основательно надо готовиться. Это одна из причин, почему я считаю, что чем меньше опыта, тем проще получить оффер.
