BA & SA | 10000 Interview questions
10.2K subscribers
172 photos
14 videos
342 links
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Download Telegram
Объяснение:

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 для параллельного выполнения независимых задач и синхронизации. Его правильное применение сокращает время процессов и повышает эффективность.
Please open Telegram to view this post
VIEW IN TELEGRAM
Science & Education 🌍🔬

Папка для тех, кто погружен в мир научных исследований, современных образовательных технологий и задумывается о международной карьере.

Мы отобрали каналы, которые реально помогают в обучении и работе: от свежих научных публикаций и EdTech-трендов, советов по управлению сложными интеллектуальными проектами до актуальных подборок стипендий и грантов по поступлению в топовые вузы мира🔥

👉 ОТКРЫТЬ ДОСТУП
№4803 категория вопросов: #REQUIREMENTS
4803. На приёмке выяснилось, что для некоторых товаров НДС 10%, а для экспортных — 0%. Претензия заказчика: «Я же просил автоматически — значит, сама должна понимать ставку». Что упустил аналитик?
Anonymous Quiz
1%
Не проверил, что разработчик знаком с налоговым кодексом
93%
Не декомпозировал требование на явные бизнес-правила (категории товаров, ставки, исключения)
2%
Не добавил ручной ввод ставки для сложных случаев
5%
Не согласовал требование с бухгалтерией до разработки
Объяснение:

«Автоматически» не означает «магически». Система не может сама догадаться, какой товар облагается какой ставкой. Аналитик обязан был задать вопросы: «Откуда системе знать ставку? По каким правилам выбирать 20% или 10%? Есть ли список товаров с исключениями?». Затем разбить на чёткие правила:

Если товар в категории «Продовольствие», то НДС 10%.
Если страна назначения не РФ, то НДС 0%.
Для остальных — 20%.
Без такой детализации разработчик принимает решение по умолчанию, которое почти наверняка окажется неверным. Это реальная проблема на проектах, где бизнес-правила сложны. Аналитик должен превращать «автоматически» в алгоритм.
Please open Telegram to view this post
VIEW IN TELEGRAM
В начале мая сразу несколько новостей показали, куда двигается рынок: спрос на готовые ИТ-бизнесы вырос на 30%, а компании всё активнее пересобирают процессы вокруг ИИ и инфраструктуры. Плюс бизнесу снова приходится быстро адаптироваться к новым правилам и ограничениям — без хороших ориентиров это уже не про рост, а про выживание.

Чтобы не тратить время на случайные каналы и шум, собрали папку с экспертами по IT и бизнесу. Внутри — люди, которые разбирают рынок по делу: без лишней теории, с практикой, кейсами и нормальной аналитикой.

Это подборка для тех, кто хочет быстрее понимать, что происходит в рынке, и принимать решения без лишней суеты.

Сохранить папку себе 📨
№4804 категория вопросов: #TESTING
4804. Тестировщики проверяли биометрию — работает. Оказывается, баг проявляется только если пользователь меняет язык приложения на английский. Какой вид тестирования должен бы
Anonymous Quiz
0%
Нагрузочное тестирование
72%
Тестирование комбинаций (парное тестирование, decision table)
1%
Тестирование безопасности
28%
Юзабилити-тестирование
Объяснение:

Баги часто возникают на пересечении двух независимых условий: биометрия + смена языка. Тестировщики проверяли биометрию на русском языке и смену языка отдельно, но не комбинацию. Техника парного тестирования или таблиц принятия решений помогает выявить такие сценарии. Аналитик при планировании должен был указать: «для критичных функций (логин, платеж) протестировать все комбинации факторов (язык, тип устройства, способ входа)». В реальном проекте из-за пропуска такой комбинации можно обнаружить баг только в проде, когда пользователи начинают жаловаться.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4805 категория вопросов: #DBMS
Объяснение:

Когда в запросе WHERE inn = 123 (число) сравнивается с полем VARCHAR, база данных неявно преобразует число в строку для каждой строки таблицы или, что чаще, делает преобразование строки в число для каждой строки индекса. Это делает индекс бесполезным (full scan). Правильное решение — либо передавать строковое значение в кавычках, либо изменить тип поля на числовой. Аналитик должен в требованиях указать, что индексируемые поля, используемые в поиске, должны иметь тип, совместимый с запросами. Реальный случай: оптимизатор PostgreSQL не использует индекс при неявном преобразовании, что приводит к падению производительности на больших таблицах.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4805 категория вопросов: #BROKER
4805. В логистической компании Kafka используется для передачи событий о перемещении грузов. Один из консьюмеров (система учёта) периодически падает из-за ошибки в формате данных.
Какое архитектурное требование аналитик должен был добавить?
Anonymous Quiz
5%
Увеличить retention сообщений до 30 дней
78%
Настроить Dead Letter Queue для сообщений
6%
Добавить мониторинг лага потребителя
12%
Переключить консьюмера в режим at-most-once
Объяснение:

Когда потребитель не может обработать сообщение (ошибка в данных), бесконечные ретраи бесполезны. Политика должна быть: после N неудачных попыток (например, 3) переместить сообщение в отдельную очередь Dead Letter Queue (DLQ). Основная очередь продолжает чистую работу, а проблемные сообщения копятся в DLQ для ручного анализа и исправления. Без DLQ одно «плохое» сообщение может заблокировать всю очередь. Аналитик обязан требовать настройку DLQ для всех критичных потребителей и указывать количество попыток, интервалы повторных попыток (обычно экспоненциальные 1, 2, 4, 8 секунд) и процедуру обработки DLQ. Это промышленный стандарт для отказоустойчивых систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4806 категория вопросов: #SYSTEMDESIGN
4806. Фотохостинг (как Instagram) должен быстро показывать ленту друзей. Создание поста — редко, а просмотр — постоянно. Какую архитектуру выбрать, чтобы не нагружать базу при чтении?
Anonymous Quiz
12%
Всегда читать посты напрямую из базы с кэшем на уровне запроса
49%
Генерировать ленту заранее — при создании поста разослать его ID всем друзьям в их ленту
13%
Использовать синхронную репликацию базы между всеми серверами
25%
Хранить посты в S3, а метаданные в DynamoDB
Объяснение:

Проблема

В фотохостинге соотношение чтения и записи огромное (например, 1000 просмотров на один пост). Если при каждом просмотре ленты делать сложный запрос к базе (получить посты друзей с пагинацией), база ляжет под нагрузкой даже при скромном количестве пользователей.

Решение — fan-out на запись
Когда пользователь создаёт пост, система не ждёт, пока друзья его увидят. Она заранее (асинхронно) раскладывает ID поста в ленту каждого друга. Лента каждого пользователя — это просто список ID постов (например, в Redis или другой кэш-структуре), отсортированный по времени. При чтении лента отдаётся мгновенно, без обращения к основной базе. Это называется push-модель (fan-out на запись).

Альтернатива (плохая для нагрузки)

Read fan-out (pull) — при каждом запросе ленты искать посты всех друзей. Это убивает производительность.
Почему другие варианты не подходят

A — всё равно каждый запрос нагрузки базу.
C — репликация не решает логику сбора ленты.
D — выбор хранилища не решает проблему: нужна стратегия подготовки ленты.

Реальный пример

Twitter раньше использовал pull-модель и испытывал проблемы. Перешёл на push для активных пользователей и гибридный подход. Instagram и Facebook генерируют ленту заранее.

Что должен зафиксировать аналитик

«При создании поста его идентификатор должен быть доставлен в ленты всех подписчиков через очередь».
«Лента пользователя хранится в быстром кэше (Redis) в виде отсортированного списка».
Please open Telegram to view this post
VIEW IN TELEGRAM
4
№4807 категория вопросов: #INTERVIEW
Объяснение:

Почему B — правильный ответ
Настоящий опытный аналитик не оценивает без контекста. Он задаёт уточняющие вопросы:

Есть ли документация по API? Какие протоколы?
Нужна ли аутентификация, какие схемы?
Будет ли шлюз обрабатывать идемпотентность?
Какой объём трафика?
Какая команда будет заниматься?
Затем предлагает диапазон оценок (например, 2–4 недели) с факторами риска (сложность аутентификации, отсутствие тестового стенда). Такой подход показывает системное мышление.

Чего ждут интервьюеры

Не названия цифр, а методологии оценки (например, T-shirt sizes, planning poker, аналогии с похожими задачами).
Умение выявлять неизвестное.
Понимание, что интеграция — это не только код, но и тестирование, документирование, отладка.
Почему не другие варианты

A — называется число без анализа, что является красным флагом (не учитывает нюансы).
C — уход от ответа показывает неуверенность.
D — завышенная оценка без объяснений — тоже плохо.

Реальный совет

На собеседовании скажите: «Я бы начал с изучения документации, составил список задач, выделил неизвестные зоны и предложил бы спринт на исследование, после которого дал бы прогноз». Это демонстрирует проактивность.
Please open Telegram to view this post
VIEW IN TELEGRAM