Публичное интервью по System Design. Александр Поломодов.
HTML-код
- Опубликовано: 25 авг 2024
- Выступление на ArchDays 2023. Забронируйте участие на следующей конференции: archconf.ru/arch
Архитектурное собеседование - одно из самых сложных как для кандидата, так и для интервьюера. Оно достаточно часто встречается в зарубежной практике и иногда в российских компаниях. Мы устроили System Design Interview в realtime и посмотрели, как обычно проходит интервью, какие знания и навыки нужны кандидату, и заодно разобрали ошибки, которые могут допустить обе стороны.
Спасибо! Интересно и полезно! Для себя сделал вывод - никогда не давать задание на систему, которая была/есть у меня, как интервьюера, в реальности, так как много лишнего обсуждается и чувствуется глубокое переживание за саму задачу, основанное на личном опыте хождения по граблям. Никогда не говорить кандидату, что именно это мы сейчас делаем, тем самым убирается ощущение, что кандидат - «бесплатный» свежий взгляд.
Спасибо за фидбек. Согласен, что с задачкой мы сильно погрузились в детали, но зато это показало в секции вопросов и ответов насколько глубока может быть кроличья нора:) А вообще, придумывание и проработка задач отнимает много времени, поэтому обычно и берешь что-то из своей практики.
@@AlexanderPolomodov я, как РР, провел более сотни интервью похожего типа, но, так как все могут прочитать книгу "как проходить SDI", использовал чуть иной подход - то есть "работа в паре", а не экзамена, как рекомендуется и как показано у Вас. Смотрел на то, как человек подходит к решению тривиальной задачи и взаимодействия, но в условиях изменяемых требований - как итог, за год всего двух лидов пришлось уволить (отлично прошли, но не хотели работать) - остальные полсотни бойцов круто перформили.
Так как я в поиске нового проекта, сам недавно проходил SDI первый раз - было интересно побывать на "другой стороне". Но в ВК использовали тот же посыл, что и Вы, задача по текущему продукту, это местами давало осадок freework.
Кажется, что свежий взгляд это нормально и то, что кандидат может сразу показать пользу в выполнении актуальной задачи, должно дать и ему самому удовлетворение
Кажется что на таких собесах собеседующий играет роль эксперта/ведущего (подсказать куда копать). Встать в такую роль когда нет реального опыта с такой задачей имхо сложно.
А "свежий" взгляд никто не отменял, главное не быть предвзятым - считать что вы самый умный и сделали лучшую систему априори
То что нужно меньше закапываться в детали это уже задача собеседующего по самоконтролю и применимо и на других этапах)
Спасибо за доклад! А вот интересно в какой момент и на основании каких требований принималось решение строить сразу распределенную систему? И вообще есть ли смысл на подобного рода интервью обсудить монолитные решения с точки зрения потянут/ не потянут, или же интервьюеры зачастую хотят увидеть именно что-то распределенное?
Я думаю сильно зависит от контекста задачи, расчетов нагрузки (которых тут не было) и от религиозных воззрений собеседующих.
Вообще жирный контр-тейк монолиту будет мол, а что будете делать когда надо будет заскейлить часть приложения, но опять же сильно зависит от вводных, мб будет норм или даже предпочтительно взять монолит
Кажется, в этой презентации ruclips.net/video/tmoOTqPgbFM/видео.html Поломовод говорит, что он однажды досрочно закончил интервью с кандидатом, который спроектировал всю систему "в одной коробке". Хотя я не думаю, что вопрос был лишь только в том, что это не была распределённая система: Александр кажется достаточно вдумчивым и корректным человеком, не склонным к "резким движениям" и категоричным заключениям.
Согласен с доводами предыдущего комментатора: нужно на начальном этапе оценивать нагрузку и её рост и исходить из этого. Об этом, например, говорит Дмитрий Волыхин
1:22:55 cassandra - а нагрузка кажется, что read-heavy per se. Я думаю, в реальных условиях это очень сложно продать интервьюеру -- почему-то кажется, что вряд ли "прокатит" вариант "у вас RFC есть похожие на тему" :) -- по крайней мере в том, варианте, что он озвучивал - что для writes рядом стоит redis
Ни о чём. Пустая трата времени.
Не очень, честно говоря
Вы прям серьезно? Вы ищите человека для каких задач? У одного требований нет, второй их пытается стребовать, но безрезультатно. Детский сад, штаны на лямках.
Спасибо за видео, но к "собесу" очень много вопросов. Самое главное, наверное, это то, что не уложились в тайминг совсем. На реальном собесе надо за 45 минут составить требования, обсчитать нагрузку / ресурсы, нарисовать схемы на разных уровнях, рассказать про масштабирование (где / как / по каким алгоритмам), обосновать выбор технологий. В видео же какой-то разговор на чиле.
Также не понравились оговорки типа "не знаком с предметной областью". Вы серьезно? A/B тестирование в первом приближении это разметить аудиторию, показывать по этой разметке, посчитать целевую метрику. Вот и вся предметная область. Вы же не стали углубляться в стат значимость, достаточность наблюдений и дисперсию целевой метрики? А там как раз самая соль. А как мне кажется, именно эти расчеты и надо автоматизировать. А также, например, пытаться делать перекрестные тесты независимыми. Или делать разбиение AAB.
Еще странная позиция по технологиям. Cassandra - а почему она? Это достаточно специализированная база данных, для time series например. И на реальном собесе кандидат должен выбрать из всех вариантов и обосновать свой выбор. А на работе ты уже так не сможешь сделать и надо брать то, что уже есть. Ну так может и на собесах не докапываться?
Чтот не понял почему "вся соль" в АВ тестах, "независимом перекрестном тестировании", "стат. значимости" и т.п. если речь про _систем дизайн_ интервью. Такой этап и у простых сеньоров часто бывает. И там не надо закапываться оч глубоко в реализацию конкретной фичи/системы, а показать что ты способен думать, осмысленно собирать из подходящих кубиков систему опираясь на упрощённый контекст задачи. Ты не должен за час успеть решить задачу которую дают аналитику/архитектору на пару дней/недель.
На мой взгляд, смысл построения такой системы как раз в организации вычислений и подтверждении стат значимости, потому что по моему опыту очень часто аналитики не до конца понимают, что такое p-value например, или почему нужно сильно больше наблюдений, если дисперсия целевого показателя большая. В реальности люди просто смотрят на то, что один показатель больше другого. А то, что результат мог получиться случайным образом, либо из-за сезонности, либо из-за неправильного разделения на сегменты и тд - об этом забывают. Вот в этом ценность системы.
Почему я хочу видеть это на систем дизайн интервью? Потому что имхо в первую очередь кандидат должен определить, в чем ценность той системы, которую мы разрабатываем, какие боли она покрывает и от этого отталкиваться. Тогда можно по полочкам разложить основные моменты и сервисы, и, например, больше внимания уделить как раз важным местам. Условно говоря, про матчинг и прилипание пользователя в группу / эксперимент надо думать в первую очередь, а не в конце собеса с подсказки интервьюера. И это вообще не специфика предметной области и супер очевидная вещь (ради чего мы делаем АБ тест?)
По моему опыту прохождения собесов, интервьюеров интересует именно законченная система с указанием всех кирпичиков (сервисов, балансировщиков, БД, очередей), выбором конкретных технологий (и обоснованием чуть большим, чем просто название), мониторингов. А еще неплохо бы рассказать, какие rps на каких ручках и что будет происходить, когда отдельные кирпичики начнут умирать, или мы захотим добавить пару новых шардов.
@@alekseevserge, если стоит задача нанять разработчика бекэнда и вы будете требовать у него понимание терминов мат статистики на уровне аналитика, то я сомневаюсь, что вы сможете закрыть позицию в приемлемое время. Очень уж разные сферы, которые слабо пересекаются даже на senior позициях.
Лайк за Український прапор
Ты серьезно такой олень, что тебе даже в декоре офиса флаги мерещатся?