Comments 16
В идеале нужно собрать основные требования и ограничения так что ответ будет очевиден
C нуля до проектирования систем уровня senior-инженера
5 000 ₽
Надо брать!
устроены популярные системы (YouTube, Uber, WhatsApp)
Я б посмотрел, но кто ж мне даст?
Когда я готовился к собеседованию в Амазон, то искал материал и находил видео с митапов от Uber, Twitter, Meta как у них устроена архитектуры, так что это не секрет, крупные компании любят делится такими знаниями на конференциях и митапах.
P.S. на интервью мне попался Netflix, сервис, который я никогда в жизни не видел (только слышал)
Хотелось бы поделиться своим мнением по System Design и собеседовании.
Если вы не трогали и не погоняли как следует на тех или иных технологиях (Redis, Kafka, конкретный CDN, конкретные движки БД etc.) то вам скорее всего не пройти System Design Interview. Пройти какой-нибудь курс и прочитать пару книг и статей не достаточно. На практике нужно не просто знать какую задачу решает та или иная технология плюсы и минусы, а довольно хорошо разбираться в деталях и знать конкретные показетели производительности. Где, сколько и что можно сделать, и на каком оборудовании. При этом я лично считаю, что это не значит, что вы не сможете вытянуть нормальную архитектуру в боевых условиях. Т.е. не очень понятно как это помогает собеседующему выбрать более ценного кандидата. Это интервью сравнимо с решением задачек с leetcode.
На практике не так уж и много проектов, где, во-первых, это всё надо, а, во-вторых, ещё и сразу. Большинство не стартует что-то для миллионов пользователей или какой-то невероятной нагрузки, ни в уже существующем проекте, ни в новом. Всё вводится постепенно. При этом сначала бизнес ещё не знает, что именно ценно и нужно. Закинув сразу кучу технологий вы только добавите себе же работы по отладке, поддержке всяких проблемных случаев в архитектуре и логике, переделыванию, тестированию и дальнейшей поддержке. Даже просто запустите только через пол года первую бета версию, вместо того, чтобы что-то запустить через месяц, и потом ещё одну две версии в продакшене.
В тех же случаях, где реально надо сразу на миллионы, просто возьмут проверенных людей с других похожих проектов или вообще сами проекты перепрофилируют. Никто не будет собеседовать в духе https://github.com/donnemartin/system-design-primer.
Уверен, что WhatsApp, YouTube, Dropbox etc уже больше чем два раза переосмыслили и переписали места, которые реально требовали внимания. При этом спокойно могут работать на одном или паре инстансов того, что большинство будет пытаться "масштабировать" во время интервью. Они, конечно, могут написать об этом в блогах и рассказать на конференциях, но совсем не факт, что у вас будут те же самые проблемы, особенно в начале.
Мне кажется это больше защита от дурака, как ответ на курсы, завышение скиллов в резюме, гпт.
Вообщем чтобы понять, человек действительно понял инструмент и тыкал его, или просто заучил ответы на часто задаваемые вопросы на собеседовании.
Добрый день. Спасибо за комментарий.
Вы правы, задачи на собеседовании и не только по System Design в большинстве случаев мало схожи с реальностью. Например в Т Банке собес по System Design для системных аналитиков это промежуточный этап отбора, на который выделяется 1.5 часа плотной работы с интервьюером. Там вас спросят обо всем. Я когда приходишь на проект, там вялотекущее развитие архитектуры в течении нескольких кварталов, причем как правило за это вообще отвечает Solution architect и приходится просто писать ФТ и НТ. Также и во всем финтехе.
Но если подумать, когда на 1 позицию метит N человек, вам приходится выбирать и для того, чтобы разметить поле выбора приходится вводить всякие новые этапы собеседований и безумные задания. System Design олицетворяет фундамент IT - как создается то или иное приложение, система и тд. Знание основ, базовых технологий и принципов снимает риск, что кандидат после принятия оферта будет балластом.
Естественно тут мы говорим только про hard skills, и не упоминаем что неопытный кандидат может на своих Soft Skills и упорстве оперативно во всем разобраться и стать ключевым звеном в команде (Это слишком непрозрачно на этапе собеседования). Но Харды проверяются легче софтов, поэтому на собеседовании есть этап с System Design.
Вы правы, задачи на собеседовании и не только по System Design в большинстве случаев мало схожи с реальностью.
Знание основ, базовых технологий и принципов снимает риск, что кандидат после принятия оферта будет балластом.
Похоже, пора обратно возвращать задачки на знание и понимание формальной логики.
Но если подумать, когда на 1 позицию метит N человек, вам приходится выбирать и для того, чтобы разметить поле выбора приходится вводить всякие новые этапы собеседований и безумные задания.
Вы ищете отличника, который ответит на все ваши вопросы и решит все задачки, которые в работе никогда не встречаются или рабочую лошадку, которая будет таски делать?
В чем суть такого извращения при найме? Выглядит так, что hr хочет найти олимпиадника, при этом тратя ресурсы работодателя в погоне за идеальным кандидатом и желательно как можно дешевле в зп.
По моим ощущениям систем дизайн интервью это сплошное лицемерие и карго культ. Ещё хуже чем ли код задачи или техническое интервью. Задачи хотя бы проверяют определенную объективно существующую натренированность ума. А понимание множества технических деталей говорит об опыте и инженерных способностях.
Дизайн интервью теоретически должно проверять способность к проектированию систем и знание существующих решений. Но в реальности подобный опыт крайне редок и мало востребован. В лучшем случае человек сталкивался на практике с частными ограничениями одного двух продуктов, про которые может сейчас уже все забыли. В итоге никто не имеет реального проверенного на практике опыта проектирования Фейсбука с нуля за 10 минут, но на интервью изображает что он у него есть, выбирая "правильные" ответы на вопросы. И побеждает не хороший инженер а лучший адепт культа.
Печалька еще в том, что велосипедостроение считается минусом, но именно так практически все методики и распространенные продукты появились.
Когда-то вокруг были сплошные велосипедисты, из которых и вырастали толковые архитекторы, набившие шишки на ошибках и на каждом шагу говорившие, что наше решение не факт, что подойдёт вам. Слишком много "если" в уравнениях.
А сейчас вся айтишечка лишена права на ошибку карго-культистами.
Почему собеседования по System Design такие сложные?
Потому что нужно угадать, как именно маршируют тараканы в голове у собеседующего. А с телепатией, как известно, у людей сложно:
Например, кандидат слышит «Спроектируйте VK»
Если у вас 1000 пользователей, Kafka — это overkill
У VK 1000 пользователей? Или по какой причине тараканы возбудились на Кафку?
В реальном проекте вы бы сначала оценили нагрузку.
В реальном проекте архитектура не строится за 30 минут.
Грустно это все.
Приходит сеньер на вакансию:
Алгоритмическая секция
Лайвкодинг
Систем дизайн
А на выходе:
Уровень влияния на архитектуру зависит от бюрократии в компании и самодурства ведущего аналитика
Будете укладывать джейсоны для клиентской части
Живите с этим...
На мой взгляд интервью должно соотвествовать. Именно поэтому, все больше, в компании попадают через знакомых. Проще процесс собеседования и, как правило, это уже проверенные люди.
Так что продолжайте накручивать собеседования, и будет вам в итоге накрутка резюмех. Это вечные крысиные бега
"как вы можете выбрать между монолитом и микросервисами?"
Даже выбирать не буду. Сразу модульный монолит. Микросервисы хороши только для докладов на симпозиумах.
Если обоснуете это выбор исходя из требований и опыта, почему бы и нет.
Микросервисы хороши только для докладов на симпозиумах.
При этом почему-то много компаний работают с микросервисами и или приходят к ним, значит микросервисная архитектура вполне имеет право на существование.
Есть один кейз, когда микросервисы работают. Правда для этого им не нужно быть сильно микро. Этот кейз когда продукт слишком большой и каждое изменение требует парализующе сложного взаимодействия команд. Тогда выделение в продукте микросервисов, каждый из которых полностью автономен - своя база, почти свой UI, свой доменный контекст решает эту организационную проблему.
Как провалить собеседование по System Design: ошибки, которые допускают даже опытные разработчики