BA & SA | 10000 Interview questions

ХОЧЕШЬ ИДТИ В НОГУ С ТЕХНОЛОГИЯМИ ?! … или наблюдать, как другие зарабатывают на ИИ? - РЕШАТЬ ТЕБЕ !

ИИ станет твоим главным инструментом, а не загадкой 🗝
Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️

Что внутри? Только лучшее из Мира IT & AI :
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
👉 Делимся знаниями и аудиторией - растём вместе ⚡️ 📂 Забирай ПАПКУ с ТОП ИИ Каналами бесплатно

Отписаться можно в любой момент. Остаться — тоже ✔️

Тссс! Не спугни 🤫

Дорогие зрители, на вашем экране удивительное интернет-явление — лучшие IT и AI каналы собрались в группу и готовы поделиться своей полезностью

Новости из мира IT
Нейросети
Реальные кейсы из практики
Вакансии

Все это, и не только, вы можете увидеть по ссылке! Забирайте пользу, пока каналы не разбежались https://t.me/addlist/qI7aaJx4U5s5MjQy

☀Объяснение:

Что такое Service Mesh?
Service Mesh — это выделенный инфраструктурный слой, который управляет коммуникацией между микросервисами. Обычно он реализован как набор прокси (sidecar-контейнеров), запускаемых вместе с каждым сервисом. Все сетевые вызовы между сервисами проходят через эти прокси, которые обеспечивают:

Безопасность: автоматическое шифрование mTLS между сервисами.
Наблюдаемость: сбор метрик (latency, error rate, traffic) и распределённая трассировка без изменения кода.
Управление трафиком: канареечные релизы, A/B‑тестирование, процентное распределение трафика между версиями.
Отказоустойчивость: таймауты, повторные попытки, circuit breaker на уровне сетевых вызовов.

Чем Service Mesh отличается от API Gateway?
API Gateway (A) — это точка входа для внешних клиентов (мобильные приложения, браузеры). Он работает на периметре системы.
Service Mesh работает внутри кластера, управляя взаимодействием между внутренними сервисами.
Они не заменяют, а дополняют друг друга.

Реальный пример:
В крупных компаниях (Google, Lyft, PayPal) используют Istio или Linkerd для управления микросервисами. Это позволяет им безопасно выкатывать новые версии и быстро откатывать при проблемах без передеплоя кода.

Что должен зафиксировать аналитик:
«При большом количестве микросервисов и требованиях к безопасности, наблюдаемости и гибкому управлению трафиком, использовать Service Mesh».
«Service Mesh должен обеспечивать mTLS, сбор метрик, трассировку и поддержку канареечных релизов».

Вывод: Service Mesh — это стандарт для микросервисных систем, который решает проблемы сетевого взаимодействия без изменения кода. Аналитик, знающий этот паттерн, может рекомендовать его как инфраструктурный слой для сложных распределённых систем.

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

☀Объяснение:

Event Sourcing — это паттерн, при котором все изменения состояния системы сохраняются как последовательность событий (event log). Вместо того чтобы хранить только текущее состояние сущности (например, заказ с полем status), вы записываете каждое событие: OrderCreated, PaymentReceived, OrderShipped, OrderCancelled. Текущее состояние вычисляется путём повторного применения всех событий к начальному состоянию (или через снимки состояния + дельта событий).

Ключевые преимущества:
Полный аудит – есть журнал всех изменений, можно ответить на вопрос «кто и когда изменил это поле».
Восстановление на любой момент времени – можно «перемотать» состояние к любой временной точке, повторно применив события до нужного момента.
Отладка и анализ – можно воспроизвести сценарий на тестовом окружении, чтобы найти причину ошибки.
Гибкость – можно строить разные read-модели (CQRS) на основе одного и того же потока событий без изменения источника.

Почему не подходят другие варианты:
A (CQRS) – разделяет команды и запросы, но может работать без Event Sourcing (например, на основе обычной БД).
B (Saga) – паттерн для распределённых транзакций, не про хранение истории.
D (Strangler Fig) – стратегия замены монолита на микросервисы, не имеет отношения к хранению изменений.

Реальный пример:
В банковских системах Event Sourcing используется для хранения всех транзакций по счёту. Это позволяет восстановить баланс на любую дату и обеспечить детальный аудит для регулятора.

Что должен зафиксировать аналитик:
«Для сущностей, требующих полного аудита и восстановления состояния на любой момент времени, использовать Event Sourcing».
«Хранить события в неизменяемом хранилище (например, Kafka, Event Store)».
«Реализовать проекции для построения текущего состояния».

Вывод: Event Sourcing — это стандарт для систем, где важна история изменений и возможность отката/аудита. Аналитик, закладывающий этот паттерн в требования, даёт команде мощный инструмент для обеспечения прозрачности и надёжности.

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

☀Объяснение:

Проблема:

При изменении API (например, добавление нового поля delivery_date или изменение структуры ошибок) клиентское приложение должно продолжать работать корректно. Модульные тесты проверяют отдельные функции изолированно и не выявят проблемы с форматом ответа от сервера. Системное тестирование проверяет систему в целом (сквозные сценарии), но оно дорогое и медленное. Приёмочное тестирование проводится с заказчиком и тоже не является первым шагом.

Интеграционное тестирование проверяет взаимодействие между двумя компонентами (клиент ↔️ сервер). В данном случае оно идеально: вы поднимаете тестовый экземпляр бэкенда с новой версией API, отправляете запросы от клиента (или эмулируете их) и проверяете, что клиент правильно парсит ответы, обрабатывает ошибки, не падает при неожиданных данных. Интеграционные тесты дают быструю обратную связь без запуска всей системы.

Реальный пример:
В Uber при обновлении API для водительского приложения сначала запускают интеграционные тесты, чтобы убедиться, что новое поле rating корректно отображается и не ломает старый код.

Что должен зафиксировать аналитик:
«При изменении контракта API обязательно проводить интеграционное тестирование на тестовом стенде до выкатки в прод».

Вывод: Интеграционное тестирование – наиболее подходящий уровень для проверки совместимости клиента и сервера при изменении API, так как оно фокусируется на коммуникации без лишней сложности.

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

🆕Дайджест новостей:
На связи канал "Инновационный советник". 👥 Достижения на сегодняшний день:

1️⃣масштабирование одного из крупнейших технопарков страны;
2️⃣привлечение за последние два года более 20 инновационных предприятий;
3️⃣увеличения количества производственных площадей более чем в три раза;
4️⃣создание Ассоциации технопарков и субъектов инновационной деятельности, ранее не существовавшей в стране;
5️⃣проведение конкурсов стартап-проектов, в том числе в IT-cфере в партнерстве с крупнейшими научно-технологическими площадками страны!

🚀 Как этого достигнуть?

Читайте продолжение в канале "Инновационный советник".

⚡️ Согласны, что образование — это инвестиция, а не просто трата времени?

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

Но что, если сделать ваш процесс обучения стратегическим?

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

💎 Что внутри? Ваша личная команда для интеллектуального роста:
• Навигаторы по знаниям — помогут выстроить персональную траекторию обучения: от выбора актуальных курсов до глубокого погружения в профессию.
• Методологи и эксперты — научат учиться эффективно, структурировать информацию и применять знания на практике, а не просто собирать «дипломы в стол».
• Научные обозреватели — разберут сложные тренды и инновации простым языком, чтобы вы всегда были на шаг впереди.
• Источники мотивации — поддержка и сообщество единомышленников, которые не дадут опустить руки, когда объем новой информации кажется пугающим.

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

🚀 Успевайте забрать папку себе и внедрить новые знания в свою жизнь:
👉 https://t.me/addlist/z9mEu_W2Vb82YTgy

*(Внимание: через 3 дня ссылка станет недоступной)*

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

А в умении работать с ИИ.

Я собрал экспертов по искусственному интеллекту.
Там — полезные инструменты, реальные кейсы и всё самое
интересное.

Добавляйте экспертов 👇🏻
https://t.me/addlist/fnSvEbEp85U4YzQy

ИИ vs ЧЕЛОВЕК / AI УЖЕ МНОГОЕ УМЕЕТ, НО НЕ ТАК КАК ТЫ ...

Нейросети уже пишут, рисуют и отвечают 24/7. Это мощно, и мы за прогресс. Но есть вещи, которые алгоритмы никогда не заменят:
— эмпатию к клиенту
— доверие, которое строится годами
— продажи без манипуляций, с душой

⚠️ Технологии — это инструмент, а главное — это ты и твой живой контакт.

Приглашаем тебя в ЭКО-Пространство, где технологии — это фон, а главное — это ты и твой клиент ✔️ В этой ПОДБОРКЕ есть кое-что поважнее алгоритмов — ДОВЕРИЕ. В папке собраны каналы про экологичные продажи, про понимание, про рост без выгорания.

Пусть ИИ пишет тексты, а ты учись создавать отношения. 💚

Добавляй папку в свой актив и делись с друзьями! 📌
Ссылка ➡️ https://t.me/addlist/9wQJPILNMKNkNmNk
👉 Делимся знаниями и аудиторией — растём вместе ⚡️

Gemini vs ChatGPT: СМЕНА ФАВОРИТОВ ... вот что вышло 👇

* Все вокруг обсуждают ChatGPT, а я нашел альтернативу, которая реально качает — Gemini от Google. Пользуюсь и очень доволен.

Почему стоит попробовать:
✔️ Бесплатно (базовая версия)
✔️ Контекст 2 млн токенов — загружайте хоть целые кодобазы
✔️ Понимает текст, картинки, видео и аудио
✔️ Дружит с Google Диском, Gmail и календарем
✔️ Код пишет на уровне топ-моделей

Решил проверить его в деле — и не прогадал. Попросил Gemini найти для меня экспертные каналы по IT и AI, чтобы собрать чистое инфополе с нуля и не делать все вручную. Закинул ссылки на проверенных авторов, и нейросеть сама проанализировала сотни рекомендаций, отсеяв пустышки.

Результат — готовая подборка из 20+ каналов с реальным опытом по: AI-воркфлоу, автоматизации, вайб-кодингу, промт-инжинирингу, RAG-системам, нейрогенерации, крипте и др.

🔗 Забирайте список в один клик 👇
https://t.me/addlist/9wQJPILNMKNkNmNk

* Пишите в комменты — пробовали Gemini? Делитесь с друзьями впечатлениями и добавляйте подборку в свой актив 📌

☀Объяснение:

Проблема с немедленными повторами:
Если внешний API временно перегружен или восстанавливается после сбоя, множество клиентов, увидев ошибку, начнут повторять запросы одновременно. Это создаёт «шторм повторных попыток» (retry storm), который ещё сильнее перегружает сервис и затягивает его восстановление. Фиксированная задержка (например, 1 секунда) синхронизирует все повторы, создавая пиковые всплески нагрузки.

Что такое экспоненциальная задержка с джиттером:
Экспоненциальная задержка (Exponential Backoff) – интервал между повторами увеличивается в геометрической прогрессии: 1с, 2с, 4с, 8с, 16с. Это даёт внешнему сервису время на восстановление и разносит пики нагрузки во времени.
Джиттер (Jitter) – добавление случайного небольшого смещения (например, ±30%) к каждой задержке. Это предотвращает синхронизацию повторов от разных клиентов. Например: 1.2с, 2.5с, 3.8с, 9.1с вместо строгих 1, 2, 4, 8.
Пример реализации (Python):
python

import time, random

def call_with_retry(func, max_retries=5, base_delay=1):
    for attempt in range(max_retries):
        try:
            return func()
        except Exception:
            if attempt == max_retries - 1:
                raise
            delay = (base_delay * (2 ** attempt)) + random.uniform(0, 0.5)
            time.sleep(delay)

Сравнение с другими вариантами:
A (фиксированная задержка) – приводит к синхронизированным пикам нагрузки, создаёт retry storm.
C (единственный повтор через 10 секунд) – недостаточно надёжен для кратковременных сбоев, не даёт шансов на восстановление.
D (без повторов) – снижает надёжность системы, пользователь получает ошибку даже при временной проблеме.

Реальный пример:
AWS SDK для вызовов к S3 и DynamoDB реализует экспоненциальный backoff с джиттером по умолчанию. Stripe также рекомендует эту стратегию для обработки временных ошибок.

Что должен зафиксировать аналитик:
«При интеграции с внешними сервисами использовать повторные попытки с экспоненциальной задержкой и джиттером».
«Максимальное количество попыток — не более 5».
«После исчерпания попыток — помещать сообщение в Dead Letter Queue (DLQ) для ручного разбора».

Вывод: Экспоненциальный backoff с джиттером – это отраслевой стандарт для отказоустойчивых интеграций, предотвращающий перегрузку внешних систем и повышающий вероятность успешной обработки запроса.

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