На собеседовании системного аналитика опыт проектов нужно подкреплять объяснением конкретных решений: как проверяется токен, почему таблицы связаны именно так и что произойдёт при сбое интеграции. В этой технической секции проверяют безопасность, модель данных, диаграммы и взаимодействие сервисов. Кандидат уверенно обсуждает практические интеграции, но затрудняется с частью базовых вопросов. Разберём, как собрать точный ответ без лишней теории.
Что представляет собой JWT-токен?
JWT хранит набор данных, которыми обмениваются стороны. Распространённый подписанный вариант состоит из трёх частей: заголовка, полезной нагрузки и подписи, разделённых точками. В заголовке указан алгоритм подписи, в нагрузке могут находиться идентификатор пользователя и срок действия. JWT также бывает зашифрованным, поэтому три части — характеристика подписанного формата JWS, а не любого JWT. RFC 7519.
Подпись нужна, чтобы обнаружить изменение данных и проверить их происхождение при доверии к ключу. Она не скрывает содержимое: нагрузку обычного подписанного JWT можно прочитать. Base64url — кодирование, не шифрование.
Практический пример: если в токене заменить роль reader на admin, текст изменится, но прежняя подпись перестанет подходить. Просто прочитать новую роль недостаточно — сервер должен проверить токен. Помимо подписи, важны ожидаемый издатель, получатель и время действия согласно правилам приложения.
На вопрос об устройстве токена кандидат готового ответа не дал. Для подготовки мы советуем связать каждую часть с действием сервера: прочитать, проверить, принять или отклонить.
Чем различаются идентификация, аутентификация и авторизация?
Идентификация отвечает на вопрос «кто вы», аутентификация — «чем это подтверждается», авторизация — «что вам разрешено». Для почты это имя учётной записи, проверка пароля или другого средства входа и разрешение читать либо отправлять письма.
В разговоре кандидат объясняет различие через действия в почтовом сервисе. Этот пример полезен, но формулировку идентификации нужно сделать точной: пароль подтверждает заявленную личность, а не заменяет её идентификатор.
Для аналитика следующий шаг — разделить проверки в требованиях. Пользователь может успешно войти в систему, но не получить доступ к конкретному документу. Поэтому сценарии «неверный пароль» и «нет права редактирования» требуют разных условий и результатов.
Как связать таблицы книг и авторов?
Сначала нужно уточнить, может ли у одной книги быть несколько авторов. В прозвучавшем условии есть две таблицы, требуется определить авторство и учесть много книг у одного автора. Этого ещё недостаточно, чтобы однозначно выбрать связь «многие ко многим».
Если принимаем допущение «у книги один автор», достаточно поля author_id в таблице книг. Оно ссылается на ключ автора. У нескольких книг значение может совпадать: так получается связь «один ко многим».
Дополнительный вариант — несколько авторов одной книги. Тогда нужна таблица book_authors с парами book_id и author_id. Одна строка связывает одну книгу с одним автором. Два внешних ключа проверяют существование обеих записей, а составной первичный ключ запрещает повторить ту же пару. Такой принцип описан в документации PostgreSQL.
В ходе ответа кандидат обсуждает неизвестного автора и позже приходит к промежуточной таблице. Неизвестное авторство — отдельное требование. Оно влияет на допустимость отсутствующей ссылки, но само по себе не создаёт связь «многие ко многим».
Какой тип выбрать для названия книги в PostgreSQL?
Если требование задаёт максимальную длину названия, подходит varchar(n), где n — согласованный предел в символах. Если ограничения нет, обычно достаточно text. Само слово string не называет встроенный строковый тип PostgreSQL. Документация строковых типов.
Вопрос проверяет не только название типа. Нужно объяснить, откуда взялось ограничение: из бизнес-правила, внешнего формата или предположения разработчика. Произвольный предел может заблокировать корректное название.
После выбора типа мы бы отдельно уточнили обязательность поля и допустимость пустой строки. Эти требования не следуют из максимальной длины. NULL, пустая строка и слишком длинное значение — три разных случая для проверки.
Как создавать диаграммы последовательности?
Диаграмма последовательности помогает описать взаимодействие во времени. В PlantUML её можно записать текстом: участники, сообщения, ответы и ветки сценария превращаются в рисунок. Синтаксис и примеры есть в документации PlantUML.
Кандидат использует такие схемы в технических заданиях и предлагает получать черновик с помощью ИИ, затем исправлять его. Это полезный рабочий приём, если аналитик проверяет логику.
Мы проверяли бы схему по конкретному сценарию: приложение запрашивает операцию, сервис проверяет условия, сохраняет результат и отвечает. После этого добавили бы альтернативу — проверка не пройдена. По схеме должно быть понятно, кто принимает решение и на каком шаге процесс заканчивается. Выбор редактора этого не объясняет.
Когда выбирать REST, а когда асинхронное взаимодействие?
Когда использовать REST на практике?
В разобранном примере приложение отправляет команду, а следующий шаг зависит от результата её обработки. Для такого сценария подходит запрос с ответом. Кандидат связывает этот выбор с потребностью быстро получить подтверждение.
При этом REST сам по себе не гарантирует мгновенное завершение операции. HTTP API может принять задачу и вернуть 202 Accepted, пока обработка продолжается. Поэтому в требованиях нужно различать «команда принята» и «операция завершена». Значение статуса определено в RFC 9110.
Когда использовать асинхронное взаимодействие и Kafka?
Оно подходит, когда отправитель может передать событие и не ждать окончания всей обработки. В ответе кандидата выбор Kafka связан с большим потоком событий и требованиями к устойчивости.
Наличие Kafka не означает, что потери и повторы исключены автоматически. Гарантии зависят от подтверждений записи, репликации и порядка обработки. При повторной доставке обработчик может увидеть событие ещё раз. Для записи результата во внешнюю систему нужны согласованные правила. Гарантии доставки Apache Kafka.
Наш дополнительный пример: событие о переводе содержит идентификатор операции. Обработчик проверяет, применял ли его раньше, чтобы повторная доставка не создала вторую операцию. Такое поведение называют идемпотентным. На интервью полезно объяснить этот механизм, а не ограничиваться словом «отказоустойчивость».
Как проверить себя перед следующим интервью
Возьмите один знакомый процесс и пройдите его от пользовательского действия до сохранения результата. Так быстрее обнаруживаются пробелы между рабочим опытом и теорией.
- Объясните, какие данные токена можно прочитать и какие проверки обязательны.
- Нарисуйте связи данных и проговорите кратность в обе стороны.
- Обоснуйте типы полей и ограничения требованиями.
- Покажите на диаграмме успешный сценарий и одну ошибку.
- Объясните, что произойдёт после тайм-аута или повторного события.
Если самостоятельно трудно оценить полноту ответа, на аудите готовности мы проводим мок-собеседование и готовим обратную связь с планом подготовки.
Итог: получил бы кандидат оффер?
Факт: во вступлении заявлен оффер на 300 000 ₽, а в финале звучит положительный прогноз ведущего. Отдельного подтверждения решения работодателя в показанном материале нет. Поэтому заявленный результат и нашу оценку ответов стоит разделять.
Наша оценка: скорее получил бы, если основной запрос команды — практическая работа с интеграциями. Кандидат связывает выбор взаимодействия с задачей, уверенно описывает подготовку технических заданий и объясняет, как использует диаграммы. Это конкретные профессиональные аргументы в его пользу.
Слабые места тоже существенны: нет готового объяснения JWT, а модель связей и строковый тип требуют уточнений. Мы бы проверили их ещё одной короткой задачей. Если позиция требует самостоятельно проектировать безопасность и данные, этих пробелов достаточно, чтобы отложить решение до дополнительной проверки.
Источники
частые вопросы
Короткие ответы
Как готовиться, если есть опыт интеграций, но забывается теория?
Возьмите одну рабочую интеграцию и объясните её без названий инструментов: какие данные передаются, кто проверяет права, где хранится состояние и что происходит при повторном запросе. Затем проверьте термины по документации.
Можно ли пользоваться ИИ для диаграмм в техническом задании?
Можно использовать ИИ для черновика. Аналитик должен самостоятельно проверить участников, порядок сообщений, данные и ветки ошибок. Красиво отрисованная схема ещё не подтверждает правильность процесса.
Нужно ли системному аналитику писать код на таком собеседовании?
В разобранном фрагменте проверяют модель данных, тип поля и объяснение интеграций. Для этих вопросов важнее корректная схема и аргументация, чем код на конкретном языке. Формат других секций следует уточнять у работодателя.
