Как подготовиться и пройти System Design Interview. Александр Поломодов
Вставка
- Опубліковано 27 вер 2024
- Выступление на конференции ArchDays 2022 archconf.ru/arch
Собеседования в формате System Design Interview становятся все популярнее. Эти собеседования по проектированию проводят как для инженеров, так и для технических менеджеров, а их результаты влияют на оценку итогового уровня кандидата. В этом выступлении я расскажу о том, как подготовиться к таким собеседованиям и как себя проявить с лучшей стороны прямо на нем.
Слайды: archconf.ru/po...
Привет, вы слишком все усложнили на всех этапах. Сделано так, что любого можно завалить - вы предлагаете ответить на все эти вопросы за один час; при этом у вас ушло больше часа чтобы объяснить что требуется. Кстати по вашей же схеме оценки Даниил не прошел бы интервью - не все учел, описал систему поверхностно, не прошелся по тому как будут работать юс кейсы, про базы данных вообще написал можно использовать постгрес или монго - как так? Но так как вы работаете вместе - то оценили его высоко - наверняка на собеседовании таких же кандидатов как Даниил отсеивают. Сами готовились к интервью с известной задачей 2 часа. Не совсем понятно, кого вы хотите тогда нанять - условного Джоша Лонга или Сэма Ньюмана. Начинаете морочить голову кандидатам, а сами не очень.
Все эти собесы приходит из FAANG, а вот зарплаты не приходят:) Кто мне может рассказать зачем сеньору настолько доскональные знания system design? Когда он никогда не сможет принимать решения такого уровня. Ответ один, давайте сделаем собес такой, чтобы никто не мог пройти на 100%, тогда всегда можно срезать ЗП на 100к.
Вот тоже заметил, что в последнее время к сеньорам стали предъявлять требования как к Delivery Manager/Solution Architect/Team Lead и Project Manager, разве что до CTO и СEO не добрались) На мой взгляд, для сеньора достаточно грамотно реализовывать поставленные ему задачи в рамках проекта с применением указанных технологий
Благодаря таким видео, можно структурировать всю свою экспертизу за 40 минут времени. Это позволит взглянуть на свой опыт со стороны и сделать выводы о дальнейшем развитии.
Выглядит, что данная информация больше нужна middle+, senior специалистам, т.к. только на этом этапе начинаю встречаться задачи которые не в вакууме.
Александр, спасибо за доклад и рекомендации!
меня всегда удивлял подход к усложнению интервью, а теперь они делают инструкции, что б его пройти, тк навыдумывали кучу этапов, и удивляются че ж нет никого, а по факту задачи будут в перекладывании JSON и тп, сначала Яндекс - теперь Тинек =)
Меня всегда удивляли кандидаты, которые свой опыт с перекладыванием JSON'чиков экстраполируют на работу всех остальных:)
@@AlexanderPolomodov ну я это в общем имею в виду =) Но вообще доклады ваши интересные, но как по мне это усложняет процесс найма, можно и так понять уровень кандидата по 1 интервью. А для остального есть испытательный срок.
@@Qnoize, я не спорю, что процесс найма усложняется, но одновременно его получается выстроить из отдельных шагов и создать пул интервьюеров.
Лет 5 назад в Tinkoff еще не было такого процесса и я сам собеседовал ребят к себе в команды - я брал с собой коллегу, который умел в нужный язык, а дальше мы за полтора часа мы успевали обсудить и язык и подизайнить кусочек системы и за жизнь поговорить. Но по мере роста компании стало ясно, что этот подход плохо масштабируется и не дает стабильного уровня качества при найме - условный Петя может собеседовать классно, а условный Вася нет, в итоге Петя будет нанимать сильных ребят, а Вася каких получится. Для решения этих вопросов мы и пришли к тому процессу найма, что у нас есть сейчас
В этом году начал серьезно прокачивать все эти доп. секции для прохождения интервью и было очень смешно увидеть такой момент - в Яндексе многоэтапные собеседования с кучей всякой теории (многое из которой не так уж часто и пригождается), но при этом всем в их системах очень часто не хватает банальных вещей - фильтры списков, возможность сортировки по различным полям, контроль над собственным кабинетом.
И после этого у меня возникло ощущение, что все эти доп. секции все же по большей мере - трата времени на этапах прохождения собеседований.
Если в реальном проекте у вас проектированием занимаются только сеньоры - в компании есть серьезные проблемы. Обычно для такого минимум нужны ведущие разработчики + архитектор + devOps.
Это связано с тем, что разработчик не обязан следить за каждым обновлением инструментария у devOps отдела, devOps не должен сильно задумываться как внутри работает код на ЯП, которого он не знает, а у архитектора всегда будет несколько более широкий взгляд на систему и часто опыт с других проектов.
И это нормально - в этом нет ничего плохого.
P.S. и при всех этих доп. секциях системы Яндекса нередко отстают в функционале и имеют критические ошибки в проде - это ли не флаг, что все эти усложненные интервью не всегда имеют смысл?
Классика, чистенький архитектор, рисующий квадратики да читающий книжки по работе, учит жизни простого работягу, разгружающего вагоны с джейсончиками 8 часов в день😂 еслиб на собесе реально надо было уровень кандидата проверить, а не чсв потешить, то спрашивали бы тест на iq - найдите закономерность и допишите этот легаси код 😂 и какие нить детективные задачки - найдите по логам где ошибка 😅 . Конечно большой вопрос зачем тогда вообще архитекторы нужны в конторе, если требования для разработчика - быть архитектором. Контора архитекторов, а работать некому. У семи архитекторов формочка без валидации😂
Полезная информация, но докладчику нужно бороться со словами-паразитами «воооот». Публичное выступление все же.
Все мы люди и важно, что человек готов делиться опытом и знаниями, а не то, насколько профессионально он проводит публичные выступления, с точки зрения каких-то корпоративных правил. На сегодняшний день, даже крупные компании идут к тому, чтобы быть ближе к публике и проводить выступления на максимально близком к аудитории уровне. Ты не меряешься письками со своей аудиторией и пытаешься удивить снобов, а, в первую очередь, пытаешься поделиться какими-то полезными практиками с единомышленниками
Еще пара вопросов возникла, не совсем по теме доклада, правда)
1. А можно ли где-то почитать\посмотреть вашу модель ролевую в части технических управленцев и требований к ним? Иерархию управления, грейды.
2. Какие подходы используете для синхронизации команд? Возможно, SAFe, LeSS и т.п., их модификации? И предъявляются ли требования по знаниям этих подходов к претендующим попасть к вам техническим руководителям и архитекторам?
Возможно, я доберусь на Teamlead Conf весной с рассказом как раз про это, так что ответа придется подождать:)
Отлично, было бы крайне интересно)
Мой доклад про то, "Как нанимать технических руководителей" в программе февральского Teamlead Conf
@@AlexanderPolomodov супер, спасибо!
очень круто, спасибо!
почему бы не заниматься проектированием ютубов доставок и твиттеров, а вместо этого заранее уточнить какая именно подсистема проектируется
в целом это странный формат пытаться за час решить то, что в реальных условиях делается неделю две, а то и дольше ну что этот навык покажет? никакой связи с реальными задачами это не имеет
если хочется понять кругозор человека и как он умеет формулировать свои мысли и задавать вопросы, то можно совсем иначе же построить интервью
Т.е. чувачок на интервью должен сам догадаться, что вы ждете, что он спросит, что можно опустить некоторые реализации, вроде авторизации и хранения каких-то данных?
Понимаю, кончи кончами. Ставьте нормально задачу на интервью и будете получать нормальный результат, а не сидеть с кривой миной, что чел не догадался о ваших влажных фантазиях, а потом говорить ему "ты не прошел".
Согласен, дегенераты придумывают какую-то идиотию с бредовыми целями, а потом преподносят это как инновационный подход. Нашли с кого брать пример, с гавнояндекса
ты всё правильно понял. этот этап нужен чтобы сказать человеку "ты не прошёл" или "ты фигово прошёл" и предложить ему меньше денег. даже в этом видео видно что докладчик давн и понятия не имеет о чём говорит, с таким же успехом чатгпт мог бы выступить.
Если у вас есть час свободного времении, послушать бесконечные "Вот вот вот вот и воооот" где ведущий нарисует себя самым умными и видимо самым красивым, посоветует крутые книжечки "которые он сам читал" и еще много много воды о не о чём и подкинет пару скупых крошек по теме этого видео, то прошу к экрану.
Интересно, что скрывается за техническими грейдами "senior+" и как распределяются задачи по проектированию между архитекторами и ведущими/старшими разработчиками?
Нет грейда senior+. Есть Senior, есть lead. А вот эти все плюсы определяют лишь зарплатную вилку, в которую попадает конкретный инженер. В одной и той же компании разница между ЗП senior инженеров может быть значительной. Для примера, в моей организации мидл, который только получил серьера получает 2000$, а сеньер, который метит в лиды - уже ~3500$, новый лид - 4000, лид с большим опытом 10-12к$ А архитекторы - это вообще другая история. Архитекторы кодят крайне редко. Их задача - расчитывать трудозатраты и делать оценки по времени на реализацию проекта, писать тех требования по проектам и валидировать, делать аудит существующих систем на предмет переработки дизайна и архитектуры и т.д.
Хотел узнать как проходить system design интервью за час. В итоге добавил к списку книг 7 и понял, что готовиться надо с месяца три 😂
Спасибо, порекомендуйте пожалуйста книжку. Хофф, это автор. А название, год выпуска и т.д.
Шаблоны интеграции корпоративных приложений
Мда... это точно просистем дизайн? Есть вполне конкретная система. Начинаем с ... интеграции? Какие протоколы, контракты, какой балансировщик? Вы систему вообще хоть както описали, там точно баланстровщик нужен?
Эх, а я еще ни разу до интервью в Тиньке не дошел, теперь понятно почему, нужно десяток скилов прокачать. Правда это не помешало в свое время найти несколько багов в бизнесовом кабинете.
От системных аналитиков уровня сеньор уровня требуют system design?
Если они идут по треку системных аналитиков, то нет. У них другой набор интервью и туда System Design не входит
Александр, а мне вот интересно, откуда берется такая дискриминация ролей бизнес и системный анализ.
А по какой причине они «не могут в системный дизайн» ?
Я не знаю, какие требования в Тиньков к тому, что люди из указанных ролей должны прорабатывать на этапе входа в проект. Но, как мне видится, достаточно не мало информации , которая подпадает под категории системного дизайна , КАЧЕСТВЕННО прорабатывается людьми из этих ролей. Если у них есть интерес к повышению компетенции в системном дизайне, по какой причине это не может быть востребовано в компании? Если в компании пытаются сделать абстрактных инженеров, которые «могут и в системный дизайн, и в разработку , и тд», то чем аналитики хуже?
Для того, чтобы разобраться (и уметь) в системном дизайне, не надо быть разработчиком, надо уметь грамотно подбирать паттерны архитектурные (сеть, интеграция, безопасность,…) в зависимости от задачи.
И практиковать это по возможности.
И проектировать (в идеале) приложение так, чтобы через пару лет не пришлось все переделывать.
Где здесь разработка ?
как часто выбирают либы на старте приложения ?
Либо это делают чуть позже, если там какой-то экзотический случай.
Как часто проектируют какие-то особенные структуры данных на этапе проектирования глобального ? Не видел ни разу (да, это субъективно).
С учетом специфики системного дизайна, каждая из обсуждаемых ролей имеет равные шансы на то, чтобы растить компетенцию эту себе, так как они смотрят на продукт с разных сторон. Не вижу, почему это не так.
Не забывайте, есть аналитики (бизнес в тч), которые могут код на бумажке написать не хуже обычного разраба.
И да, их майндсет остается аналитическим. Хотя, если потребуется, они могут переключиться в другую роль.
Вооооооооот
Ha-ha, classic. Сначала делаем алгоритмические интервью. Видим что это нахрен никому не сдалось. Но вместо того что-бы отменить, начинаем снимать видео, как проходить алгоритмические интервью. Потом удивляемся, что начинаем нанимать не талантливых программистов, а тех кто за...чил литкод и алгоритмы. Что же могло пойти не так? Вводим систем дизайн. Но опять видим, что норм люди отсеиваються. И вместо того, что бы переработать систему найма - начинаем выпускать видео, как проходить систем дизайн интервью так, как вам надо. Вы что не понимаете, что нормальный разработчик не будет тратить полгода-год только на то, что бы вытянуть ваши палки с колес при прохождении собесов. 80% толковых просто пройдут мимо. И будут правы.
А есть ссылка на то интервью с Даниилом, про которое идет речь в докладе ?
Скоро будет. Оно в рамках этой же конференции было, но на часа четыре раньше.
@@AlexanderPolomodov отлично, буду ждать! Вообще вам большое спасибо за то, что вы делаете! Сейчас с большим удовольствием и интересом изучаю ваши материалы
Опубликовали интервью ua-cam.com/video/Wh5Ya6UFG1k/v-deo.html
@@AlexanderPolomodov Спасибо за доклад!
Подскажите пожалуйста, вы вроде упоминали про то что и у фронтенда есть систем дизайн интервью, но не очень понятно что он включает.
С системным дизайном для бекендщиков все понятно и ты видишь какой-то путь, чтобы вырасти в архитектора, но у фронтенда это все в каком-то тумане и сильно зависит от компании (в основном ты просто крафтишь компоненты и перекрашиваешь кнопки). Я довольно долго варюсь в этом и вижу только путь развития в тимлида из сеньера фронта (а в менеджмент не хочется), либо свичится в бек на N лет и потом идти в архитекторы (это какой-то титанический труд с большим риском).
Если поделитесь опытом, было бы интересно! Спасибо.
@@exslims1, спасибо за обратную связь и вопрос. Да, у нас для фронтенд разработчиков есть свое интервью по Web Architecture, в котором фокус на проектирование сложного фронтенд приложения с определенными требованиями по получению и отправке данных и компонентной структурой на фронте. Подробнее, возможно, расскажут мои коллеги на одной из конференций, так как я хоть и поспособствовал появлению такого интервью у них, но дальше не сильно погружался в происходящее там.
Кандидаты в в архитекторы уровня солюшн тоже проходят у вас секцию алгоритмов и языковую?
Да
@@AlexanderPolomodov почему так? Архитектор должен выйти из кодинга или уметь в?
@@Akimkooo а как по другому, нужны практики, а не теоретики... Так как весь дьявол в деталях
@@Akimkooo, мы считаем, что люди, которые не умеют писать код и не знакомы с промышленной разработкой, а умеют только рисовать квадратики и стрелочки, не слишком нам интересны в роли архитектора.
@@AlexanderPolomodovмного они потом пишут код в роли архитектора или рисуют квадратики?
Порожняк! Если каждй синьйор будет все настраивать прямо и проектировать ну такое. Техлид архитектор набуя?
Как то всё высосано из пальца. Куча мест где можно предьявить за отсутствие опыта или знаний что бы урезать кандидата по зп
Вооот
... воот
ппц душнила
10/10
Продам нейросеть, обученную вырезать слово "вот" из видео.
Невозможно слушать. Неструктурированная каша из мыслей.
Смотрю доклад и вижу, есть 100500 книжек, их хорошо бы изучить все, потом можете попробовать к нам прийти.
Просто автор их прочитал и чешет ими своё ЧСВ, если ты читал другое - у него ключевые слова несовпадут и он заключит что ты не прошёл интервью.
Какие-то психологические игры. В своих ответах ясно пояснил, что почва под этим процессом непрочная и больше, всё-таки, основана на субъективном восприятии.
вот
супер доклад
Очень крутой доклад, раскладывает всю массу неструктурированных знаний в очень понятный план, как и в роадмапе развития архитекторов. Проводим по вашей методологии интервью по систем дизайну из блога в медиуме, за что огромное вам спасибо!
Спасибо за обратную связь, рад, что вам этот материал помог.
Йфффй
Ййф
Ййй😊фффф😊😊😊
Ф ффм
Мне кажется вы путаете поток исполнения и диаграммы потоков данных в 4 пункте статьи / доклада. Диаграммы потока данных это вполне конкретная диаграмма в одной из нотаций. en.wikipedia.org/wiki/Data-flow_diagram. То о чем вы говорите это просто execution flow, который наиболее проще показать на sequence диаграмме или на какой-то более абстрактной диаграмме, но уж точно не data flow diagram - которая используется для рисования обзорной картинки потоков данных между системами в различных ETL процессах. Но уж точно на DFD не будет детализации какой запрос POST посылает пользователь. Главный фокус DFD это узлы между которыми перетекают данные и направление потока, но не детали данных.
Какое отношение алгоритмы имеют к эффективному хранению, быстрому чтению из БД и какие алгоритмы вы бы использовали?
Александр, спасибо за систематизацию знаний и здесь и в других выступлениях, очень просто о сложном. У меня всегда не хватает административной составляющей для систематизации знаний, а тут за 40 минут паттерн проектирования, который можно отдать ребятам для изучения точек входа. Единственное, чтобы добавил сюда, что архитектор должен еще знать НПА в смежных областях, особенно в нашем государстве, ведь можно сделать систему, а потом понять, что она вне закона, а никто кроме архитектора не мог подсказать об этом. У меня есть предположения где в Тинькофф (и не только) это упустили, но возможно вы это заложили в risk management или договор с клиентом, так как иногда это можно покрыть просто успешностью системы.
Спасибо за обратную связь.
Насчет юридических вопросов или рисков в целом - это хороший point. В рамках больших проектов у нас такая проработка конечно есть, но пытаться проверить это на system design interview было бы сложно - времени бы точно не хватило:)
Use case нету в UML!!!!!
Для того, чтобы проверить ложность этого утверждения стоит заглянуть в последний стандарт UML 2.5.1 от декабря 2017 года и найти описание Use Cases в части 18. А дальше почитать с б39 страницы по 652 страницу о том, что это такое и как этим пользоваться