BA & SA | 10000 Interview questions
10.2K subscribers
171 photos
14 videos
341 links
Вопросы и задачи, которые задают на собеседованиях на позицию Бизнес и Системного аналитика. По вопросам сотрудничества- @DeliveryManager7
Download Telegram
Если коротко, то ИИ уже не будущее, а наше настоящее.
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.

Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.

Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
 
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа  
 
* Отписаться можно в любой момент. Остаться — тоже. ✔️

Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk
🔥1
№4841 категория вопросов: #DBMS
4841. В системе бронирования билетов критично не потерять ни одной записи. Репликация базы данных настроена асинхронно. При сбое мастер-сервера последних транзакций пропадают. Как изменить настройку репликации, чтобы гарантировать нулевую потерю данных?
Anonymous Quiz
3%
Увеличить количество реплик
88%
Переключиться на синхронную репликацию (операция подтверждается только после записи на реплику)
1%
Увеличить частоту снэпшотов
8%
Включить кэширование на мастере
НЕБОЛЬШОЙ АПГРЕЙД ТВОЕЙ ЛЕНТЫ, КОТОРЫЙ ДАСТ ХОРОШИЙ БУСТ ТВОЕЙ КАРЬЕРЕ

Друзья, наш канал попал в подборку тг-каналов про ИТ, ИИ, технологии и карьеру — получилась такая ламповая тусовка «для своих» 😎

Тут мы собрали каналы для себя, которые реально помогают:
следить за ИИ — от свежих инструментов до реальных кейсов
разбираться в технологиях — тренды, обзоры и объяснения
расти в IT — советы по карьере, поиску работы и развитию
быть в теме HR Tech — как технологии меняют найм и управление

🆒 Осталось только добавить папку себе ✔️https://t.me/addlist/n__Pk89IyogzOTVk
1👍1🔥1
Объяснение:

Как работает асинхронная репликация
Мастер-сервер принимает транзакцию, подтверждает клиенту «успех» и потом отправляет изменения на реплику. Если мастер падает между подтверждением и отправкой, реплика не получает данные → потеря транзакций. Это допустимо в системах, где допустима микро-потеря (например, аналитика), но не в финансовых или критичных системах.

Синхронная репликация
Мастер отправляет данные на реплику, ждёт её подтверждения, и только после этого отвечает клиенту «успех». При падении мастера реплика уже имеет данные, и потери нет. Недостаток: задержка увеличивается, так как клиент ждёт ответа от реплики.
Пример из реальной жизни
В банковских системах (например, при переводе денег) используется синхронная репликация. В социальных сетях (лайки, просмотры) — асинхронная, так как пара потерянных лайков не критична.

Что должен зафиксировать аналитик
Допустимо ли RPO (Recovery Point Objective) больше нуля? Если нет — синхронная репликация.
Какая задержка допустима? Синхронная репликация медленнее.

Нужно ли распределение по географическим зонам? Тогда синхронная репликация может быть очень медленной.
Вывод: Для критичных к потере данных систем синхронная репликация обязательна. Аналитик должен указать это в требованиях к отказоустойчивости.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4842 категория вопросов: #INTEGRATION
4842. Внешний API ограничивает 10 запросов в секунду. Ваше приложение шлёт 50 запросов в секунду и получает ошибки 429. Какая техника защиты должна быть реализована на стороне клиента?
Anonymous Quiz
9%
Увеличить таймаут соединения
84%
Внедрить token bucket или leaky bucket на клиенте, ограничивая исходящий поток
6%
Увеличить количество потоков
2%
Перестать использовать API
Объяснение:

Что такое token bucket?
Это алгоритм, который контролирует скорость отправки запросов:
Корзина с токенами (например, 10 токенов).
Каждый запрос забирает 1 токен.
Корзина пополняется с заданной скоростью (например, 1 токен в 0.1 секунды).
Если токенов нет, запрос задерживается или отклоняется.

Leaky bucket — аналогичен, но ограничивает не пиковую скорость, а среднюю.

Почему это должен делать клиент?
Если клиент превышает лимиты API, он получит HTTP 429 («Too Many Requests») и может быть заблокирован. Клиент сам должен ограничивать свою нагрузку, чтобы не перегружать внешний сервис и не терять запросы.

Реальный пример
Twitter API ограничивает 300 запросов на 15 минут. Клиентские библиотеки (например, Tweepy) содержат встроенный token bucket. Без него приложение поймает 429 и упадёт.

Что должен зафиксировать аналитик
Требование: «На стороне клиента реализовать ограничение частоты запросов в соответствии со спецификацией API (token bucket)».
Параметры: максимальная скорость, размер корзины, стратегия при переполнении (блокировка, очередь).
Обработка ошибок 429: увеличение задержки (exponential backoff).

Вывод: Rate limiting — обязанность не только провайдера API, но и клиента. Аналитик должен включать это требование в спецификации интеграций.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4843 категория вопросов: #REQUIREMENTS
4843. Заказчик: «Система должна импортировать Excel-файл». Аналитик передал задачу разработчику. Импорт сломался из-за файла в 2 ГБ. Что аналитик упустил?
Anonymous Quiz
1%
Проверку формата файла
97%
Брейкдаун на нефункциональные требования: максимальный размер, скорость, формат, обработка ошибок
1%
Согласование с администратором
1%
Проверку антивирусом
2
Объяснение:

«Импортировать Excel» — функциональное требование, но без брейкдауна (декомпозиции) нельзя спроектировать решение. Аналитик обязан разбить на подвопросы:

Максимальный размер файла: 1 МБ или 2 ГБ? Это влияет на потоковую обработку (chunked) vs загрузка в память.
Форматы: 
.xlsx.xls.csv? Разные парсеры.
Скорость: импорт за 5 секунд или 5 минут?
Обработка ошибок: при неверной строке — откат всего импорта или пропуск с логом?
Многопоточность: можно ли обрабатывать несколько файлов параллельно?

Реальный кейс: Один аналитик не спросил про размер, разработчик загружал файл целиком в память. При 500 МБ сервер упал с OOM. Переделали на потоковый импорт.

Вывод: Любое общее требование должно быть разбито на проверяемые компоненты. Это ключевая техника системного анализа.
Please open Telegram to view this post
VIEW IN TELEGRAM
2
№4844 категория вопросов: #INTEGRATION
4844. Внешний сервис может присылать уведомления о событиях не мгновенно, а с задержкой до 5 минут. Какой способ получения событий обеспечит минимальную задержку?
Anonymous Quiz
5%
Polling каждую секунду
71%
Webhook (callback)
24%
Очередь сообщений с периодическим чтением
0%
Email-уведомления
Объяснение:

Webhook — это механизм, при котором внешний сервис сам отправляет HTTP-запрос на ваш endpoint в момент наступления события. Задержка минимальна (секунды). Polling — ваша система постоянно опрашивает сервис «есть ли новости?». Если опрашивать часто, растёт нагрузка; если редко — растёт задержка. Очередь с периодическим чтением тоже вносит задержку. Email — ещё медленнее. В задаче дано: внешний сервис может задерживать отправку до 5 минут, но внутри этого окна webhook — самый быстрый способ.

Реальный пример: Платёжные системы (Stripe, PayPal) используют webhook для оповещения о статусе платежа. Ваш сервер получает уведомление через секунды после оплаты, а не через минуты при polling.

Вывод: Если внешний сервис поддерживает webhook, это лучший вариант для получения событий в реальном времени. Аналитик должен уметь сравнивать webhook и polling в требованиях к интеграции.
Please open Telegram to view this post
VIEW IN TELEGRAM
В мае стало очевидно: digital снова штормит. AI-выдача давит классический трафик, воронки проседают, и выигрывают не самые опытные — а самые быстрые.

В такой момент решает не количество информации, а её качество.

Мы собрали папку тех, кто уже адаптируется, работает с цифрами и делится тем, что реально даёт результат.

Без шума. Только практика.
Если ты в маркетинге / digital / IT — это способ не выпасть из рынка.

Сохранить папку себе 📨
№4845 категория вопросов: #DBMS
4845. Проектируется каталог товаров, где у каждого товара разный набор атрибутов (телефоны: экран, память; книги: автор, издательство). Схема часто меняется. Какой тип БД предпочтителен?
Anonymous Quiz
24%
Реляционная с EAV (сущность-атрибут-значение)
62%
Документоориентированная NoSQL (MongoDB, Couchbase)
1%
Графовая БД
13%
Ключ-значение
Объяснение:

В реляционной БД для товаров с разным набором атрибутов пришлось бы использовать либо много колонок с NULL (жестко и негибко), либо EAV-модель (таблица «сущность-атрибут-значение»). EAV приводит к сложным запросам с множеством JOIN, падению производительности и нечитаемости. Документоориентированные БД (MongoDB, Couchbase) хранят каждый товар как отдельный JSON-документ, где атрибуты просто поля документа. Схема гибкая, можно добавлять новые атрибуты без миграций. Это идеально для каталогов, CMS, лидов в CRM.

Реальный пример: Интернет-магазины электроники используют MongoDB для каталога, чтобы легко добавлять новые характеристики (например, «наличие eSIM») без изменения схемы.

Вывод: Аналитик должен различать случаи: когда схема стабильна и известна — подходит SQL, когда схема часто меняется или вариативна — NoSQL.
Please open Telegram to view this post
VIEW IN TELEGRAM
№4846 категория вопросов: #REQUIREMENTS
4846. Заказчик говорит: «Система должна обрабатывать заказы очень быстро». Аналитик записывает это в требования. На приёмке заказчик недоволен, потому что заказ обрабатывается 2 секунды, а он ожидал 0.5 секунды. Что нужно было сделать аналитику?
Anonymous Quiz
0%
Передать требование архитектору
98%
Уточнить и зафиксировать цифры: время отклика, процентиль, объём данных
2%
Добавить в команду тестировщика производительности
0%
Попросить заказчика подождать следующей версии
Объяснение:

Слово «очень быстро» субъективно. Для одного заказчика 2 секунды — отлично, для другого — неприемлемо. Аналитик обязан перевести неопределённое пожелание в измеримые критерии. Например:
«95% запросов на создание заказа должны выполняться не более 500 мс при нагрузке 1000 RPS».

Без цифр разработчик ориентируется на свой опыт, тестировщик не может проверить, а на приёмке начинаются споры. Хороший аналитик задаёт уточняющие вопросы:

Какое максимальное время допустимо?
Какой процент запросов должен укладываться в это время (процентиль)?
При какой нагрузке?

Реальный кейс: В одном проекте «быстрая выгрузка отчёта» означала для заказчика 10 секунд, а разработчик сделал 2 минуты (думая, что это быстро). После внедрения конкретных цифр время сократили до 5 секунд, и заказчик принял работу.

Вывод: Любое расплывчатое требование о качестве (быстрота, надёжность, удобство) нужно превращать в числовые метрики. Это экономит часы споров и переделок.
Please open Telegram to view this post
VIEW IN TELEGRAM