[middle] SA | FM Logistic | WMS, микросервисы, Kafka, SQL

Компания: #fmlogistic
Уровень: #middle
Формат: #техсобес
Темы: #wms #логистика #микросервисы #kafka #sql #bpmn #use_case #api #integration #scrum #jira #confluence #data_modeling #аналитика

Как проходит собеседование:
Начинается с подробного разбора опыта кандидата — про проекты, роль аналитика и бизнес-контекст. Важно не просто “что делал”, а какую задачу решал бизнес.
Затем идет системный блок:
микросервисная архитектура
взаимодействие сервисов (Kafka, события), API и спецификации, SQL и моделирование БД
После — вопросы на мышление: дают ситуацию (например, рассинхронизация сервисов) и просят предложить решение.

❓Общие вопросы
➖Расскажи про проект (особенно бизнес-ценность)
➖Как унифицировали складской учет?
➖Как работал с разрозненными данными (номенклатура, артикулы)?
➖Кто был стейкхолдерами и как с ними взаимодействовал?
➖Как работал с задачами: откуда приходили и как декомпозировал?
➖Как взаимодействовал с заказчиком напрямую?

📦 Домен / логистика (опыт)
➖Как устроены складские операции (приемка, отгрузка, трансферы)?
➖Как фиксируются события (кладовщик, ТСД, система)?
➖Как работает инвентаризация (массовая vs циклическая)?
➖Как улучшали точность остатков (stock accuracy)?
➖Какие бизнес-проблемы решали (расхождения, ручной учет)?

🔗Архитектура / интеграции
➖Как устроена микросервисная архитектура?
➖Как сервисы взаимодействуют (синхронно vs асинхронно)?
➖Kafka: топики, консюмеры, обработка сообщений
➖Что такое Dead Letter Queue и зачем она нужна?
➖Как обеспечивается доставка сообщений?
➖Что происходит при рассинхронизации сервисов?

🛠Практический кейс
Есть 2 сервиса: один обработал сообщение, второй — нет
➖Как решать проблему рассинхронизации?
➖Как избежать ситуации, когда данные “разъехались”?
➖Что делать при несовместимых версиях API?
➖Как обеспечить консистентность данных?

🧩 Требования и артефакты
➖User story vs use case
➖Как описываешь требования (структура, детализация)?
➖Когда используешь BPMN?
➖Нужно ли строго соблюдать нотации или можно упрощать?
➖Как документируешь API (вход/выход, маппинг, sequence)?
➖Работа с Confluence / Jira

🗄 Базы данных / SQL
➖Какие запросы писал (join, group by, subquery)?
➖Как проектировал БД (связи, ключи)?
➖Что такое индексы и зачем они нужны?
➖Как оптимизировали медленные запросы?
➖Нормализация vs денормализация (когда нарушать правила)?

🤝 Работа с людьми
➖Как работаешь со сложными стейкхолдерами?
➖Что делать, если заказчик “сливается”?
➖Как добываешь требования без помощи лида/PM?
➖Как готовишься к интервью с бизнесом?

⚠️ Где будет сложно
🟤много вопросов именно про бизнес-суть, а не только технику
🟤глубокая проверка микросервисного мышления (Kafka, события)
🟤кейсы на консистентность данных
🟤могут копать в SQL и моделирование глубже, чем ожидаешь

🎯 Что полезного в этой записи
Это хороший пример middle SA/BA собеседования, где проверяют:
понимание реального бизнеса (WMS), умение работать в микросервисной архитектуре, способность думать, а не воспроизводить теорию

👀 Кому смотреть
junior — понять, какой разрыв до middle;
middle — прокачать архитектуру, Kafka и кейсы на консистентность.

Полная запись на Boosty.

[middle] SA | Комрадес Девс | интеграции, Kafka/RabbitMQ, API, UML, SQL

Компания: #комрадес_девс
Уровень: #middle
Формат: #техсобес
Темы: #REST #Kafka #RabbitMQ #интеграции #SQL #ERD #UML #user_story #use_case #API #архитектура #синхронность #асинхронность #Agile #Scrum #реальный_уровень

Как проходит собеседование:
Начинается с подробного разбора опыта кандидата: проекты, роли, артефакты, взаимодействие с командой. Затем идут ситуационные вопросы — конфликты, работа с требованиями, коммуникация с бизнесом. Основной упор — на интеграции и архитектурное мышление. В конце дают практические кейсы (интернет-магазин, оффлайн-режим) и обсуждают инструменты.

🧩 Общие вопросы
➖Чем занимался на проектах?
➖Какие артефакты писал?
➖Как взаимодействовал с командой и бизнесом?
➖Как решаешь конфликты с разработчиками?
➖Что делаешь, если требования неясные или противоречивые?

📄 Требования и артефакты
➖Как описываешь User Story и Use Case?
➖Какая структура у Use Case?
➖Какие диаграммы используешь (ER, UML)?
➖Как документируешь API?
➖Какие шаблоны требований применяешь?

🔋 Интеграции / брокеры
➖Когда использовать синхронное взаимодействие?
➖Когда асинхронное?
➖Как работают брокеры сообщений?
➖Разница Kafka и RabbitMQ?
➖Когда что выбрать?
➖Что происходит с сообщениями после чтения?

🏗 Архитектура / кейсы
➖Как спроектировать цепочку заказа (сайт → банк → склад → доставка)?
➖Как обрабатывать ошибки в распределенной системе?
➖Как логировать и восстанавливать процессы?
➖Как реализовать систему при плохом интернете (оффлайн-first)?
➖Как синхронизировать локальную и центральную системы?

📑 Базы данных
➖Какую БД выбрать для локального решения?
➖Как хранить и синхронизировать данные?
➖Как организовать очередь и обработку сообщений?

⚠️ Где будет сложно
Основная сложность — не в терминах, а в применении:
асинхронная архитектура,
🟤выбор между Kafka/RabbitMQ,
🟤проектирование цепочек,
🟤обработка ошибок,
🟤оффлайн-сценарии. Интервьюер проверяет, насколько кандидат понимает реальные кейсы.

🎯 Что полезного в этой записи
Хороший пример собеседования с упором на практику: кейсы (интернет-магазин, оффлайн-производство), проверка системного мышления и умения договариваться с бизнесом и разработкой.

👀 Кому смотреть
junior — чтобы понять реальные ожидания от middle;
middle — чтобы прокачать архитектурное мышление и интеграции перед собеседованием.

Полная запись на Boosty.