BA & SA | 10000 Interview questions
10.2K subscribers
172 photos
14 videos
342 links
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Download Telegram
4854. В середине спринта заказчик просит добавить поле «скидка» в отчёт. Оценка — 2 дня. В спринте осталось 3 дня, но есть незавершённая задача высокой важности. Что делает аналитик?
Anonymous Quiz
0%
Добавляет поле без обсуждения, чтобы угодить заказчику
95%
Организует встречу с заказчиком и командой, показывает последствия, ищет компромисс
3%
Отказывает, потому что требования уже утверждены
2%
Передаёт решение тимлиду
Объяснение:

Изменения в середине спринта — норма. Но аналитик не должен принимать их единолично.
Процесс:
Оценить трудозатраты (2 дня).
Выяснить у команды, какую задачу можно отложить или сократить.
Показать заказчику варианты:

Добавить поле, но сдвинуть релиз на 2 дня.
Добавить поле вместо другой задачи (какую именно?).
Отложить поле на следующий спринт.
Зафиксировать решение (протокол).

Реальный кейс: В компании по разработке CRM аналитик сразу согласился добавить поле «скидка» в отчёт без обсуждения. В итоге сломали отчёт по выручке, так как новая задача не была протестирована. После внедрения процедуры change request подобное прекратилось.

Вывод: Аналитик — не просто исполнитель, а фасилитатор, который управляет приоритетами и информирует о рисках.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4855 категория вопросов: #INTEGRATION
4855. Платежный шлюз присылает callback на ваш endpoint. Злоумышленник может подделать запрос и сымитировать успешную оплату. Как защититься?
Anonymous Quiz
0%
Проверять IP-адрес отправителя
95%
Использовать цифровую подпись (HMAC) каждого запроса, сверять её с секретным ключом
1%
Требовать пароль в теле запроса
4%
Принимать callback только из внутренней сети
Объяснение:

Платёжные системы используют подпись HMAC (или JWT). Провайдер и ваш сервер имеют общий секретный ключ. Провайдер вычисляет подпись тела запроса и передаёт её в заголовке. Ваш сервер перевычисляет подпись и сравнивает. Если подписи совпадают — запрос подлинный.

Почему не подходят другие:

IP может быть подделан или динамический.
Пароль в теле может быть перехвачен (не передавайте в открытом виде).
Ограничение по внутренней сети не работает для внешних webhook.

Реальный пример: Stripe подписывает каждый callback заголовком 
Stripe-Signature. Ваш сервер проверяет подпись, прежде чем обрабатывать платёж.

Вывод: В требованиях к интеграции аналитик должен указать: «Callback-запросы должны содержать HMAC-подпись, вычисленную с использованием секретного ключа».
Please open Telegram to view this post
VIEW IN TELEGRAM
№4856 категория вопросов: #DBMS
4856. В системе категорий товаров (меню) глубина вложенности не ограничена. Запросы: «найти все подкатегории заданной категории». Какой способ хранения иерархии оптимален для чтения?
Anonymous Quiz
45%
Поле parent_id + рекурсивный CTE
34%
Хранить предков в отдельной таблице (Closure Table)
11%
Хранить path в виде строки (например, "1/3/5/")
9%
Хранить сразу все уровни в отдельных столбцах (level1_id, level2_id...)
Объяснение:

Closure Table (таблица замыканий) хранит все пути «предок-потомок» в отдельной таблице. Например, для дерева: категория 1 → 2 → 3, строки: (1,1,0), (2,2,0), (3,3,0), (1,2,1), (2,3,1), (1,3,2). Запрос «все подкатегории категории 1»: SELECT descendant FROM closure WHERE ancestor = 1. Это один простой быстрый запрос без рекурсии.
parent_id + CTE — рекурсивный запрос, при глубоких деревьях и больших объёмах данных может быть медленным.
path — хорошо, если не нужно часто искать поддеревья и не очень много записей.
отдельные колонки — ограничивает глубину.

Реальный пример: В каталоге интернет-магазина с 10 000 категорий и глубиной 5 уровней Closure Table позволяет получить все товары раздела за 20 мс, тогда как рекурсивный CTE — за 200 мс.

Вывод: Аналитик, проектируя структуру для иерархий с частым чтением поддеревьев, должен рекомендовать Closure Table.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4857 категория вопросов: #REQUIREMENTS
4857. Заказчик просит сделать «фильтр товаров по многим параметрам с мгновенной выдачей результатов». После реализации выясняется, что «мгновенно» — 0.5 секунды, а разработчик заложил 2 секунды. Что нужно было сделать аналитику до начала разработки?
Anonymous Quiz
7%
Передать требование архитектору для технической оценки
89%
Зафиксировать числовое значение в нефункциональном требовании
2%
Уменьшить количество параметров фильтрации
2%
Добавить в команду профессионального тестировщика
Объяснение:

Остальные варианты — передача архитектору, уменьшение параметров, добавление тестировщика — не решают проблему отсутствия конкретной цифры. Только явная фиксация времени отклика (например, «не более 500 мс») делает требование проверяемым.)
Please open Telegram to view this post
VIEW IN TELEGRAM
№4858 категория вопросов: #DBMS
4858. В интернет-магазине при одновременном заказе последнего товара двумя пользователями оба заказа проходят, и остаток становится отрицательным. Какой механизм БД предотвратит эту ситуацию?
Anonymous Quiz
3%
Увеличить количество реплик базы данных
86%
Использовать пессимистическую блокировку строки
11%
Создать индекс на поле остатка
1%
Переключиться на NoSQL базу данных
ПРОМТ, КОТОРЫЙ УЛУЧШИТ ВАШ БЛОГ ИЛИ ПРОДУКТ

- нормально сегментирует ЦА, а не напишет «женщины 30+»
- подскажет, что нужно докрутить


В одной ПАПКЕ с топовыми каналами по бизнесу, IT и AI

AI песочница инженера

…. и ещё много полезных каналов, из которых вы получите

- нейросети, которые генерят контент за минуты, ведут переписки и приводят новых клиентов
- набор топовых инструментов для IT
- небанальные связки по привлечению трафика

❗️через 3 дня удалю пост

ПОПАСТЬ В ПОДБОРКУ КАНАЛОВ
Объяснение:

Увеличение реплик, индекс или смена БД не решают проблему гонки. Только блокировка строки SELECT ... FOR UPDATE гарантирует, что второй заказ увидит уже изменённый остаток.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4859 категория вопросов: #ARCHITECTURE
4859. В микросервисной архитектуре мобильное приложение вызывает 5 разных микросервисов напрямую. При изменении IP-адреса одного сервиса приложение перестаёт работать. Какой паттерн решает эту проблему?
Anonymous Quiz
4%
Перейти на синхронные вызовы с ретраями
92%
Внедрить единую точку входа (API Gateway)
4%
Хранить адреса сервисов в кэше приложения
1%
Использовать общую базу данных для координации
Очевидно, что всего через пару лет умение работать с ИИ станет таким же обычным делом, как открыть браузер или найти что-то в поисковике.

И вот что удивительно — многие до сих пор не воспринимают это всерьёз.

Одни продолжают делать всё по старинке — руками.
А другие — уже сейчас экономят часы работы с нейросетями и вырываются вперёд.
С каждым месяцем разрыв между ними будет только расти.


Вот отличная подборка сильных экспертов по AI & IT для твоего профессионального роста:
(https://t.me/addlist/iy6id2ElW_hiNTg0)

* Там — живые инструменты, реальные кейсы и понятные схемы, как использовать нейросети с толком и высоким КПД.

Если Тема тебе откликается — добавляйся в ПАПКУ 📌 👉 Делимся знаниями и аудиторией — растём вместе ⚡️ * Отписаться можно в любой момент. Остаться — тоже. ✔️
👍1
Объяснение:

Ретраи, кэширование адресов в приложении или общая БД не решают проблему смены IP. API Gateway скрывает внутреннюю структуру, клиент знает только адрес шлюза
Please open Telegram to view this post
VIEW IN TELEGRAM
⁉️ Устал искать интересные каналы с новостями про искусственный интеллект?

📁 СОХРАНИ СЕБЕ ЧТОБЫ НЕ ПОТЕРЯТЬ

В этой папке собраны каналы про медицину, которые помогают быстрее разобраться в сфере, находить идеи и экономить время на поиске информации.

😏 ЗАБИРАЙ ПАПКУ ТУТ

Папка действует 72 часа.

🤩 Организаторы: Green.Papka
Please open Telegram to view this post
VIEW IN TELEGRAM
№4860 категория вопросов: #REQUIREMENTS