BA & SA | 10000 Interview questions

☀Объяснение: 1. Суть задачи Две проверки не зависят друг от друга: одну можно выполнять в кредитном бюро, другую в скоринговой системе. Нет смысла делать их последовательно — это удвоит время ожидания. Нужно запустить их параллельно и продолжить процесс только после того, как обе завершатся. 2. Как работает AND-шлюз Fork (разветвление): шлюз с одним входом и двумя выходами. Поток разделяется на две параллельные ветки. Обе выполняются одновременно. Join (слияние): шлюз с двумя входами и одним выходом. Он пропускает поток дальше только после того, как все входящие ветки завершились. Соединяя fork и join, вы получаете параллельное выполнение с синхронизацией. 3. Почему не подходят другие шлюзы XOR (исключающий) — активирует только один путь из нескольких. Если поставить XOR, будет выполнена только одна проверка, вторая не запустится. Не подходит. OR (включающий) — может активировать один или несколько путей. Но при слиянии OR продолжает работу после завершения первой активированной ветки, не дожидаясь остальных. Это не гарантирует выполнения обеих проверок. Событийный шлюз — выбирает путь на основе наступления события (таймер, сообщение). Для параллельного выполнения не используется. 4. Реальный кейс В банке процесс выдачи кредита изначально был последовательным: сначала скоринг (1 минута), потом кредитная история (1 минута). Заявка обрабатывалась 2 минуты. Аналитик перерисовал процесс с AND-шлюзом: проверки запускаются параллельно, общее время сократилось до 1 минуты. Клиенты стали получать решение в два раза быстрее. 5. Дополнительные детали для аналитика Дорожки (swimlanes) помогают показать, кто за какую проверку отвечает (скоринг — отдел рисков, кредитная история — бюро). Таймеры можно прикрепить к каждой ветке: если одна проверка зависла, через 30 секунд отправить уведомление администратору. Исключения: если одна из проверок падает с ошибкой, то join не сработает. Нужно добавить шлюз для обработки ошибок (например, если скоринг недоступен, вернуть отказ). Вывод: AND-шлюз (fork/join) — ключевой элемент BPMN для параллельного выполнения независимых задач и синхронизации. Его правильное применение сокращает время процессов и повышает эффективность.

Грант на миграцию в Yandex Cloud — без лимита Три причины, по которым компании откладывают переезд в облако: двойные расходы на переходный период, сложность планирования и нехватка команды. Мы закрываем все три: ✅ Грант на 60 дней — не платите за потребление, пока переезжаете ✅ Архитектор Yandex Cloud — спроектирует инфраструктуру и составит план ✅ Нет DevOps-команды — подберём формат поддержки 75+ сервисов в одной консоли. 4 дата-центра. Pay-as-you-go. ⚡ Программа действует до 20 июня. Оставьте заявку — рассчитаем грант. Узнать больше #реклама 16+ yandex.cloud О рекламодателе

№4799 категория вопросов: #BPMN

☀Объяснение: 1. В чём неоднозначность? Фраза «при смене статуса» допускает множество интерпретаций. У заказа может быть 10 статусов: «Создан», «Оплачен», «На сборке», «Передан курьеру», «В пути», «Доставлен», «Отменён», «Возврат», «Переназначен» и т.д. Бизнес, вероятно, хотел уведомлять только о статусах, важных для клиента (например, «Оплачен», «Передан курьеру», «Доставлен»). Разработчик же, следуя букве, отправил уведомление при любом изменении, в том числе техническом («Переназначено курьеру» из-за смены смены). Это привело к спаму. 2. Что такое критерии приемки (Acceptance Criteria)? Это список проверяемых условий, которые должны выполняться, чтобы пользовательская история считалась завершённой. Они пишутся на понятном бизнесу языке и часто в формате Given-When-Then. В данном случае аналитик должен был включить: Критерии приемки: Уведомление отправляется при переходе в статусы: «Оплачен», «Передан в доставку», «Доставлен». Уведомление не отправляется при статусах: «Отменён», «Возврат», «Переназначено курьеру». Уведомление содержит текст, соответствующий статусу (тексты приведены в приложении). 3. Почему не подходят другие варианты? A (согласовать с разработчиками) — полезно, но разработчики не являются заказчиками. Они не могут решить, какие статусы важны для бизнеса. C (нагрузочное тестирование) — не связано с логикой отправки, это про производительность. D (только после финального статуса) — это тоже предположение, не обязательно верное. Бизнес мог ждать уведомления и на промежуточных этапах. 4. Реальный кейс В службе доставки продуктов клиенты начали получать уведомления «Курьер переназначен» (при смене смены) в 3 часа ночи. Жалобы посыпались. Аналитик не указал явный список статусов. После добавления критериев приемки разработчик изменил логику, и уведомления стали приходить только о ключевых событиях. 5. Что должен сделать аналитик Всегда задавать вопрос: «А при каких именно статусах нужно уведомление? Приведите примеры». Фиксировать ответы в виде таблицы или списка. Включать критерии приемки в каждую пользовательскую историю. Проверять, что тестировщики учли все перечисленные статусы. Вывод: Избегайте общих фраз. Если есть список значений — перечисляйте их явно в критериях приемки. Это сэкономит часы переделок и нервов команды.

№4798 категория вопросов: #REQUIREMENTS

Как работать удаленно с нейросетями? Присоединяйся! Подпишись прямо сейчас, чтобы не потерять: Свежие обзоры нейросетей, которые реально работают — без лишнего хайпа и воды, только проверенная информация, которую можно использовать для заработка. Пошаговые видео-уроки, после которых всё станет понятно — научитесь быстро осваивать новые профессии и автоматизировать рутинные задачи. Как находить клиентов, готовых платить дорого — секреты эффективного поиска заказов и построения стабильного потока заказов. Автоматизация работы — научитесь выполнять 2-часовую работу за 20 минут без выгорания, автоматизируя рутину с помощью нейросетей. Подписаться #реклама 16+ О рекламодателе

☀Объяснение: 1. Почему возникают дубликаты? Платёжные системы часто работают по семантике at-least-once (как минимум один раз). Это означает, что при сомнении (таймаут, неполучение подтверждения, перезапуск) шлюз может отправить callback повторно. Сетевые сбои, перезагрузки серверов — обычная причина дублей. Если ваша система списывает деньги при каждом вызове, клиент заплатит дважды. 2. Идемпотентность — единственное решение Идемпотентная операция при повторном выполнении с теми же входными данными не меняет состояние системы. В данном случае: обработав первый callback, вы списываете деньги и запоминаете уникальный ID транзакции (например, payment_id). При повторном callback вы проверяете: если payment_id уже обработан — просто возвращаете успех, не списывая повторно. Технически это делается через хранение ID в Redis (с TTL) или в БД с уникальным индексом. 3. Почему не подходят другие варианты? A (увеличить таймаут) — не влияет на дубликаты, таймаут отвечает за время ожидания ответа от вашего сервера шлюзом, но шлюз может дублировать и без таймаута. C (отключить повторные callback на стороне шлюза) — невозможно, это внутренняя логика шлюза. Даже если бы можно было, вы снизите надёжность: при временном сбое уведомление потеряется навсегда. D (ручной разбор) — не масштабируется, при тысячах платежей в день ручная проверка невозможна, бизнес не успеет. 4. Реальный кейс Интернет-магазин подключил платёжный шлюз. В первые часы у нескольких клиентов списались деньги дважды. Анализ показал, что шлюз отправлял дубликат при задержке ответа магазина более 2 секунд. Внедрение идемпотентности на основе transaction_id позволило автоматически отсекать дубликаты без потери надёжности. 5. Что должен зафиксировать аналитик в требованиях «Обработка callback-ов должна быть идемпотентной. Для этого использовать уникальный идентификатор платежа, предоставляемый шлюзом (поле payment_id), и хранить обработанные ID в Redis или БД с временем жизни не менее 24 часов». «При повторном получении callback-а с уже обработанным ID система должна возвращать HTTP 200 OK без повторного выполнения бизнес-логики». «Для защиты от гонок использовать блокировки или атомарные операции (например, SET NX в Redis)». Вывод: Идемпотентность — обязательное требование для любой интеграции, где внешняя система может повторять запросы (а это почти все платёжные, SMS, email-сервисы). Без неё дублирование неизбежно приведёт к финансовым потерям и недовольству клиентов.

№4797 категория вопросов: #BROKER

☀Объяснение: 1. Суть проблемы Микросервисная архитектура даёт преимущества при большом масштабе (тысячи заказов в секунду, 10+ команд разработки), но на старте проекта главное — как можно быстрее выкатить рабочий продукт (MVP), проверить гипотезы и получить обратную связь. Микросервисы же требуют значительных начальных инвестиций в инфраструктуру, инструменты и процессы. 2. Что значит «сложнее в отладке и эксплуатации» Отладка: локально поднять 5 сервисов с их базами данных, очередями, кэшами — это время и память. Трассировка запроса, проходящего через сервисы, требует внедрения распределённого трейсинга (Jaeger, Zipkin). Эксплуатация: нужны оркестрация (Kubernetes), сервис-меш (Istio), мониторинг (Prometheus + Grafana), сбор логов (ELK). Всё это настраивается неделями. Развёртывание: CI/CD для микросервисов сложнее, чем для монолита. Для MVP с 100 заказами в день эти затраты неоправданны. Монолит (или модульный монолит) позволит запуститься за месяц вместо трёх. 3. Почему остальные аргументы слабее A (больше серверов): В облаке дешёвые инстансы для 5 микросервисов стоят несущественно. Не главное. B (нет ACID-транзакций): Действительно проблема, но для доставки еды конечная согласованность (eventual consistency) часто допустима. Например, если заказ создался, а уведомление чуть задержалось — не катастрофа. D (сетевые задержки): При 100 заказах в день сетевые вызовы добавляют миллисекунды, пользователь не заметит. Не весомо. 4. Реальный кейс Стартап потратил 6 месяцев на проектирование микросервисов, а конкуренты на монолите запустились за 2 месяца и захватили рынок. После этого стартап закрылся. Другой пример: известный сервис доставки еды начинал с монолита и перешёл на микросервисы только когда нагрузка превысила 1000 заказов в минуту. 5. Что должен сделать аналитик Оценить стадию проекта (MVP — монолит). Согласовать с командой «архитектуру на вырост» в виде модульного монолита с чёткими границами пакетов, которые в будущем легко вырезать. Зафиксировать нефункциональное требование: «Архитектура должна позволять выделение сервисов без полной переписки при росте нагрузки более 5000 заказов в сутки». Вывод: Микросервисы — не бесплатный бонус, а плата высокой сложностью за масштабируемость и независимость команд. Для MVP эта плата обычно чрезмерна.

Soundlines Russia- надёжный партнёр в подборе персонала! ⚡ Профессиональный подбор персонала для крупных проектов любой сложности. Саундлайнс Глобал работает с кандидатами из 23+ стран мира. ✅ Предлагаем полный цикл услуг: от тестирования до трудоустройства. Гарантируем соответствие всем требованиям и стандартам качества. 👍 Более 30 успешных проектов в разных странах. Доверяют ведущие мировые корпорации. Начните сотрудничество прямо сейчас! Узнать больше #реклама О рекламодателе

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

☀Объяснение: 1. Почему возникают дубликаты? Платёжные системы часто работают по семантике at-least-once (как минимум один раз). Это означает, что при сомнении (таймаут, неполучение подтверждения, перезапуск) шлюз может отправить callback повторно. Сетевые сбои, перезагрузки серверов — обычная причина дублей. Если ваша система списывает деньги при каждом вызове, клиент заплатит дважды. 2. Идемпотентность — единственное решение Идемпотентная операция при повторном выполнении с теми же входными данными не меняет состояние системы. В данном случае: обработав первый callback, вы списываете деньги и запоминаете уникальный ID транзакции (например, payment_id). При повторном callback вы проверяете: если payment_id уже обработан — просто возвращаете успех, не списывая повторно. Технически это делается через хранение ID в Redis (с TTL) или в БД с уникальным индексом. 3. Почему не подходят другие варианты? A (увеличить таймаут) — не влияет на дубликаты, таймаут отвечает за время ожидания ответа от вашего сервера шлюзом, но шлюз может дублировать и без таймаута. C (отключить повторные callback на стороне шлюза) — невозможно, это внутренняя логика шлюза. Даже если бы можно было, вы снизите надёжность: при временном сбое уведомление потеряется навсегда. D (ручной разбор) — не масштабируется, при тысячах платежей в день ручная проверка невозможна, бизнес не успеет. 4. Реальный кейс Интернет-магазин подключил платёжный шлюз. В первые часы у нескольких клиентов списались деньги дважды. Анализ показал, что шлюз отправлял дубликат при задержке ответа магазина более 2 секунд. Внедрение идемпотентности на основе transaction_id позволило автоматически отсекать дубликаты без потери надёжности. 5. Что должен зафиксировать аналитик в требованиях «Обработка callback-ов должна быть идемпотентной. Для этого использовать уникальный идентификатор платежа, предоставляемый шлюзом (поле payment_id), и хранить обработанные ID в Redis или БД с временем жизни не менее 24 часов». «При повторном получении callback-а с уже обработанным ID система должна возвращать HTTP 200 OK без повторного выполнения бизнес-логики». «Для защиты от гонок использовать блокировки или атомарные операции (например, SET NX в Redis)». Вывод: Идемпотентность — обязательное требование для любой интеграции, где внешняя система может повторять запросы (а это почти все платёжные, SMS, email-сервисы). Без неё дублирование неизбежно приведёт к финансовым потерям и недовольству клиентов.

ИИ уже не “будущее” — он тихо стал частью повседневности.🤖 Нейросети помогают писать тексты, генерировать изображения, анализировать данные, искать ошибки в коде и даже придумывать идеи для бизнеса. Но самое интересное — ИИ не заменяет человека, а усиливает того, кто умеет правильно задавать вопросы.🧠 Главный навык ближайших лет — не просто пользоваться технологиями, а понимать, как с ними сотрудничать. IT + ИИ + нейро = новая реальность, где побеждает не тот, кто знает всё, а тот, кто быстрее учится. 🚀 Забрать папку 🎁 Добавиться в папку ⚡️

☀Объяснение: Контрактное тестирование проверяет, что поставщик API (сервис заказов) не нарушает ожидания потребителей (CRM, мобильное приложение, другие сервисы). Оно включает написание тестов, которые имитируют требования потребителя к структуре ответа (поля, типы). При изменении API, если оно удаляет поле, которое ожидает потребитель, контрактный тест падает и не даёт выкатить релиз. Модульные тесты (A) проверяют отдельные функции, они не заметят изменение публичного API. Нагрузочное тестирование (B) проверяет производительность, а не совместимость. Юзабилити (D) — про удобство интерфейса.

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