Как подготовиться и пройти System Design Interview. Александр Поломодов

Выступление на конференции ArchDays 2022 archconf.ru/arch
Собеседования в формате System Design Interview становятся все популярнее. Эти собеседования по проектированию проводят как для инженеров, так и для технических менеджеров, а их результаты влияют на оценку итогового уровня кандидата. В этом выступлении я расскажу о том, как подготовиться к таким собеседованиям и как себя проявить с лучшей стороны прямо на нем.
Слайды: archconf.ru/polomodov22

[@dobriykote]

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

[@filippt9304]

очень круто, спасибо!

[@Nodorgrom]

Благодаря таким видео, можно структурировать всю свою экспертизу за 40 минут времени. Это позволит взглянуть на свой опыт со стороны и сделать выводы о дальнейшем развитии. Выглядит, что данная информация больше нужна middle+, senior специалистам, т.к. только на этом этапе начинаю встречаться задачи которые не в вакууме. Александр, спасибо за доклад и рекомендации!

[@sergeykutylev8891]

Очень крутой доклад, раскладывает всю массу неструктурированных знаний в очень понятный план, как и в роадмапе развития архитекторов. Проводим по вашей методологии интервью по систем дизайну из блога в медиуме, за что огромное вам спасибо!

[@AlexanderPolomodov]

Спасибо за обратную связь, рад, что вам этот материал помог.

[@user-cz1iz7wt4s]

Йфффй

[@user-cz1iz7wt4s]

Ййф

[@user-cz1iz7wt4s]

Ййй😊фффф😊😊😊

[@user-cz1iz7wt4s]

Ф ффм

[@ealeykin]

Какое отношение алгоритмы имеют к эффективному хранению, быстрому чтению из БД и какие алгоритмы вы бы использовали?

[@minmanr]

Интересно, что скрывается за техническими грейдами "senior+" и как распределяются задачи по проектированию между архитекторами и ведущими/старшими разработчиками?

[@maksimbondarenko1179]

Нет грейда senior+. Есть Senior, есть lead. А вот эти все плюсы определяют лишь зарплатную вилку, в которую попадает конкретный инженер. В одной и той же компании разница между ЗП senior инженеров может быть значительной. Для примера, в моей организации мидл, который только получил серьера получает 2000$, а сеньер, который метит в лиды - уже ~3500$, новый лид - 4000, лид с большим опытом 10-12к$ А архитекторы - это вообще другая история. Архитекторы кодят крайне редко. Их задача - расчитывать трудозатраты и делать оценки по времени на реализацию проекта, писать тех требования по проектам и валидировать, делать аудит существующих систем на предмет переработки дизайна и архитектуры и т.д.

[@aleksey2793]

Еще пара вопросов возникла, не совсем по теме доклада, правда) 1. А можно ли где-то почитать\посмотреть вашу модель ролевую в части технических управленцев и требований к ним? Иерархию управления, грейды. 2. Какие подходы используете для синхронизации команд? Возможно, SAFe, LeSS и т.п., их модификации? И предъявляются ли требования по знаниям этих подходов к претендующим попасть к вам техническим руководителям и архитекторам?

[@AlexanderPolomodov]

Возможно, я доберусь на Teamlead Conf весной с рассказом как раз про это, так что ответа придется подождать:)

[@aleksey2793]

Отлично, было бы крайне интересно)

[@AlexanderPolomodov]

Мой доклад про то, "Как нанимать технических руководителей" в программе февральского Teamlead Conf

[@aleksey2793]

@@AlexanderPolomodov супер, спасибо!

[@user-ex4ll1ky4r]

Полезная информация, но докладчику нужно бороться со словами-паразитами «воооот». Публичное выступление все же.

[@oOSwiMmOo]

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

[@Qnoize]

меня всегда удивлял подход к усложнению интервью, а теперь они делают инструкции, что б его пройти, тк навыдумывали кучу этапов, и удивляются че ж нет никого, а по факту задачи будут в перекладывании JSON и тп, сначала Яндекс - теперь Тинек =)

[@AlexanderPolomodov]

Меня всегда удивляли кандидаты, которые свой опыт с перекладыванием JSON'чиков экстраполируют на работу всех остальных:)

[@Qnoize]

@@AlexanderPolomodov ну я это в общем имею в виду =) Но вообще доклады ваши интересные, но как по мне это усложняет процесс найма, можно и так понять уровень кандидата по 1 интервью. А для остального есть испытательный срок.

[@AlexanderPolomodov]

@@Qnoize​, я не спорю, что процесс найма усложняется, но одновременно его получается выстроить из отдельных шагов и создать пул интервьюеров. Лет 5 назад в Tinkoff еще не было такого процесса и я сам собеседовал ребят к себе в команды - я брал с собой коллегу, который умел в нужный язык, а дальше мы за полтора часа мы успевали обсудить и язык и подизайнить кусочек системы и за жизнь поговорить. Но по мере роста компании стало ясно, что этот подход плохо масштабируется и не дает стабильного уровня качества при найме - условный Петя может собеседовать классно, а условный Вася нет, в итоге Петя будет нанимать сильных ребят, а Вася каких получится. Для решения этих вопросов мы и пришли к тому процессу найма, что у нас есть сейчас

[@eugenteris]

В этом году начал серьезно прокачивать все эти доп. секции для прохождения интервью и было очень смешно увидеть такой момент - в Яндексе многоэтапные собеседования с кучей всякой теории (многое из которой не так уж часто и пригождается), но при этом всем в их системах очень часто не хватает банальных вещей - фильтры списков, возможность сортировки по различным полям, контроль над собственным кабинетом. И после этого у меня возникло ощущение, что все эти доп. секции все же по большей мере - трата времени на этапах прохождения собеседований. Если в реальном проекте у вас проектированием занимаются только сеньоры - в компании есть серьезные проблемы. Обычно для такого минимум нужны ведущие разработчики + архитектор + devOps. Это связано с тем, что разработчик не обязан следить за каждым обновлением инструментария у devOps отдела, devOps не должен сильно задумываться как внутри работает код на ЯП, которого он не знает, а у архитектора всегда будет несколько более широкий взгляд на систему и часто опыт с других проектов. И это нормально - в этом нет ничего плохого. P.S. и при всех этих доп. секциях системы Яндекса нередко отстают в функционале и имеют критические ошибки в проде - это ли не флаг, что все эти усложненные интервью не всегда имеют смысл?

[@redkostia]

Классика, чистенький архитектор, рисующий квадратики да читающий книжки по работе, учит жизни простого работягу, разгружающего вагоны с джейсончиками 8 часов в день😂 еслиб на собесе реально надо было уровень кандидата проверить, а не чсв потешить, то спрашивали бы тест на iq - найдите закономерность и допишите этот легаси код 😂 и какие нить детективные задачки - найдите по логам где ошибка 😅 . Конечно большой вопрос зачем тогда вообще архитекторы нужны в конторе, если требования для разработчика - быть архитектором. Контора архитекторов, а работать некому. У семи архитекторов формочка без валидации😂

[@vladimireliseev7602]

Спасибо, порекомендуйте пожалуйста книжку. Хофф, это автор. А название, год выпуска и т.д.

[@uivadim]

Шаблоны интеграции корпоративных приложений

[@user-zf7kr6vn1t]

А есть ссылка на то интервью с Даниилом, про которое идет речь в докладе ?

[@AlexanderPolomodov]

Скоро будет. Оно в рамках этой же конференции было, но на часа четыре раньше.

[@user-zf7kr6vn1t]

@@AlexanderPolomodov отлично, буду ждать! Вообще вам большое спасибо за то, что вы делаете! Сейчас с большим удовольствием и интересом изучаю ваши материалы

[@archdays]

Опубликовали интервью kzbin.info/www/bejne/jZmYipRsiqt6Z80

[@exslims1]

@@AlexanderPolomodov Спасибо за доклад! Подскажите пожалуйста, вы вроде упоминали про то что и у фронтенда есть систем дизайн интервью, но не очень понятно что он включает. С системным дизайном для бекендщиков все понятно и ты видишь какой-то путь, чтобы вырасти в архитектора, но у фронтенда это все в каком-то тумане и сильно зависит от компании (в основном ты просто крафтишь компоненты и перекрашиваешь кнопки). Я довольно долго варюсь в этом и вижу только путь развития в тимлида из сеньера фронта (а в менеджмент не хочется), либо свичится в бек на N лет и потом идти в архитекторы (это какой-то титанический труд с большим риском). Если поделитесь опытом, было бы интересно! Спасибо.

[@AlexanderPolomodov]

@@exslims1, спасибо за обратную связь и вопрос. Да, у нас для фронтенд разработчиков есть свое интервью по Web Architecture, в котором фокус на проектирование сложного фронтенд приложения с определенными требованиями по получению и отправке данных и компонентной структурой на фронте. Подробнее, возможно, расскажут мои коллеги на одной из конференций, так как я хоть и поспособствовал появлению такого интервью у них, но дальше не сильно погружался в происходящее там.

[@skayrton]

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

[@AlexanderPolomodov]

Спасибо за обратную связь. Насчет юридических вопросов или рисков в целом - это хороший point. В рамках больших проектов у нас такая проработка конечно есть, но пытаться проверить это на system design interview было бы сложно - времени бы точно не хватило:)

[@GeorgiyRyabov]

10/10

[@oldzas]

От системных аналитиков уровня сеньор уровня требуют system design?

[@AlexanderPolomodov]

Если они идут по треку системных аналитиков, то нет. У них другой набор интервью и туда System Design не входит

[@sergeyk.1808]

Александр, а мне вот интересно, откуда берется такая дискриминация ролей бизнес и системный анализ. А по какой причине они «не могут в системный дизайн» ? Я не знаю, какие требования в Тиньков к тому, что люди из указанных ролей должны прорабатывать на этапе входа в проект. Но, как мне видится, достаточно не мало информации , которая подпадает под категории системного дизайна , КАЧЕСТВЕННО прорабатывается людьми из этих ролей. Если у них есть интерес к повышению компетенции в системном дизайне, по какой причине это не может быть востребовано в компании? Если в компании пытаются сделать абстрактных инженеров, которые «могут и в системный дизайн, и в разработку , и тд», то чем аналитики хуже? Для того, чтобы разобраться (и уметь) в системном дизайне, не надо быть разработчиком, надо уметь грамотно подбирать паттерны архитектурные (сеть, интеграция, безопасность,…) в зависимости от задачи. И практиковать это по возможности. И проектировать (в идеале) приложение так, чтобы через пару лет не пришлось все переделывать. Где здесь разработка ? как часто выбирают либы на старте приложения ? Либо это делают чуть позже, если там какой-то экзотический случай. Как часто проектируют какие-то особенные структуры данных на этапе проектирования глобального ? Не видел ни разу (да, это субъективно). С учетом специфики системного дизайна, каждая из обсуждаемых ролей имеет равные шансы на то, чтобы растить компетенцию эту себе, так как они смотрят на продукт с разных сторон. Не вижу, почему это не так. Не забывайте, есть аналитики (бизнес в тч), которые могут код на бумажке написать не хуже обычного разраба. И да, их майндсет остается аналитическим. Хотя, если потребуется, они могут переключиться в другую роль.

[@aleksey2793]

Кандидаты в в архитекторы уровня солюшн тоже проходят у вас секцию алгоритмов и языковую?

[@AlexanderPolomodov]

Да

[@Akimkooo]

@@AlexanderPolomodov почему так? Архитектор должен выйти из кодинга или уметь в?

[@skayrton]

@@Akimkooo а как по другому, нужны практики, а не теоретики... Так как весь дьявол в деталях

[@AlexanderPolomodov]

@@Akimkooo, мы считаем, что люди, которые не умеют писать код и не знакомы с промышленной разработкой, а умеют только рисовать квадратики и стрелочки, не слишком нам интересны в роли архитектора.

[@user-wp3kd7gd3j]

​@@AlexanderPolomodovмного они потом пишут код в роли архитектора или рисуют квадратики?

[@user-yt1tn1pb8c]

Хотел узнать как проходить system design интервью за час. В итоге добавил к списку книг 7 и понял, что готовиться надо с месяца три 😂

[@suniverse9000]

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

[@pavelpavel7938]

Мда... это точно просистем дизайн? Есть вполне конкретная система. Начинаем с ... интеграции? Какие протоколы, контракты, какой балансировщик? Вы систему вообще хоть както описали, там точно баланстровщик нужен?

[@dobriykote]

Мне кажется вы путаете поток исполнения и диаграммы потоков данных в 4 пункте статьи / доклада. Диаграммы потока данных это вполне конкретная диаграмма в одной из нотаций. en.wikipedia.org/wiki/Data-flow_diagram. То о чем вы говорите это просто execution flow, который наиболее проще показать на sequence диаграмме или на какой-то более абстрактной диаграмме, но уж точно не data flow diagram - которая используется для рисования обзорной картинки потоков данных между системами в различных ETL процессах. Но уж точно на DFD не будет детализации какой запрос POST посылает пользователь. Главный фокус DFD это узлы между которыми перетекают данные и направление потока, но не детали данных.

[@DmitryRandom]

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

[@sattamassagana4193]

Вооооооооот

[@anatolyshaulsky6098]

Если у вас есть час свободного времении, послушать бесконечные "Вот вот вот вот и воооот" где ведущий нарисует себя самым умными и видимо самым красивым, посоветует крутые книжечки "которые он сам читал" и еще много много воды о не о чём и подкинет пару скупых крошек по теме этого видео, то прошу к экрану.

[@user-jx8jl7nc3j]

Какие-то психологические игры. В своих ответах ясно пояснил, что почва под этим процессом непрочная и больше, всё-таки, основана на субъективном восприятии.

[@RomanAlexandrov]

Смотрю доклад и вижу, есть 100500 книжек, их хорошо бы изучить все, потом можете попробовать к нам прийти.

[@margaritasato1365]

Вооот

[@Levelord92]

... воот

[@user-hp2cg6px8c]

Т.е. чувачок на интервью должен сам догадаться, что вы ждете, что он спросит, что можно опустить некоторые реализации, вроде авторизации и хранения каких-то данных? Понимаю, кончи кончами. Ставьте нормально задачу на интервью и будете получать нормальный результат, а не сидеть с кривой миной, что чел не догадался о ваших влажных фантазиях, а потом говорить ему "ты не прошел".

[@user-md5xb9ie1i]

Согласен, дегенераты придумывают какую-то идиотию с бредовыми целями, а потом преподносят это как инновационный подход. Нашли с кого брать пример, с гавнояндекса

[@pavelsachkov4471]

вот

[@user-kq8nk5vj5r]

ппц душнила

[@oldzas]

Use case нету в UML!!!!!

[@AlexanderPolomodov]

Для того, чтобы проверить ложность этого утверждения стоит заглянуть в последний стандарт UML 2.5.1 от декабря 2017 года и найти описание Use Cases в части 18. А дальше почитать с б39 страницы по 652 страницу о том, что это такое и как этим пользоваться

[@Loutistic]

Невозможно слушать. Неструктурированная каша из мыслей.