BA & SA | 10000 Interview questions

Экономьте бюджет и время на организацию командировок Как перестать тратить на организацию командировки 2+ часа и совершать ошибки? Воспользуйтесь сервисом автоматического оформления командировок GATE. Зарегистрируйтесь за 1 минуту и получите: ✅ Бесплатное подключение. Платите только тогда, когда ездите в командировки. Возможна оплата по счету или картой. ✅ Постоплата до 30 дней. Оплачивайте сервис тогда, когда вам удобно. ✅ Автоматизация бухгалтерии. Автоматическое оформление отчетов и квитанций. Больше никакого заведения вручную. ✅ Подгрузка закрывающих документов в ЭДО. ✅ Заведение карточек сотрудников. Загрузите информацию о сотруднике и в будущем она будет автоматически подгружаться при оформлении. GATE— это экспертиза и 3 000+ довольных клиентов! Узнать больше #реклама 16+ gate.ru О рекламодателе

☀Объяснение: Суть проблемы Требование могло звучать как: «Пользователь может забронировать место». Ни слова про то, что место должно блокироваться на время оплаты, чтобы его не перехватил другой. Разработчик реализовал только бронирование без блокировки, и это формально соответствует букве требования. Но бизнес ожидал стандартного для таких систем поведения (блокировка на 10–15 минут). Проблема — в неполноте требований, а именно — в отсутствии сценария конкурентного доступа. Почему это зона ответственности аналитика? Аналитик должен выявлять и описывать нефункциональные и логические требования, которые кажутся «очевидными» бизнесу, но не очевидны разработчику. Конкурентный доступ (race condition) — классический сценарий для систем бронирования. Аналитик обязан был задать вопрос: «А что, если два пользователя попытаются забронировать одно место?». Критерии приемки (Acceptance Criteria) должны включать примеры с одновременными действиями. ❌ Почему не другие варианты: A (разработчики) — они реализовали требования «как есть». Без явного указания на блокировку у них нет оснований её делать. B (тестировщики) — тестировщики проверяют соответствие требованиям. Если в требованиях нет сценария с параллельным бронированием, они могут его не проверить. D (архитектор) — архитектор может предложить техническое решение (пессимистические блокировки), но только если есть соответствующее требование. Как должно было быть в требованиях: Аналитик должен добавить в критерии приемки: При начале бронирования место блокируется для текущего пользователя на 10 минут. Другой пользователь не может забронировать то же место, пока блокировка активна. При успешной оплате блокировка снимается, место становится купленным. При неоплате через 10 минут блокировка снимается, место снова доступно. Пример тест-кейса, который должен быть в плане тестирования: Пользователь А выбирает место и начинает бронирование. Пользователь Б пытается выбрать то же место. Ожидаемый результат: Б видит сообщение «Место временно заблокировано другим пользователем». Реальный кейс В одной авиакомпании при запуске нового сайта пассажиры жаловались, что после выбора места и ввода данных карты место вдруг становится недоступным — его успевал перехватить другой пассажир, более быстрый на оплату. Компания потеряла сотни тысяч рублей на возвратах и компенсациях. Аналитик не прописал блокировки, хотя в предыдущей системе они были. После инцидента требования дополнили, и блокировки внедрили. Вывод: Аналитик обязан выявлять неочевидные сценарии, такие как конкурентный доступ, и явно описывать их в требованиях. «Очевидные» вещи для бизнеса не очевидны для разработчиков. Пропуск такого сценария — прямая ответственность аналитика, а не разработки или тестирования. 🎯 #TESTING

Запустите рекламу в телеграм-каналах через Яндекс Директ Перфоманс-реклама в мессенджере продолжает работать: • Таргетинг по тематикам и регионам • Умный подбор каналов • Гибкие модели оплаты (CPC и CPV) Яндекс Директ знает, как привлечь целевую аудиторию 💰👌 Попробовать #реклама yandex.ru О рекламодателе

№4780 категория вопросов: #TESTING

ИН:Ритейл 21 мая приглашаем всех, кто определяет стратегию развития и маркетинга бизнесов в ритейле, обсудить ситуацию на рынке в новых условиях, вызовы 2026 года и перспективы. Отдельный фокус — на технологиях и инструментах, которые помогают бизнесу отвечать на новые вызовы: как меняется эффективность привлечения, как растёт измеримость рекламных каналов и какую роль играют новые форматы в маркетинговом миксе. Встречаемся 21 мая в Москве. Для тех, кто не сможет приехать, организуем онлайн-трансляцию. Мероприятие бесплатное, нужно только зарегистрироваться. Зарегистрироваться #реклама yandex.ru О рекламодателе

ИИ — ЭТО УЖЕ НЕ «КОГДА-НИБУДЬ ПОТОМ» ... ОН ПРЯМО СЕЙЧАС ПЕРЕПИСЫВАЕТ ПРАВИЛА ИГРЫ 🖋 Тексты, аналитика, продажи, дизайн, экономия десятков часов в неделю — это не футурология. Это ваш обычный вторник, если вы в теме. Вопрос больше не в том, заменит ли ИИ людей. Вопрос в том, кто обгонит вас, пока вы раздумываете. Хотите быть среди первых, кто использует нейросети на все сто? Тогда вот что вам нужно ⚡️: 👉 ПОДБОРКА реально сильных и продвинутых экспертов по нейросетям, ИИ, IT & HR Tech, а также последние - AI Life hacks Забирайте, пока другие бездумно скролят ленту новостей. Отписаться можно в любой момент — без проблем ✔️ Ссылка на ПАПКУ ⬇️ https://t.me/addlist/3PXSBSiaHSc2ZWRk * Добавляйте себе в избранное и скидывайте ссылку коллегам.

ТЫ ГОТОВ К ВИРУСНОМУ ПРОРЫВУ ?! ВКЛЮЧАЙСЯ ! ⚡️ Нейросети радикально меняют правила игры и никого не ждут. Мы даём тебе полную ПОДБОРКУ лучших ИИ инструментов для работы с практическими примерами и конкретными шагами для старта и роста ⚡️ Здесь собрана настоящая мощь ИИ 🔥 Подписывайся ⬅️ пока искусственный интеллект не решил, что ты вне игры ... От свежих инсайтов до практичных лайфхаков по работе с ИИ - всё, что поможет создавать контент за считанные минуты: ▪️ секреты и примеры написания промптов для любого ИИ ▪️ создание ИИ-ассистента, который заменит целый отдел ▪️ техники продаж с помощью нейросетей Хочешь узнать, как ИИ меняет мир прямо на твоих глазах ?! 📌 Добавляй ПАПКУ бесплатно и делись с друзьями * Ссылка ➡️ https://t.me/addlist/3PXSBSiaHSc2ZWRk Отписаться можно в любой момент. Остаться — тоже ✔️ . Получай лучшие ИИ инструменты уже сегодня - не жди ♨️ 👉 Забирай ПОДБОРКУ экспертных каналов прямо сейчас ! * Через 48 часов ссылка будет удалена ...

Выплаты и оформление сотрудников по всему миру MadeTask - международный сервис выплат и оформления сотрудников для вашего бизнеса💰 Выплаты на карты, счета и электронные кошельки по всему миру. Работа с самозанятыми, ИП и физлицами. Встроенная проверка исполнителей. Автоматизация через API (АПИ). Пополнение счёта в рублях. Модель EOR (ЕОР): официальное оформление сотрудников без открытия вашего юрлица за рубежом. Доступные страны: Россия, Беларусь, Кипр и другие. Соцпакет и налоги по местному законодательству. Один договор для всех исполнителей. Закрывающие документы в личном кабинете. Оставьте заявку на подключение📞 Попробовать #реклама madetask.ru О рекламодателе

☀Объяснение: Почему этот кейс важен? Частая ошибка — проектировать сложную распределённую систему там, где бизнес ещё не доказал свою жизнеспособность. Для MVP (минимально жизнеспособного продукта) главное — скорость выхода на рынок и возможность быстро менять логику. Микросервисы эту скорость убивают. 1. Почему A — самый весомый аргумент? Микросервисы требуют настройки межсервисного взаимодействия (брокеры, API gateway, discovery), логирования, трассировки, управления конфигами, отказоустойчивости. Всё это — инженерная сложность, которая не нужна, пока нет 10 пользователей. Отладка распределённой системы в разы сложнее: локально поднять 5 сервисов с их базами данных — это время. А если баг воспроизводится только при определённой последовательности вызовов между сервисами? 2. Почему другие варианты слабее? B (больше серверов) — да, но облака позволяют арендовать дешёвые маленькие инстансы. Это не главная проблема. C (нет ACID-транзакций) — действительно проблема, но для многих сценариев интернет-магазина eventual consistency допустима. Это не самый весомый аргумент на старте. D (медленнее из-за сети) — сетевые вызовы добавляют задержку, но современные дата-центры и протоколы делают её не такой критичной. Опять же, не главное. 3. Реальный кейс Один стартап потратил 6 месяцев на проектирование микросервисной архитектуры с Kafka, Kubernetes, сервис-мешем. К моменту запуска рынок уже заняли конкуренты с монолитом на Ruby on Rails, который они сделали за 2 месяца. Стартап закрылся. Другой пример: известный сервис по доставке еды начинал с монолита и перешёл на микросервисы только когда нагрузка превысила 1000 заказов в минуту. До этого монолит отлично работал и позволял быстро экспериментировать с фичами. 4. Что должен сделать аналитик в такой ситуации? Оценить стадию проекта: MVP — монолит, даже если «потом перепишем». Зафиксировать нефункциональные требования: ожидаемая нагрузка в первый месяц, темп изменений. Предложить модульный монолит: внутри одного приложения выделить пакеты/модули с чёткими границами. Это позволит в будущем легко вырезать их в микросервисы, если понадобится. Настоять на том, что сложность архитектуры должна соответствовать сложности бизнеса. Не нужно строить космопорт, если пока продаёте хот-доги с лотка. 5. Когда микросервисы действительно нужны с самого начала? Если разные модули имеют кардинально разные требования к масштабированию (например, видеообработка и простой блог). Если в команде уже есть опыт и инфраструктура для микросервисов. Если бизнес требует независимого развёртывания частей системы разными командами. Вывод: Главный весомый аргумент против микросервисов на старте — избыточная сложность, которая замедляет разработку и увеличивает риск провала MVP. Аналитик, понимающий это, помогает команде не переусложнять архитектуру раньше времени. 🎯 #ARCHITECTURE

Куда срочно перенести рабочие чаты? Битрикс24 — мессенджер для работы и бизнеса. Личные и групповые чаты, видеозвонки и каналы в одном сервисе. Приглашайте коллег и внешние команды. Работает как привычный мессенджер. Есть бесплатный тариф. Начните работать уже сейчас. Попробовать #реклама 16+ bitrix24.ru О рекламодателе

№4779 категория вопросов: #ARCHITECTURE

Гайд для маркетологов по эффективным онлайн-встречам Как повысить результативность брейнштормов, совещаний и планерок с командой с помощью онлайн-встреч? Гайд МТС Линк: полезные материалы, чек-листы и кейсы для эффективных видеовстреч и совещаний. ✅ В гайде: - Как организовать встречу, на которую все придут; - Как управлять ходом встречи, чтобы не превратить её в хаос; - Как завершить встречу и не забыть о договорённостях; ✨ Скачайте гайд бесплатно по ссылке Скачать #реклама 16+ mts-link.ru О рекламодателе

☀Объяснение: 1. Что произошло в кейсе? Изначально система была монолитом — всё работало в одном процессе. Уведомления отправлялись внутри того же приложения, поэтому проблем не было. Когда сервис уведомлений выделили в отдельный микросервис, разработчики, скорее всего, оставили синхронный вызов: сервис заказов отправляет HTTP‑запрос к сервису уведомлений и ждёт ответа. Если сервис уведомлений недоступен (упал, перегружен, обновляется), вызов завершается ошибкой, и уведомление теряется навсегда. Ретраи (повторы) помогают только при кратковременных сбоях, но не при длительной недоступности. 2. Почему асинхронный брокер сообщений — правильное решение? Брокер (например, RabbitMQ, Kafka) работает как надёжная очередь, которая хранит сообщения, даже если потребитель временно не работает. Сервис заказов создаёт событие «Заказ создан» и отправляет его в очередь. Ему не нужно ждать ответа → пользователь не испытывает задержки. Сервис уведомлений читает из очереди и отправляет уведомления. Если он упал, сообщения остаются в очереди и не теряются. Когда сервис восстановится, он заберёт все накопившиеся сообщения и обработает их. Брокер может быть настроен на персистентность (сохранение на диск) и репликацию (копии на нескольких серверах), что исключает потерю данных даже при полном отключении брокера. 3. Почему не подходят другие варианты? A (синхронный REST с ретраями) — если сервис уведомлений лежит 30 минут, ретраи будут бесполезны, а синхронный вызов всё равно заблокирует основной процесс (пользователь будет ждать). C (общая БД) — возврат к монолиту на уровне данных: сервисы начнут писать в одну базу, возникнут конфликты, потеряется независимость микросервисов. Это антипаттерн. D (gRPC) — это более быстрый и компактный протокол, но он остаётся синхронным. Проблема недоступности не решается. 4. Реальный пример из жизни Один известный сервис доставки выделил уведомления в микросервис, оставив синхронные вызовы. В час пик сервис уведомлений упал на 40 минут. За это время тысячи заказов не получили SMS и пушей. Клиенты не знали, где курьер, и жаловались. После инцидента перешли на RabbitMQ: теперь даже при падении сервиса уведомлений на несколько часов все события накапливаются в очереди и доставляются после восстановления. Заказы не теряются, пользователи довольны. 5. Что аналитик должен зафиксировать в требованиях Для всех фоновых операций (уведомления, логирование, отчёты) использовать асинхронные очереди. Указать брокер сообщений, настройки персистентности и репликации. Прописать политику повторных попыток и Dead Letter Queue. Определить допустимую задержку (например, уведомление должно прийти не позже чем через 5 минут после события). Вывод: При переходе на микросервисы критически важно пересмотреть способ коммуникации. Для операций, не требующих немедленного ответа, асинхронный брокер сообщений — это единственный способ обеспечить надёжность и не потерять данные. 🎯 #ARCHITECTURE

Гайд по лидогенерящим вебинарам для маркетологов Как CMO, PR и digital-маркетологам сделать вебинары полноценным инструментом лидогенерации и системно привлекать новых клиентов? Гайд от МТС Линк по подготовке и проведению эффективных вебинаров для лидогенерации. ✅ В гайде: - Составили пошаговую инструкцию по организации маркетингового вебинара; - Собрали рекомендации экспертов по обучению, выступлениям и маркетингу; - Делимся успешными кейсами компаний DSSL, Just AI, «Гален», «САРШТЕДТ» и «ЭГИС-РУС». ✨ Скачайте гайд бесплатно по ссылке Скачать #реклама 16+ mts-link.ru О рекламодателе

№4778 категория вопросов: #ARCHITECTURE

Творческая профессия без опыта: шаг, меняющий многое Нет художественного образования? Не знаешь, с чего начать? Думаешь «это не для меня» или «я уже опоздала»? Все меняется с одного простого шага — нужно разрешить себе попробовать. Именно поэтому я создала бесплатный курс для женщин, которым хочется перемен. Тех, кто ищет дело по душе, тянется к красоте и хочет попробовать что-то новое. Спокойно, без вложений, с поддержкой. На бесплатном 14-дневном курсе по дизайну интерьера с нуля ты узнаешь: — как выбирать правильные материалы; — какие инструменты использовать при работе над проектами; — секреты создания гармоничного пространства. За две недели у тебя на руках будет готовый дизайн-проект реальной квартиры. И все это бесплатно. Запишись на практический курс. И проверь, может, ты следующая, кто скажет: «я нашла себя»❤️ Зарегистрироваться #реклама 16+ diskill-design.ru О рекламодателе

☀Объяснение: 1. Суть проблемы На диаграмме вариантов использования (use case diagram) отношение include означает, что включаемый вариант использования (в данном случае «Аутентифицироваться») обязательно выполняется каждый раз, когда выполняется базовый вариант («Оплатить услугу»). Если хотя бы один способ оплаты не требует аутентификации (например, оплата по ссылке из SMS), то include применять нельзя — он создаст неверное требование, что аутентификация нужна всегда. 2. Правильное отношение — «extend» Отношение extend используется, когда расширяющий вариант (в данном случае «Аутентифицироваться») выполняется не всегда, а только при наступлении определённого условия (extension condition). Это условие указывается в диаграмме или в спецификации. Например: «Аутентифицироваться» расширяет «Оплатить услугу» только если пользователь заходит через личный кабинет и не аутентифицирован ранее. При оплате по SMS-ссылке условие ложно, и аутентификация не вызывается. 3. Почему другие варианты неверны A (наследование между акторами) — не решает проблему, наследование акторов (например, «Авторизованный пользователь» наследует «Гость») относится к ролям, а не к вариантам использования. C — формулировка «include используется только для обязательных подфункций» верна по сути, но в ответе она подана как утверждение, что аутентификация необязательна. Однако причина ошибки не в том, что include так нельзя использовать, а в том, что нужно было выбрать extend. D — ошибка есть, вариант неверен. 4. Реальный кейс из практики В одном проекте аналитик нарисовал include для аутентификации во всех платёжных сценариях. Разработчик реализовал обязательный вход для всех способов оплаты, включая оплату по ссылке из email. Бизнес заказчик был в шоке: пользователи, переходя по ссылке, должны были вводить логин и пароль, что убивало удобство быстрой оплаты. Переделка стоила спринта. После этого в команде ввели правило: перед использованием include всегда задавать вопрос «А есть ли сценарий, где эта подфункция не нужна?». Если есть — использовать extend с условием. 5. Что должен сделать аналитик для предотвращения ошибки Перечислить все возможные способы оплаты. Для каждого способа определить, требуется ли аутентификация. Если хотя бы один способ не требует аутентификации — выбрать extend. Явно прописать условие расширения (например, «если пользователь не аутентифицирован и способ оплаты ≠ SMS-ссылка»). Включить оба сценария (с аутентификацией и без) в критерии приёмки. Вывод: Ошибка в выборе между include и extend — не просто «неточность в диаграмме», а прямая причина неверной реализации бизнес-логики и лишних затрат. Аналитик обязан различать эти отношения и всегда проверять обязательность подфункции. 🎯 #UML