ЧЕКЛИСТ СИСТЕМНОГО АНАЛИТИКА: КАК ПРОЙТИ СОБЕСЕДОВАНИЕ ОТ JUNIOR ДО SENIOR. ЧАСТЬ 1 — ИНТЕГРАЦИИ
====================================================================================================
Я три года провожу собеседования и сам через них прошёл. Вот что реально спрашивают у системного аналитика — от первого вопроса джуниора до задач, которые ставят в тупик мидла.
Это первая часть серии из четырёх постов. Каждый пост — отдельный блок знаний с конкретными вопросами и ответами. Сегодня разбираем интеграции: REST API, SOAP, синхронное и асинхронное взаимодействие, брокеры сообщений, версионирование.
Сохрани серию целиком — пригодится за неделю до собеседования.
────────────────────────────────────────
▶ Почему интеграции — это первое что проверяют
Системный аналитик описывает контракты между системами. Без понимания интеграций ты не сможешь написать техническое задание, которое реально исполнят разработчики. Поэтому на каждом уровне — от джуниора до сеньора — этот блок присутствует обязательно.
────────────────────────────────────────
▶ Уровень Junior
На этом уровне проверяют базу: понимаешь ли ты, что такое контракт API и из каких типов данных он состоит.
Что спрашивают:
• Назови основные типы данных в REST API.
Ответ: string, integer, boolean, date/datetime, array, object. Уметь назвать — это минимум. Уметь объяснить зачем каждый тип — это уже плюс.
• Как описать контракт REST в таблице?
Ответ: таблица контракта содержит поля — название параметра, тип данных, обязательность, пример значения, описание. Такую таблицу ты будешь писать каждый день работы.
• Что такое SOAP?
Ответ: SOAP — это протокол обмена сообщениями, который использует XML и описывает интерфейс через WSDL (Web Services Description Language). SOAP строже REST: у него фиксированная структура конверта, обязательные заголовки, строгая типизация.
────────────────────────────────────────
▶ Уровень Middle
Здесь уже нужно понимать разницу между подходами и объяснять выбор.
Что такое идемпотентность? Это один из самых частых вопросов на мидл-уровне.
Идемпотентность — свойство операции, при котором повторный вызов с теми же параметрами даёт тот же результат, что и первый. Простыми словами: можно вызвать сколько угодно раз — ничего лишнего не произойдёт.
• GET — идемпотентен. Запрашиваешь данные, ничего не меняется.
• PUT — идемпотентен. Обновляешь ресурс, повторный PUT даст тот же результат.
• DELETE — идемпотентен. Удалил один раз — повторное удаление ничего не изменит.
• POST — НЕ идемпотентен. Каждый вызов создаёт новый ресурс.
CRUD и HTTP методы:
• Create = POST
• Read = GET
• Update = PUT (полное обновление) / PATCH (частичное)
• Delete = DELETE
REST vs SOAP простыми словами:
REST — это стиль архитектуры, работает через HTTP, передаёт данные в JSON (чаще всего). Легковесный, гибкий, стандарт де-факто для публичных API.
SOAP — протокол с жёсткими правилами. XML везде, WSDL для описания, встроенная поддержка транзакций и безопасности. Используется в банках, корпоративных системах, там где нужна строгая формальность.
Синхронное vs асинхронное взаимодействие:
Синхронное — клиент отправил запрос и ждёт ответа. Как телефонный звонок: ты говоришь, тебе отвечают прямо сейчас.
Асинхронное — клиент отправил сообщение и пошёл заниматься своим делом. Ответ придёт потом. Как электронная почта.
Брокеры сообщений — Kafka, RabbitMQ:
Брокер — это посредник, который принимает сообщения от отправителей и доставляет получателям.
Point-to-Point (очередь): одно сообщение — один получатель. Отправил задачу в очередь, один воркер её забрал и обработал.
Pub-Sub (публикация-подписка): одно сообщение — много получателей. Kafka работает именно по этой модели. Один продюсер публикует событие, несколько консьюмеров получают его независимо.
────────────────────────────────────────
▶ Уровень Senior
На сеньора проверяют детали, которые большинство кандидатов не знает.
Статус-коды HTTP — обязательно знать:
• 200 OK — успешный запрос
• 201 Created — ресурс создан
• 204 No Content — успех, но тела ответа нет
• 400 Bad Request — ошибка клиента, неверный запрос
• 401 Unauthorized — не аутентифицирован
• 403 Forbidden — аутентифицирован, но нет прав
• 404 Not Found — ресурс не найден
• 409 Conflict — конфликт состояния (например, дубликат)
• 422 Unprocessable Entity — данные понятны, но семантически неверны
• 500 Internal Server Error — ошибка на стороне сервера
POST и идемпотентность — нюанс для сеньора:
По умолчанию POST не идемпотентен. Но можно сделать его идемпотентным через заголовок Idempotency-Key. Клиент генерирует уникальный ключ и отправляет его в заголовке. Сервер кэширует ответ на этот ключ — повторный запрос с тем же ключом вернёт тот же результат без повторного выполнения.
Версионирование API:
Когда API меняется, нельзя просто сломать старых клиентов. Решение — версионирование через путь: /v1/users, /v2/users. Старая версия продолжает работать.
Обратная совместимость — главное правило:
• Нельзя удалять существующие поля из ответа
• Нельзя менять тип существующих полей
• Новые поля всегда добавляются как optional
Нарушишь это правило — сломаешь клиентов, которые уже в продакшене.
────────────────────────────────────────
В следующей части разберём архитектуру и базы данных: монолит vs микросервисы, C4 нотация, нормализация, ACID, SQL vs NoSQL.
#системныйаналитик #собеседование #ITкарьера #аналитик #подготовка