Архитектор | Ритейлер товаров для детей
Вакансия: Архитектор
Уровень: Senior
Жалование: 450к запрошено
⏺Запись собеседования⏺(В том числе systemDesign со схемами)
📝 Секция «Общие вопросы»:
🔵Расскажите о себе, о своём опыте.
🔵Расскажи про предыдущий проект.
🔵Расскажи о негативном опыте.
🔵Опыт работы с высоконагруженными системами.
🔵Почему перешёл из системного анализа в архитектуру.
📝 Секция «Требования/Нотации/Документация»:
🔵Какая документация была подготовлена на предыдущем проекте.
🔵Что отражали в ADR.
🔵Как проверить соответствие реализации проекту.
👣 Секция «HTTP/REST и синхронные интеграции»:
🔵По каким параметрам выбирать синхронную интеграцию.
🔵Что делать при риске перегрузки системы.
🔵Как обеспечить согласованность данных между системами.
🖥Секция «Брокеры сообщений и асинхронные интеграции»:
🔵Что такое распределённая транзакция.
⚙️ Секция «Архитектура»:
🔵Кто такой архитектор по вашему мнению.
🔵Что самое сложное в работе архитектора.
🤓 Секция «Практика»:
🔴Кейс: Приходит бизнес и ставит срок выполнения проекта - 2 месяца, а ты понимаешь, что за 2 месяца эту задачу не выполнить, нужно как минимум 3 - 4 месяца. Как будешь решать эту проблему?
🔴Попутные вопросы по кейсу:
🔵Приходит бизнес и говорит, что нужно ввести какой - то функционал, но ты понимаешь, что этот функционал будет сильно перегружать систему. Что будешь делать?
🔴Кейс: У нас есть микросервисная архитектура онлайн - магазина. Есть сервис каталога, корзины, заказов. Есть кнопка "добавить в корзину", в "корзине" есть кнопка "оформить заказ", после нажатия этой кнопки заказ летит в сервис заказов и дальше проходить весь жизненный цикл. Сейчас у нас работа с акциями и промо - кодами, проблема в том, что логика работы с этими акциями и промо - кодами размазана по сервисам "корзина", "каталог" и т.д. Маркетологи хотят быстрее запускать акции и промо - коды, а не так как сейчас: через задачу, разработку и т.д. Что ты как архитектор можешь предложить по этой задаче?
🔴Попутные вопросы по кейсу:
🔵Акция на товар, который уже находится в корзине закончилась, что делать?
🔵Как долго хранить данные?
🔵Какую базу данных использовать?
🔵Контракт в Redis изменился. Что произойдёт?
🔵Как построить аналитическую выгрузку?
🔵Где хранить расчёты?
🔵Нужен ли кэш для повторных запросов?
🔵Что будет при изменении JSON?
🔵Будет ли расчёт сохраняться при каждом обновлении?
🔵Как определить устаревший расчёт?
🔵Нужно ли брать другую сумму после окончания акции?
🔵Что делать при медленной работе сервиса?
🔵Что делать, если масштабирование не помогло?
🔵Где хранить данные для отчётности?
🔴Кейс: Что делать при сбое перед отправкой платежа?
🔴Попутные вопросы по кейсу:
🔵Как защититься от повторной отправки заявки?
💩 Голосование: Как вам собес?
🙏 — Сложновато
🔥 — Изи собес
Подписывайтесь на:
❤️@sa_sobes
Вакансия: Архитектор
Уровень: Senior
Жалование: 450к запрошено
⏺Запись собеседования⏺(В том числе systemDesign со схемами)
📝 Секция «Общие вопросы»:
🔵Расскажите о себе, о своём опыте.
🔵Расскажи про предыдущий проект.
🔵Расскажи о негативном опыте.
🔵Опыт работы с высоконагруженными системами.
🔵Почему перешёл из системного анализа в архитектуру.
📝 Секция «Требования/Нотации/Документация»:
🔵Какая документация была подготовлена на предыдущем проекте.
🔵Что отражали в ADR.
🔵Как проверить соответствие реализации проекту.
👣 Секция «HTTP/REST и синхронные интеграции»:
🔵По каким параметрам выбирать синхронную интеграцию.
🔵Что делать при риске перегрузки системы.
🔵Как обеспечить согласованность данных между системами.
🖥Секция «Брокеры сообщений и асинхронные интеграции»:
🔵Что такое распределённая транзакция.
⚙️ Секция «Архитектура»:
🔵Кто такой архитектор по вашему мнению.
🔵Что самое сложное в работе архитектора.
🤓 Секция «Практика»:
🔴Кейс: Приходит бизнес и ставит срок выполнения проекта - 2 месяца, а ты понимаешь, что за 2 месяца эту задачу не выполнить, нужно как минимум 3 - 4 месяца. Как будешь решать эту проблему?
🔴Попутные вопросы по кейсу:
🔵Приходит бизнес и говорит, что нужно ввести какой - то функционал, но ты понимаешь, что этот функционал будет сильно перегружать систему. Что будешь делать?
🔴Кейс: У нас есть микросервисная архитектура онлайн - магазина. Есть сервис каталога, корзины, заказов. Есть кнопка "добавить в корзину", в "корзине" есть кнопка "оформить заказ", после нажатия этой кнопки заказ летит в сервис заказов и дальше проходить весь жизненный цикл. Сейчас у нас работа с акциями и промо - кодами, проблема в том, что логика работы с этими акциями и промо - кодами размазана по сервисам "корзина", "каталог" и т.д. Маркетологи хотят быстрее запускать акции и промо - коды, а не так как сейчас: через задачу, разработку и т.д. Что ты как архитектор можешь предложить по этой задаче?
🔴Попутные вопросы по кейсу:
🔵Акция на товар, который уже находится в корзине закончилась, что делать?
🔵Как долго хранить данные?
🔵Какую базу данных использовать?
🔵Контракт в Redis изменился. Что произойдёт?
🔵Как построить аналитическую выгрузку?
🔵Где хранить расчёты?
🔵Нужен ли кэш для повторных запросов?
🔵Что будет при изменении JSON?
🔵Будет ли расчёт сохраняться при каждом обновлении?
🔵Как определить устаревший расчёт?
🔵Нужно ли брать другую сумму после окончания акции?
🔵Что делать при медленной работе сервиса?
🔵Что делать, если масштабирование не помогло?
🔵Где хранить данные для отчётности?
🔴Кейс: Что делать при сбое перед отправкой платежа?
🔴Попутные вопросы по кейсу:
🔵Как защититься от повторной отправки заявки?
💩 Голосование: Как вам собес?
🙏 — Сложновато
🔥 — Изи собес
Подписывайтесь на:
❤️@sa_sobes