Как подготовиться и пройти System Design Interview. Александр Поломодов
ฝัง
- เผยแพร่เมื่อ 14 พ.ย. 2022
- Выступление на конференции ArchDays 2022 archconf.ru/arch
Собеседования в формате System Design Interview становятся все популярнее. Эти собеседования по проектированию проводят как для инженеров, так и для технических менеджеров, а их результаты влияют на оценку итогового уровня кандидата. В этом выступлении я расскажу о том, как подготовиться к таким собеседованиям и как себя проявить с лучшей стороны прямо на нем.
Слайды: archconf.ru/polomodov22
Благодаря таким видео, можно структурировать всю свою экспертизу за 40 минут времени. Это позволит взглянуть на свой опыт со стороны и сделать выводы о дальнейшем развитии.
Выглядит, что данная информация больше нужна middle+, senior специалистам, т.к. только на этом этапе начинаю встречаться задачи которые не в вакууме.
Александр, спасибо за доклад и рекомендации!
Привет, вы слишком все усложнили на всех этапах. Сделано так, что любого можно завалить - вы предлагаете ответить на все эти вопросы за один час; при этом у вас ушло больше часа чтобы объяснить что требуется. Кстати по вашей же схеме оценки Даниил не прошел бы интервью - не все учел, описал систему поверхностно, не прошелся по тому как будут работать юс кейсы, про базы данных вообще написал можно использовать постгрес или монго - как так? Но так как вы работаете вместе - то оценили его высоко - наверняка на собеседовании таких же кандидатов как Даниил отсеивают. Сами готовились к интервью с известной задачей 2 часа. Не совсем понятно, кого вы хотите тогда нанять - условного Джоша Лонга или Сэма Ньюмана. Начинаете морочить голову кандидатам, а сами не очень.
очень круто, спасибо!
Очень крутой доклад, раскладывает всю массу неструктурированных знаний в очень понятный план, как и в роадмапе развития архитекторов. Проводим по вашей методологии интервью по систем дизайну из блога в медиуме, за что огромное вам спасибо!
Спасибо за обратную связь, рад, что вам этот материал помог.
Йфффй
Ййф
Ййй😊фффф😊😊😊
Ф ффм
Еще пара вопросов возникла, не совсем по теме доклада, правда)
1. А можно ли где-то почитать\посмотреть вашу модель ролевую в части технических управленцев и требований к ним? Иерархию управления, грейды.
2. Какие подходы используете для синхронизации команд? Возможно, SAFe, LeSS и т.п., их модификации? И предъявляются ли требования по знаниям этих подходов к претендующим попасть к вам техническим руководителям и архитекторам?
Возможно, я доберусь на Teamlead Conf весной с рассказом как раз про это, так что ответа придется подождать:)
Отлично, было бы крайне интересно)
Мой доклад про то, "Как нанимать технических руководителей" в программе февральского Teamlead Conf
@@AlexanderPolomodov супер, спасибо!
меня всегда удивлял подход к усложнению интервью, а теперь они делают инструкции, что б его пройти, тк навыдумывали кучу этапов, и удивляются че ж нет никого, а по факту задачи будут в перекладывании JSON и тп, сначала Яндекс - теперь Тинек =)
Меня всегда удивляли кандидаты, которые свой опыт с перекладыванием JSON'чиков экстраполируют на работу всех остальных:)
@@AlexanderPolomodov ну я это в общем имею в виду =) Но вообще доклады ваши интересные, но как по мне это усложняет процесс найма, можно и так понять уровень кандидата по 1 интервью. А для остального есть испытательный срок.
@@Qnoize, я не спорю, что процесс найма усложняется, но одновременно его получается выстроить из отдельных шагов и создать пул интервьюеров.
Лет 5 назад в Tinkoff еще не было такого процесса и я сам собеседовал ребят к себе в команды - я брал с собой коллегу, который умел в нужный язык, а дальше мы за полтора часа мы успевали обсудить и язык и подизайнить кусочек системы и за жизнь поговорить. Но по мере роста компании стало ясно, что этот подход плохо масштабируется и не дает стабильного уровня качества при найме - условный Петя может собеседовать классно, а условный Вася нет, в итоге Петя будет нанимать сильных ребят, а Вася каких получится. Для решения этих вопросов мы и пришли к тому процессу найма, что у нас есть сейчас
В этом году начал серьезно прокачивать все эти доп. секции для прохождения интервью и было очень смешно увидеть такой момент - в Яндексе многоэтапные собеседования с кучей всякой теории (многое из которой не так уж часто и пригождается), но при этом всем в их системах очень часто не хватает банальных вещей - фильтры списков, возможность сортировки по различным полям, контроль над собственным кабинетом.
И после этого у меня возникло ощущение, что все эти доп. секции все же по большей мере - трата времени на этапах прохождения собеседований.
Если в реальном проекте у вас проектированием занимаются только сеньоры - в компании есть серьезные проблемы. Обычно для такого минимум нужны ведущие разработчики + архитектор + devOps.
Это связано с тем, что разработчик не обязан следить за каждым обновлением инструментария у devOps отдела, devOps не должен сильно задумываться как внутри работает код на ЯП, которого он не знает, а у архитектора всегда будет несколько более широкий взгляд на систему и часто опыт с других проектов.
И это нормально - в этом нет ничего плохого.
P.S. и при всех этих доп. секциях системы Яндекса нередко отстают в функционале и имеют критические ошибки в проде - это ли не флаг, что все эти усложненные интервью не всегда имеют смысл?
Классика, чистенький архитектор, рисующий квадратики да читающий книжки по работе, учит жизни простого работягу, разгружающего вагоны с джейсончиками 8 часов в день😂 еслиб на собесе реально надо было уровень кандидата проверить, а не чсв потешить, то спрашивали бы тест на iq - найдите закономерность и допишите этот легаси код 😂 и какие нить детективные задачки - найдите по логам где ошибка 😅 . Конечно большой вопрос зачем тогда вообще архитекторы нужны в конторе, если требования для разработчика - быть архитектором. Контора архитекторов, а работать некому. У семи архитекторов формочка без валидации😂
Александр, спасибо за систематизацию знаний и здесь и в других выступлениях, очень просто о сложном. У меня всегда не хватает административной составляющей для систематизации знаний, а тут за 40 минут паттерн проектирования, который можно отдать ребятам для изучения точек входа. Единственное, чтобы добавил сюда, что архитектор должен еще знать НПА в смежных областях, особенно в нашем государстве, ведь можно сделать систему, а потом понять, что она вне закона, а никто кроме архитектора не мог подсказать об этом. У меня есть предположения где в Тинькофф (и не только) это упустили, но возможно вы это заложили в risk management или договор с клиентом, так как иногда это можно покрыть просто успешностью системы.
Спасибо за обратную связь.
Насчет юридических вопросов или рисков в целом - это хороший point. В рамках больших проектов у нас такая проработка конечно есть, но пытаться проверить это на system design interview было бы сложно - времени бы точно не хватило:)
Интересно, что скрывается за техническими грейдами "senior+" и как распределяются задачи по проектированию между архитекторами и ведущими/старшими разработчиками?
Нет грейда senior+. Есть Senior, есть lead. А вот эти все плюсы определяют лишь зарплатную вилку, в которую попадает конкретный инженер. В одной и той же компании разница между ЗП senior инженеров может быть значительной. Для примера, в моей организации мидл, который только получил серьера получает 2000$, а сеньер, который метит в лиды - уже ~3500$, новый лид - 4000, лид с большим опытом 10-12к$ А архитекторы - это вообще другая история. Архитекторы кодят крайне редко. Их задача - расчитывать трудозатраты и делать оценки по времени на реализацию проекта, писать тех требования по проектам и валидировать, делать аудит существующих систем на предмет переработки дизайна и архитектуры и т.д.
Полезная информация, но докладчику нужно бороться со словами-паразитами «воооот». Публичное выступление все же.
Все мы люди и важно, что человек готов делиться опытом и знаниями, а не то, насколько профессионально он проводит публичные выступления, с точки зрения каких-то корпоративных правил. На сегодняшний день, даже крупные компании идут к тому, чтобы быть ближе к публике и проводить выступления на максимально близком к аудитории уровне. Ты не меряешься письками со своей аудиторией и пытаешься удивить снобов, а, в первую очередь, пытаешься поделиться какими-то полезными практиками с единомышленниками
Какое отношение алгоритмы имеют к эффективному хранению, быстрому чтению из БД и какие алгоритмы вы бы использовали?
10/10
Эх, а я еще ни разу до интервью в Тиньке не дошел, теперь понятно почему, нужно десяток скилов прокачать. Правда это не помешало в свое время найти несколько багов в бизнесовом кабинете.
Спасибо, порекомендуйте пожалуйста книжку. Хофф, это автор. А название, год выпуска и т.д.
Шаблоны интеграции корпоративных приложений
А есть ссылка на то интервью с Даниилом, про которое идет речь в докладе ?
Скоро будет. Оно в рамках этой же конференции было, но на часа четыре раньше.
@@AlexanderPolomodov отлично, буду ждать! Вообще вам большое спасибо за то, что вы делаете! Сейчас с большим удовольствием и интересом изучаю ваши материалы
Опубликовали интервью th-cam.com/video/Wh5Ya6UFG1k/w-d-xo.html
@@AlexanderPolomodov Спасибо за доклад!
Подскажите пожалуйста, вы вроде упоминали про то что и у фронтенда есть систем дизайн интервью, но не очень понятно что он включает.
С системным дизайном для бекендщиков все понятно и ты видишь какой-то путь, чтобы вырасти в архитектора, но у фронтенда это все в каком-то тумане и сильно зависит от компании (в основном ты просто крафтишь компоненты и перекрашиваешь кнопки). Я довольно долго варюсь в этом и вижу только путь развития в тимлида из сеньера фронта (а в менеджмент не хочется), либо свичится в бек на N лет и потом идти в архитекторы (это какой-то титанический труд с большим риском).
Если поделитесь опытом, было бы интересно! Спасибо.
@@exslims1, спасибо за обратную связь и вопрос. Да, у нас для фронтенд разработчиков есть свое интервью по Web Architecture, в котором фокус на проектирование сложного фронтенд приложения с определенными требованиями по получению и отправке данных и компонентной структурой на фронте. Подробнее, возможно, расскажут мои коллеги на одной из конференций, так как я хоть и поспособствовал появлению такого интервью у них, но дальше не сильно погружался в происходящее там.
От системных аналитиков уровня сеньор уровня требуют system design?
Если они идут по треку системных аналитиков, то нет. У них другой набор интервью и туда System Design не входит
Александр, а мне вот интересно, откуда берется такая дискриминация ролей бизнес и системный анализ.
А по какой причине они «не могут в системный дизайн» ?
Я не знаю, какие требования в Тиньков к тому, что люди из указанных ролей должны прорабатывать на этапе входа в проект. Но, как мне видится, достаточно не мало информации , которая подпадает под категории системного дизайна , КАЧЕСТВЕННО прорабатывается людьми из этих ролей. Если у них есть интерес к повышению компетенции в системном дизайне, по какой причине это не может быть востребовано в компании? Если в компании пытаются сделать абстрактных инженеров, которые «могут и в системный дизайн, и в разработку , и тд», то чем аналитики хуже?
Для того, чтобы разобраться (и уметь) в системном дизайне, не надо быть разработчиком, надо уметь грамотно подбирать паттерны архитектурные (сеть, интеграция, безопасность,…) в зависимости от задачи.
И практиковать это по возможности.
И проектировать (в идеале) приложение так, чтобы через пару лет не пришлось все переделывать.
Где здесь разработка ?
как часто выбирают либы на старте приложения ?
Либо это делают чуть позже, если там какой-то экзотический случай.
Как часто проектируют какие-то особенные структуры данных на этапе проектирования глобального ? Не видел ни разу (да, это субъективно).
С учетом специфики системного дизайна, каждая из обсуждаемых ролей имеет равные шансы на то, чтобы растить компетенцию эту себе, так как они смотрят на продукт с разных сторон. Не вижу, почему это не так.
Не забывайте, есть аналитики (бизнес в тч), которые могут код на бумажке написать не хуже обычного разраба.
И да, их майндсет остается аналитическим. Хотя, если потребуется, они могут переключиться в другую роль.
Хотел узнать как проходить system design интервью за час. В итоге добавил к списку книг 7 и понял, что готовиться надо с месяца три 😂
Мне кажется вы путаете поток исполнения и диаграммы потоков данных в 4 пункте статьи / доклада. Диаграммы потока данных это вполне конкретная диаграмма в одной из нотаций. en.wikipedia.org/wiki/Data-flow_diagram. То о чем вы говорите это просто execution flow, который наиболее проще показать на sequence диаграмме или на какой-то более абстрактной диаграмме, но уж точно не data flow diagram - которая используется для рисования обзорной картинки потоков данных между системами в различных ETL процессах. Но уж точно на DFD не будет детализации какой запрос POST посылает пользователь. Главный фокус DFD это узлы между которыми перетекают данные и направление потока, но не детали данных.
Мда... это точно просистем дизайн? Есть вполне конкретная система. Начинаем с ... интеграции? Какие протоколы, контракты, какой балансировщик? Вы систему вообще хоть както описали, там точно баланстровщик нужен?
Кандидаты в в архитекторы уровня солюшн тоже проходят у вас секцию алгоритмов и языковую?
Да
@@AlexanderPolomodov почему так? Архитектор должен выйти из кодинга или уметь в?
@@Akimkooo а как по другому, нужны практики, а не теоретики... Так как весь дьявол в деталях
@@Akimkooo, мы считаем, что люди, которые не умеют писать код и не знакомы с промышленной разработкой, а умеют только рисовать квадратики и стрелочки, не слишком нам интересны в роли архитектора.
@@AlexanderPolomodovмного они потом пишут код в роли архитектора или рисуют квадратики?
почему бы не заниматься проектированием ютубов доставок и твиттеров, а вместо этого заранее уточнить какая именно подсистема проектируется
в целом это странный формат пытаться за час решить то, что в реальных условиях делается неделю две, а то и дольше ну что этот навык покажет? никакой связи с реальными задачами это не имеет
если хочется понять кругозор человека и как он умеет формулировать свои мысли и задавать вопросы, то можно совсем иначе же построить интервью
Вооот
Если у вас есть час свободного времении, послушать бесконечные "Вот вот вот вот и воооот" где ведущий нарисует себя самым умными и видимо самым красивым, посоветует крутые книжечки "которые он сам читал" и еще много много воды о не о чём и подкинет пару скупых крошек по теме этого видео, то прошу к экрану.
... воот
Т.е. чувачок на интервью должен сам догадаться, что вы ждете, что он спросит, что можно опустить некоторые реализации, вроде авторизации и хранения каких-то данных?
Понимаю, кончи кончами. Ставьте нормально задачу на интервью и будете получать нормальный результат, а не сидеть с кривой миной, что чел не догадался о ваших влажных фантазиях, а потом говорить ему "ты не прошел".
Согласен, дегенераты придумывают какую-то идиотию с бредовыми целями, а потом преподносят это как инновационный подход. Нашли с кого брать пример, с гавнояндекса
ты всё правильно понял. этот этап нужен чтобы сказать человеку "ты не прошёл" или "ты фигово прошёл" и предложить ему меньше денег. даже в этом видео видно что докладчик давн и понятия не имеет о чём говорит, с таким же успехом чатгпт мог бы выступить.
Вооооооооот
Какие-то психологические игры. В своих ответах ясно пояснил, что почва под этим процессом непрочная и больше, всё-таки, основана на субъективном восприятии.
Смотрю доклад и вижу, есть 100500 книжек, их хорошо бы изучить все, потом можете попробовать к нам прийти.
ппц душнила
вот
Use case нету в UML!!!!!
Для того, чтобы проверить ложность этого утверждения стоит заглянуть в последний стандарт UML 2.5.1 от декабря 2017 года и найти описание Use Cases в части 18. А дальше почитать с б39 страницы по 652 страницу о том, что это такое и как этим пользоваться
Невозможно слушать. Неструктурированная каша из мыслей.