BA & SA | 10000 Interview questions

До 40% годовых на быстрорастущих IT-компаниях Фонд «Финам и БСФ: Новые чемпионы» открывает возможность инвестировать в быстрорастущие ІТ компании на стадии активного роста. Это шанс войти в капитал компаний до того, как они станут звездами ІРО. ✅ Почему это интересно? - Доходность: до 40% годовых за счет роста стоимости компаний - Ликвидность: паи будут торговаться на бирже, что позволит свободно покупать и продавать их в любое время - Регулярные выплаты: выплаты в размере 50% от прибыли фонда производятся каждые 6 месяцев - Эксклюзивность: доступ к закрытым сделкам, которые обычно недоступны частным инвесторам - Экспертиза: Опытная команда берет на себя глубокий анализ, развитие компаний и максимизацию вашей прибыли 💰 Успейте войти в капитал лидеров будущего! Подать заявку Финансовые услуги оказывает: АО «ФИНАМ». #реклама funds.finam.ru О рекламодателе

№4749 категория вопросов: #BA #SYSTEMDESIGN

Курс для тех, кто хочет не только работать, но и жить Погружены в задачи 24/7, и даже если делегируете, то всё равно всё продолжаете контролировать? Предлагаем вместе найти баланс, чтобы всё успевать и при этом не выгорать. Справочная, бизнес-медиа банка Точка, запустила бесплатный онлайн-курс «Тайм-менеджмент без огня и стресса». Из курса узнаете, как сместить фокус с достигаторства на бережное отношение к себе и расстановку приоритетов. Поймёте, что мешает сосредоточиться на задачах, как составлять выполнимое расписание и не терять в эффективности. Уроки подготовили сооснователь SETTERS Евгений Давыдов, CEO сервиса «Фитмост» Александра Герасимова, коуч ICF Юрий Мурадян и серийная предпринимательница Наталья Олина. Запишитесь на курс и получите полезные подарки, чек-листы и готовые шаблоны для распределения задач. Зарегистрироваться #реклама 16+ allo.tochka.com О рекламодателе

🧑‍🎓Объяснение:| Это классическая задача выбора индексов под разные паттерны запросов. Ошибка здесь — попытка одним индексом закрыть оба запроса. 1. Анализ запросов Запрос 1: WHERE user_id = ? AND order_date > ... Условия: равенство по user_id + диапазон по order_date Оптимальный индекс: составной (user_id, order_date) Сначала фильтруем по user_id (равенство) Затем сканируем диапазон по order_date внутри одного пользователя Индекс покрывает оба условия Запрос 2: WHERE order_date = ? Условие: только равенство по order_date Оптимальный индекс: одиночный (order_date) 2. Почему один индекс не работает? ❌ A (только user_id): Запрос 1: находит все заказы пользователя (быстро), но потом фильтрует по дате в памяти (медленно, если у пользователя много заказов). Запрос 2: вообще не использует индекс (поиск по дате неэффективен). ❌ B (только order_date): Запрос 2: работает быстро. Запрос 1: находит все заказы за неделю (всех пользователей), потом фильтрует по user_id в памяти — при большой базе это катастрофа. ❌ D (составной (order_date, user_id)): Запрос 2: работает быстро (order_date в начале). Запрос 1: сначала фильтрует по диапазону дат (находит миллионы записей за неделю), потом по user_id — эффекта нет, так как дата стоит первой. 3. Почему C — правильный ответ Два индекса: (user_id, order_date) — идеально покрывает первый запрос. (order_date) — идеально покрывает второй запрос. Да, это дополнительные затраты на запись (каждый индекс замедляет вставку/обновление), но это разумный компромисс между производительностью чтения и записи. 4. Реальный кейс В интернет-магазине после добавления составного индекса (user_id, order_date) время выполнения отчёта по истории заказов пользователя сократилось с 8 секунд до 50 миллисекунд. А запросы по дате работали через отдельный индекс. 5. Дополнительный нюанс: покрывающий индекс Если в SELECT только id и order_date, индекс (user_id, order_date) становится покрывающим (covering index) — СУБД может ответить на запрос, читая только индекс, без обращения к таблице. Это ещё больше ускоряет запрос. 6. Вывод для аналитика Аналитик не должен писать индексы сам, но обязан: Понимать, какие запросы самые частые и критичные. Знать, что для запросов с разными условиями нужны разные индексы. Фиксировать в требованиях к производительности ожидаемое время выполнения. Нельзя одним индексом «накрыть» все запросы. Это одна из частых причин падения производительности в проде. 🎯

Премии больше не работают! Что дальше? Материальная мотивация не гарантирует лояльность и драйв в команде. И это не проблема людей. Это ошибка в управлении, когда путают два понятия: 💰 Мотивация — это внешняя сделка: «ты — работа, я — деньги». ❤️ Вовлечённость — это внутренний драйв: «я верю в то, что делаю, и вижу, как мои цели сходятся с целями компании». Это то, что нельзя купить, но можно построить. Те руководители, кто уже прошли этот путь, делают иначе. Например, Виктор Гор, основатель 18 бизнесов, отказался от KPI. Вместо этого он помогает сотрудникам достигать личных целей — купить квартиру, съездить в отпуск — через рост компании. Сегодня в Школе Генерального директора открыт доступ к новому курсу MBA. Вы научитесь создавать системы, где люди включаются сами. Получите гостевой доступ к курсу. Узнать больше #реклама 16+ mba-upravlenie-kompaniei.school.gd.ru О рекламодателе

№4748 категория вопросов: #SQL

Как сэкономить на путешествии 50 000 ₽ Яндекс Путешествия выкатили вау-промокод на жильё — TELEGA. Скидка 25% (максимум 50 000 ₽) сработает, если забронировать отдых на март. Поспешите! Жирный промик действует только до 22 марта. Если вы ждали знак от Вселенной — это он. Пора отдохнуть! Забронировать #реклама travel.yandex.ru О рекламодателе

🧑‍🎓Объяснение: Это классический выбор между синхронным и асинхронным взаимодействием, когда критически важна надёжность доставки и слабая связанность систем. 1. Почему очередь (брокер сообщений) — лучшее решение? Брокер сообщений (Kafka, RabbitMQ, AWS SQS) предоставляет: Гарантированную доставку: сообщение сохраняется на диске брокера и будет доставлено, даже если потребитель (система лояльности) временно недоступен. Подтверждения (acknowledgments): потребитель явно подтверждает обработку; если он упал или не ответил, сообщение возвращается в очередь. Персистентность: данные не теряются при перезапуске брокера. Независимость: CRM не ждёт ответа от системы лояльности, пользователь не видит задержек. 2. Почему синхронный REST с retry (A) — хуже? При длительной недоступности системы лояльности CRM будет исчерпывать попытки и либо терять данные (если нет fallback), либо задерживать ответ пользователю. Повторные попытки создают дополнительную нагрузку на CRM и внешнюю систему. Retry не спасает, если система лояльности недоступна часы — сообщения всё равно не доставятся, если не сохранять их локально. В CRM нужно реализовывать сложную логику хранения "отложенных" записей. 3. Почему прямая запись в общую БД (C) — антипаттерн? Создаёт жёсткую связь: CRM должна знать структуру БД системы лояльности. Нарушает инкапсуляцию данных — изменение схемы в одной системе ломает другую. Транзакции между разными БД практически невозможны (распределённые транзакции — зло). Конкуренция за доступ к данным, блокировки, проблемы с масштабированием. 4. Почему FTP (D) — устаревшее и ненадёжное решение? Высокая задержка (периодические выгрузки). Нет гарантии доставки: файл может быть повреждён, не доставлен, обработан частично. Сложность обработки ошибок и дублирования. Отсутствие мониторинга в реальном времени. 5. Реальный кейс из практики Крупный ритейлер использовал синхронный REST для передачи данных о новых клиентах в маркетинговую систему. При падении маркетинговой системы новые клиенты просто не попадали в базу для рассылок. Потери конверсии составили 15% за месяц. После внедрения RabbitMQ с очередью new_customers проблема исчезла: CRM публикует события, маркетинговая система забирает их, когда готова. При длительном простое сообщения накапливаются в очереди и обрабатываются после восстановления. 6. Что должен заложить аналитик в требования? Тип интеграции: асинхронная, событийно-ориентированная. Брокер сообщений с поддержкой персистентности и подтверждений. Политика повторных попыток на стороне потребителя (если нужно). Мониторинг глубины очереди и алертинг при накоплении. Идемпотентность обработки (на случай дублирования сообщений). Схема данных (контракт) в формате JSON/Avro/Protobuf. 7. Профессиональный нюанс Если объём данных очень велик (миллионы клиентов в день), стоит рассмотреть Kafka с её высокой пропускной способностью и долгим хранением. Для умеренных нагрузок подойдёт RabbitMQ. Важно также продумать retention в очереди: сколько времени хранить сообщения, если потребитель надолго упал. 8. Вывод Выбор паттерна интеграции определяется требованиями к надёжности, задержкам и связанности. Для критичных данных, которые нельзя терять, асинхронная очередь с гарантированной доставкой — промышленный стандарт. Аналитик, предлагающий такое решение на этапе проектирования, предотвращает будущие потери бизнеса. 🎯

Бот для аудита, юнита, рекоменаций по товарам WB/Ozon ТГ-бот mpsovet подключается по API, раз в сутки обновляет данные и выдаёт: аудит за последние 8 недель, рекомендации по товарам, unit-экономику, ДРР по каждому товару и расчёт поставки. Скачали файл — сразу видно, где просадка и что править в первую очередь. Рекомендации по каждому товару. Узнать больше #реклама 16+ О рекламодателе

№4747 категория вопросов: #INTEGRATION

Как понять, что бизнес будет успешным? Составьте финансовую модель. Как это сделать рассказывает бизнес-медиа банка Точка Справочная в новом бесплатном курсе «Финансовая модель бизнеса для новичков». Эксперт уроков — серийный предприниматель и автор телеграм-канала «Стартап дня» Александр Горный. Он объяснил, как самостоятельно составлять финмодель, как она поможет бизнесу расти и привлекать инвестиции, а ещё поделится готовыми шаблонами для популярных бизнесов. Программу курса смотрите на карточке к посту, а записаться можно по ссылке ниже. Курс бесплатный, с вечным доступом и подарками от Точки и Александра. Зарегистрироваться #реклама 0+ allo.tochka.com О рекламодателе

Привет, друзья! ИИ, нейросети и IT — в одной папке Мы собрали папку с каналами для тех, кто хочет применять ИИ системно и получать реальный результат. Внутри папки:

🔵нейросети: GPT, DeepSeek, OpenAI, LLaMA, Grok — практические кейсы и сравнения 🔵промпты и ИИ-агенты под конкретные задачи 🔵сборка ИИ-систем и автоматизация процессов 🔵ИИ-боты и ассистенты для бизнеса и экспертов 🔵ускорение работы и рост результатов ×2 🔵карьера в IT и AI, актуальные технологии и тренды

➕ Все каналы про ИИ, нейросети и технологии — в одной папке по ссылке ниже 👉 https://t.me/addlist/UIH6U0ZP4yVjZjQ6 Хочу добавить свой канал в папку

🧑‍🎓Объяснение: Это классическая проблема обработки "зависших" сообщений в очередях, которая приводит к блокировке бизнес-процессов и потерянным заказам. 1. Что происходит в описанной ситуации? Сообщение о новом заказе попадает в очередь. Потребитель (сервис доставки) пытается обработать его, но внешний сервис недоступен. В зависимости от настроек, сообщение может: Оставаться в очереди и повторно пытаться обработаться снова и снова (блокируя другие сообщения, если очередь FIFO). "Зависнуть" в состоянии "в обработке" (если не настроен таймаут и механизм повторной постановки). Бесконечно ретраиться, создавая нагрузку на систему. 2. Как работает Dead Letter Queue (DLQ)? DLQ — это отдельная очередь для сообщений, которые не могут быть обработаны после нескольких попыток. Типичная схема: Сообщение попадает в основную очередь (например, orders). Потребитель пытается обработать его. Если возникает ошибка (сервис недоступен), сообщение возвращается в очередь с указанием задержки перед следующей попыткой. После N неудачных попыток (например, 3) сообщение автоматически перемещается в DLQ (orders_dlq). Основная очередь продолжает обрабатывать новые сообщения без блокировки. Администраторы или отдельный процесс анализируют сообщения в DLQ и принимают меры (исправляют ошибку, обрабатывают вручную, перекладывают обратно). 3. Почему другие варианты не работают? ❌ A (увеличить потребителей): Если сообщение "зависло" и бесконечно ретраится, добавление новых потребителей только ускорит цикл бесполезных попыток. Проблема не в пропускной способности, а в логике обработки ошибок. ❌ C (синхронные вызовы): Переход на синхронное взаимодействие (HTTP напрямую) создаст прямую зависимость. При недоступности внешнего сервиса упадут и заказы пользователей. Очередь как раз нужна для буферизации и отказоустойчивости. ❌ D (таймауты): Таймауты — это часть решения, но они не предотвращают зацикливание. Сообщение всё равно будет бесконечно возвращаться в очередь, даже с таймаутом. Нужен механизм исчерпания попыток и изоляции проблемных сообщений. 4. Реальный кейс из практики Крупный маркетплейс использовал RabbitMQ для передачи заказов в службу доставки. Однажды внешний сервис доставки "лёг" на 3 часа. Все сообщения о новых заказах начали бесконечно ретраиться, заблокировав очередь. Новые заказы не могли попасть в обработку, потому что очередь была забита "зависшими" сообщениями (в режиме FIFO). После восстановления сервиса пришлось вручную чистить очередь и разбираться с потерянными заказами. Что сделали: Внедрили DLQ с политикой: 3 попытки с интервалами 1, 5, 15 минут. После 3-й неудачи сообщение уходит в DLQ. Отдельный микросервис мониторит DLQ и при восстановлении внешнего сервиса автоматически перекладывает сообщения обратно в основную очередь. 5. Как это должно быть описано в требованиях? Аналитик обязан заложить в требования к интеграции: Повторные попытки (retry policy): Максимальное количество попыток: 3 Интервалы: экспоненциальная задержка (1с, 5с, 30с) Dead Letter Queue: После исчерпания попыток сообщение перемещается в DLQ Для DLQ настроен мониторинг и алертинг Предусмотрен механизм ручного или автоматического возврата сообщений из DLQ после устранения проблемы 6. Дополнительные нюансы Идемпотентность: Важно, чтобы повторные попытки не приводили к дублированию операций (например, повторному списанию денег). Потребитель должен быть идемпотентным. Типы ошибок: Не все ошибки требуют ретраев. Например, ошибка валидации (400) — сообщение нужно сразу отправлять в DLQ или в отдельную очередь "некорректных данных". Мониторинг: DLQ должна быть под наблюдением. Накопление сообщений в DLQ — сигнал к немедленному реагированию. 7. Профессиональный вывод DLQ — это не просто "техническая деталь", а критический элемент отказоустойчивой архитектуры. Аналитик, проектирующий интеграции, обязан: Понимать разницу между временными и фатальными ошибками. Закладывать политику повторных попыток и механизм изоляции проблемных сообщений. Учитывать влияние "зависших" сообщений на бизнес-процессы.

«Нейросети для руководителя» новый курс от Школы Гендира Научитесь встраивать ИИ в управление, продажи, производство и маркетинг. ⚡ Разбираем кейсы действующих директоров из разных сфер – каждый из них уже получил измеримые результаты с помощью ИИ: ✅ Производство и качество Алексей Оносов («Юнисофт Принт», выручка 170 млн руб.) покажет, как с помощью компьютерного зрения снизить брак с 3% до нуля. ✅ Тяжелая промышленность и риск-менеджмент Андрей Чернышев (Simple Company, клиенты — Газпром и Лукойл) объяснит, как прогнозировать техногенные риски и зачем он отказался от отдела маркетинга, сэкономив 30% бюджета. ✅ Производство и e-commerce Владимир Мамут (Lucky Child, топ-3 бренд одежды для новорожденных) покажет, как ИИ в реальном времени мониторит воронку продаж, оценивает звонки менеджеров и сам сигнализирует о сбоях. Узнать больше Есть противопоказания. Посоветуйтесь с врачом. #реклама 16+ gd.ru О рекламодателе

№4746 категория вопросов: #INTEGRATION

Гайд для L&D и директоров корпоративных университетов Узнайте, как корпоративному университету оптимизировать расходы, улучшить усвоение новых знаний сотрудниками и выпускать больше контента без расширения штата. ✅ Еще узнаете из гайда, как: - Сократить отток новичков на испытательном сроке; - Увеличить количество учеников и обучающих программ без дополнительной нагрузки на тренеров; - Снизить затраты на организацию обучения без сокращения штата. В гайде собраны прикладные советы от экспертов «Джалинга» и клиентов, которые регулярно записывают обучающий контент в студии. Также собрали кейсы Lamoda, Мегафон и Harat's School, которые оснастили свои учебные центры видеостудией «Джалинга». 🎓Скачайте гайд на сайте. Скачать #реклама 16+ jalinga.ru О рекламодателе