🔥 Интервью - это стресс.
Как сделать прохождение комфортным?
💡 Хорошисты и отличники обладают хорошей базой знаний.
Однако этого ещё не достаточно, чтобы успешно пройти специальный экзамен - ЕГЭ. Его специфика породила определённую подготовку. Одно дело знать, другое - уметь применить знания по определенной теме за короткое время в данных условиях.
Слышал истории, когда люди полгода готовились к интервью изучая разрозненный материал. И не факт, что проходили🤷
Предлагаю рассмотреть саму структуру интервью и уменьшить тем самым неопределенность и стресс от прохождения.
⚡️ Структуру задает кандидат. Хорошо когда она есть. И ещё лучше когда шаги в ней последовательные и логичные. Помогают кандидату двигаться в бодром темпе и не упускать главные моменты.
⚙️ Существуют различные варианты таких шагов. Мне понравился подход Александра. Он драйвит тему интервью. Можно сказать, формирует тренд.
1️⃣ В начале кандидат задаёт уточняющие вопросы, понимает границы системы. Таким образом, синхронизируется с интервьюером.
2️⃣ И далее уже от общего к частному строит систему по шагам.
✅ Поняв и проработав предлагаемую структуру, можно смело пробоваться в наши и зарубежные Big Tech компании.
#SystemDesignInterview #SystemDesign
Как сделать прохождение комфортным?
💡 Хорошисты и отличники обладают хорошей базой знаний.
Однако этого ещё не достаточно, чтобы успешно пройти специальный экзамен - ЕГЭ. Его специфика породила определённую подготовку. Одно дело знать, другое - уметь применить знания по определенной теме за короткое время в данных условиях.
Слышал истории, когда люди полгода готовились к интервью изучая разрозненный материал. И не факт, что проходили🤷
Предлагаю рассмотреть саму структуру интервью и уменьшить тем самым неопределенность и стресс от прохождения.
⚡️ Структуру задает кандидат. Хорошо когда она есть. И ещё лучше когда шаги в ней последовательные и логичные. Помогают кандидату двигаться в бодром темпе и не упускать главные моменты.
⚙️ Существуют различные варианты таких шагов. Мне понравился подход Александра. Он драйвит тему интервью. Можно сказать, формирует тренд.
1️⃣ В начале кандидат задаёт уточняющие вопросы, понимает границы системы. Таким образом, синхронизируется с интервьюером.
2️⃣ И далее уже от общего к частному строит систему по шагам.
✅ Поняв и проработав предлагаемую структуру, можно смело пробоваться в наши и зарубежные Big Tech компании.
#SystemDesignInterview #SystemDesign
YouTube
Как подготовиться и пройти System Design Interview. Александр Поломодов
Выступление на конференции ArchDays 2022 https://archconf.ru/arch
Собеседования в формате System Design Interview становятся все популярнее. Эти собеседования по проектированию проводят как для инженеров, так и для технических менеджеров, а их результаты…
Собеседования в формате System Design Interview становятся все популярнее. Эти собеседования по проектированию проводят как для инженеров, так и для технических менеджеров, а их результаты…
⚡️ CQRS
4 буквы, смысл один:
"Принцип разделения операций чтения и записи"
Распишу предпосылки для его использования. Чтобы на собеседование вы смогли понять, что данные обстоятельства идеальны для его применения.
На интервью нужно уметь оценивать отношение операций чтения к операциям записи.
Зачастую, чтений на порядки больше.
1️⃣ Такие чтения бывают ресурсоёмкие. К примеру, нужно много join'ить, чтобы получить нужную информацию.
2️⃣ Если использовать классический подход - одна база данных для чтений и записей - то каждым таким чтением будем нагружать БД.
3️⃣ Если есть обозреватель, которому нужно получать только определенный вид данных, то не обязательно join'ить на каждый запрос чтения.
Поэтому выделяем отдельную сущность для чтения.
Это может быть материализованное представление. Когда ответ уже готов к выдаче.
Или много таких представлений. Если есть разные обозреватели, которым требуются разные виды данных на чтение.
Всё. Теперь вы знаете что такое принцип CQRS(Command Query Responsibility Segregation). И при каких обстоятельствах его применять.
Это был easy уровень. Выжимка из большого кол-ва информации в интернете.
middle уровень
🔥 Для тех, кто любит погорячее.
Такую сущность можно выделить ещё более явно. В отдельную Базу Данных. Зачем?
✅ Мы можем выбрать БД, оптимизированную под данный тип данных и под их быструю отдачу.
Также и для БД для операций записи.
✅ Положительный side-эффект от такого выделения - теперь у нас два независимых трака работы с данными!
Рушится запись? Остаётся чтение! И наоборот. Повысили отказоустойчивость системы.
Не можете сделать заказы в онлайн магазине? Печаль. Зато можете просматривать товары. Система отвалилась не полностью.
Изобрели серебряную пулю? Как бы не так.😕
Модель согласованность деградировала до "eventual consistency" - "согласованность в конечном счёте".
Теперь мы не читаем с той же БД, в которую только что записали. Где можно было бы обеспечить транзакционность.
Пишем оптимизированно в одну БД, читаем из другой. А как же свежие данные оказались доступны для чтения?
Есть различные ответы на этот вопрос.
1) Сервис между базами данных подкачивает изменения из БД для записи в БД для чтения.
2) Сервис, который пишет в БД для записи сам откидывает изменение в БД для чтения.
3) Сервис, который пишет в БД для записи кладёт записи и в брокер сообщений. Из этого брокера считывает другой сервис, который обновляет данные в БД для чтения.
❇️ Появилась дополнительная сущность, отвечающая за синхронизацию данных.
❌ Она же является и дополнительной точкой отказа.
⏱ Именно из-за этой синхронизации модель согласованности данных стала "eventual consistency".
Нужно некоторое конечное время, что перенести обновления.
В отличие от строгой согласованности, когда:
"Все пользователи всех нод в одно и тоже время видят одно и тоже значение записи."
Здесь же записавший понимает, что данные записаны. А читатель их ещё не видит.
Поэтому такой подход нельзя применять в банковских системах, где нужно гарантировать ACID.
А в онлайн магазине - пожалуйста. И в системе заказа еды. Или же - в системе по ведению работы с клиентами с многочисленными формализованными отчётами.
senior уровень
📗 Больше о терминах
Операции записи объединяются под термином "command" - команда. Чтобы более точно передать смысл - "отдаём команды на выполнение". Не ожидаем данных. Только подтверждение успешности выполнения/принятия команды.
Операции чтения объединяются под термином "query" - запрос. Это именно получение данных без их изменения.
📔 Event Sourcing
Обозначу, что есть системы, построенные на генерации, обмене, использование событий.
Бывает, что говоря о CQRS подразумевают использование этих event'ов. Но нет.
Это два разных подхода. Которые могут использоваться вместе.
—————
Завтра стартует High Load 2023.
Среди докладов есть "Эволюция и мифы CQRS" Андрея Цветцих. Хочу попасть к нему. Послушаю. Расширю восприятие темы.
#SystemDesignInterview #SystemDesign #CQRS
4 буквы, смысл один:
"Принцип разделения операций чтения и записи"
Распишу предпосылки для его использования. Чтобы на собеседование вы смогли понять, что данные обстоятельства идеальны для его применения.
На интервью нужно уметь оценивать отношение операций чтения к операциям записи.
Зачастую, чтений на порядки больше.
1️⃣ Такие чтения бывают ресурсоёмкие. К примеру, нужно много join'ить, чтобы получить нужную информацию.
2️⃣ Если использовать классический подход - одна база данных для чтений и записей - то каждым таким чтением будем нагружать БД.
3️⃣ Если есть обозреватель, которому нужно получать только определенный вид данных, то не обязательно join'ить на каждый запрос чтения.
Поэтому выделяем отдельную сущность для чтения.
Это может быть материализованное представление. Когда ответ уже готов к выдаче.
Или много таких представлений. Если есть разные обозреватели, которым требуются разные виды данных на чтение.
Всё. Теперь вы знаете что такое принцип CQRS(Command Query Responsibility Segregation). И при каких обстоятельствах его применять.
Это был easy уровень. Выжимка из большого кол-ва информации в интернете.
middle уровень
🔥 Для тех, кто любит погорячее.
Такую сущность можно выделить ещё более явно. В отдельную Базу Данных. Зачем?
✅ Мы можем выбрать БД, оптимизированную под данный тип данных и под их быструю отдачу.
Также и для БД для операций записи.
✅ Положительный side-эффект от такого выделения - теперь у нас два независимых трака работы с данными!
Рушится запись? Остаётся чтение! И наоборот. Повысили отказоустойчивость системы.
Не можете сделать заказы в онлайн магазине? Печаль. Зато можете просматривать товары. Система отвалилась не полностью.
Изобрели серебряную пулю? Как бы не так.😕
Модель согласованность деградировала до "eventual consistency" - "согласованность в конечном счёте".
Теперь мы не читаем с той же БД, в которую только что записали. Где можно было бы обеспечить транзакционность.
Пишем оптимизированно в одну БД, читаем из другой. А как же свежие данные оказались доступны для чтения?
Есть различные ответы на этот вопрос.
1) Сервис между базами данных подкачивает изменения из БД для записи в БД для чтения.
2) Сервис, который пишет в БД для записи сам откидывает изменение в БД для чтения.
3) Сервис, который пишет в БД для записи кладёт записи и в брокер сообщений. Из этого брокера считывает другой сервис, который обновляет данные в БД для чтения.
❇️ Появилась дополнительная сущность, отвечающая за синхронизацию данных.
❌ Она же является и дополнительной точкой отказа.
⏱ Именно из-за этой синхронизации модель согласованности данных стала "eventual consistency".
Нужно некоторое конечное время, что перенести обновления.
В отличие от строгой согласованности, когда:
"Все пользователи всех нод в одно и тоже время видят одно и тоже значение записи."
Здесь же записавший понимает, что данные записаны. А читатель их ещё не видит.
Поэтому такой подход нельзя применять в банковских системах, где нужно гарантировать ACID.
А в онлайн магазине - пожалуйста. И в системе заказа еды. Или же - в системе по ведению работы с клиентами с многочисленными формализованными отчётами.
senior уровень
📗 Больше о терминах
Операции записи объединяются под термином "command" - команда. Чтобы более точно передать смысл - "отдаём команды на выполнение". Не ожидаем данных. Только подтверждение успешности выполнения/принятия команды.
Операции чтения объединяются под термином "query" - запрос. Это именно получение данных без их изменения.
📔 Event Sourcing
Обозначу, что есть системы, построенные на генерации, обмене, использование событий.
Бывает, что говоря о CQRS подразумевают использование этих event'ов. Но нет.
Это два разных подхода. Которые могут использоваться вместе.
—————
Завтра стартует High Load 2023.
Среди докладов есть "Эволюция и мифы CQRS" Андрея Цветцих. Хочу попасть к нему. Послушаю. Расширю восприятие темы.
#SystemDesignInterview #SystemDesign #CQRS
✅ Как пройти System Design Интервью?
1️⃣ Этапы интервью
По моему опыту прохождения и опыту изучения материалов для подготовки к успешному прохождению этой секции интервью могу выделить 4 основных этапа, которые кандидату необходимо пройти в ходе проектирования заданной системы:
1) Уточнение функциональных и нефункциональных требований
Звёздный час кандидата. Точнее 5-10 минут. За которые нужно собрать фт, нфт, которые есть в голове интервьюера на данную сессию интервью. Понять, прояснить, закомититься по функционалу, который нужно будет реализовать. Также рассчитать нагрузки.
2) API
Построение легкой версии интерфейса взаимодействия с пользователем. Возможны и вариации этого этапа. О них ниже.
Здесь можно определить happy path, data flow.
3) Построение базовой архитектурной схемы
Большими мазками построить основные сервисы, БД, взаимодействия. Должно быть дубово. И работать. В принципе.
Далее можно углубиться в части системы чтобы показать, доказать интервьюеру, что таким образом система реализует обговоренный и согласованный ранее функционал.
4) Уточнение технологий
Sql, NoSql? OLAP, OLTP? statefull, stateless? Python, Go? Rest, grpc? ... Возможный расчёт мощности сервера БД.
2️⃣ Какие могут быть вариации? И причём тут умение коммуницировать?
Нужно быть готовым к отклонению от такой схемы прохождения интервью.
🧐 Пример картинки на ближайшие 45 минут в голове у интервьюера:
"Ожидаю, что кандидат уточнит требования, рассчитает базовые характеристики системы, построит схему данных, базовую схему. Хочу в дополнение намекнуть ему реализовать систему мониторинга".
🤷 Можно проявить чудеса телекинеза и считать, что угадал план этого интервью.
🗣 А можно спрашивать. Явно. Это твой выход. Ты на сцене и прожекторы смотрят на тебя. Прежде чем выступить, нужно понять что от тебя хотят. И уточнять по мере продвижения.
"Нужно ли сейчас реализовывать полноценное api? Или сконцентрироваться на схеме данных?"
3️⃣ Нужные качества кандидата
1. Умение слушать
Помогает понимать подсказки и пожелания интервьюера. Возможно, менять направление дизайна.
2. Проактивность
Именно ты ведёшь интервью. Всегда есть баланс между:
Спросил много -> посчитали, что джун ⚖️ спросил мало -> говорит заученное
Практика помогает найти разумный баланс.
⭐️ Представленная схема с 4мя этапами, вариациями и подсвеченные важные навыки помогут тебе заложить фреймворк для прохождения любого System Design интервью.
Удачи в прохождение!
А какие интервью были недавно у тебя и как они прошли?
https://www.youtube.com/watch?v=KhfeYD0VBOY
#SystemDesignInterview #SystemDesign
1️⃣ Этапы интервью
По моему опыту прохождения и опыту изучения материалов для подготовки к успешному прохождению этой секции интервью могу выделить 4 основных этапа, которые кандидату необходимо пройти в ходе проектирования заданной системы:
1) Уточнение функциональных и нефункциональных требований
Звёздный час кандидата. Точнее 5-10 минут. За которые нужно собрать фт, нфт, которые есть в голове интервьюера на данную сессию интервью. Понять, прояснить, закомититься по функционалу, который нужно будет реализовать. Также рассчитать нагрузки.
2) API
Построение легкой версии интерфейса взаимодействия с пользователем. Возможны и вариации этого этапа. О них ниже.
Здесь можно определить happy path, data flow.
3) Построение базовой архитектурной схемы
Большими мазками построить основные сервисы, БД, взаимодействия. Должно быть дубово. И работать. В принципе.
Далее можно углубиться в части системы чтобы показать, доказать интервьюеру, что таким образом система реализует обговоренный и согласованный ранее функционал.
4) Уточнение технологий
Sql, NoSql? OLAP, OLTP? statefull, stateless? Python, Go? Rest, grpc? ... Возможный расчёт мощности сервера БД.
2️⃣ Какие могут быть вариации? И причём тут умение коммуницировать?
Нужно быть готовым к отклонению от такой схемы прохождения интервью.
🧐 Пример картинки на ближайшие 45 минут в голове у интервьюера:
"Ожидаю, что кандидат уточнит требования, рассчитает базовые характеристики системы, построит схему данных, базовую схему. Хочу в дополнение намекнуть ему реализовать систему мониторинга".
🤷 Можно проявить чудеса телекинеза и считать, что угадал план этого интервью.
🗣 А можно спрашивать. Явно. Это твой выход. Ты на сцене и прожекторы смотрят на тебя. Прежде чем выступить, нужно понять что от тебя хотят. И уточнять по мере продвижения.
"Нужно ли сейчас реализовывать полноценное api? Или сконцентрироваться на схеме данных?"
3️⃣ Нужные качества кандидата
1. Умение слушать
Помогает понимать подсказки и пожелания интервьюера. Возможно, менять направление дизайна.
2. Проактивность
Именно ты ведёшь интервью. Всегда есть баланс между:
Спросил много -> посчитали, что джун ⚖️ спросил мало -> говорит заученное
Практика помогает найти разумный баланс.
⭐️ Представленная схема с 4мя этапами, вариациями и подсвеченные важные навыки помогут тебе заложить фреймворк для прохождения любого System Design интервью.
Удачи в прохождение!
А какие интервью были недавно у тебя и как они прошли?
https://www.youtube.com/watch?v=KhfeYD0VBOY
#SystemDesignInterview #SystemDesign