Перед собеседованием хочется найти список практических задач и прорешать его. Я проверил сработает ли это. Взял больше сотни описаний реальных собеседований системных аналитиков и выписал все задачи.

Практическую задачу давали больше чем на половине собеседований. Дословно повторились единицы, так что на твоем собеседовании, скорее всего, будет новая.

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

Вот одна из задач про дубли: "Есть POST-запрос на совершение оплаты. Его вызвали 30 раз с одними и теми же параметрами. Создалось 30 одинаковых платежей. Почему это могло произойти, как этого избежать?"

Сильный ответ начинается с вопросов. Кто вызывал 30 раз: пользователь жал на кнопку или клиент повторял запрос по таймауту? Деньги списаны 30 раз или в базе 30 записей при одном списании? Есть ли в запросе номер заказа?

Потом причина. Сервер не отличает повтор от нового запроса и на каждый вызов создает платеж. А повторы случаются сами: клиент не дождался ответа и отправил запрос снова. Защита держится на идентификаторе операции, это ключ идемпотентности или номер заказа. Проверку и создание платежа делают одной атомарной операцией, на повтор возвращают результат первой.

Частая ошибка: заблокировать кнопку после нажатия. Двойной клик это уберет, повтор по таймауту нет.

На разборах почти все пересказывают заученное правило: передай ключ идемпотентности в заголовке. Мало кто понимает суть работы с данными. Повтор можно распознать и по телу запроса, например по номеру заказа. Если заказ с таким номером уже создан, второй не создается.

Остальные задачи про дубли звучат иначе: повторная оплата, двойное списание, дубли заявок. А ход у них тот же.

Всего видов практических задач восемь, от частых к редким: 1. Решить проблему в работающей системе: найти причину сбоя и закрыть ее, как с платежами выше. 2. Спроектировать взаимодействие систем: как заказ проверяет склад и что делать, если склад молчит. 3. Модель данных: спроектировать таблицы или навести порядок в данных. 4. API: описать эндпоинты, параметры и коды ответов. 5. Требования: какие вопросы задать до решения и как записать ответы, чтобы их можно было проверить. 6. SQL: написать запрос по нескольким таблицам или прочитать готовый. 7. BPMN: нарисовать процесс с развилками и исключениями. 8. Найти ошибку: в JSON или по симптомам сбоя, без разработчика.

Порядок видов подсказывает с чего начать, но задачу конкретной компании не предсказывает.

И это не только для Senior, Middle практическую задачу дают не реже.

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

Выбери два-три вида: самые частые и те, что ближе к твоим вакансиям. Реши по задаче каждого вида.

На странице каждый вид разобран на реальной задаче: что уточнить, ход ответа, типичная ошибка. Страница бесплатная, своими идеями я делюсь свободно.

Открыть задачи → https://ineverov.ru/knowledge/sa-interview-tasks/

Вопросы к собеседованию → https://ineverov.ru/knowledge/sa-interview-bank/

#собеседование #системныйанализ #поискработы #аналитика #АналитикНаБалтике

Знания. Свободно. Ваш Аналитик на Балтике 🌊