Опиши архитектуру сервиса отправки промокода после отзыва
Что проверяют
Это системный дизайн в версии для тестировщика. Проверяют не умение спроектировать сервис, а умение увидеть в схеме места, где всё ломается, и превратить их в проверки. Ещё смотрят, задаёте ли вы уточняющие вопросы до того, как начали рисовать.
Как отвечать
Сначала требования, вопросов пять хватит: что считается отзывом и проходит ли он модерацию до выдачи кода, один код на отзыв или на пользователя за период, канал доставки, срок жизни и уникальность кода, откуда берутся коды и конечен ли запас.
Потом короткая схема: форма отзыва, сервис отзывов сохраняет запись и публикует событие, сервис промокодов читает событие, резервирует код и отдаёт его в доставку письмом или сообщением. Асинхронность тут не украшение: доставка не должна держать пользователя на форме.
Дальше сразу переходите в свою зону, ради неё вопрос и задан:
- повтор события из очереди не должен выдавать второй код, ключом идемпотентности служит идентификатор отзыва;
- двойной клик по кнопке и два отзыва от одного пользователя одновременно;
- отзыв отклонили модерацией после выдачи кода: код отзывается или сгорает;
- запас кодов исчерпан, один код достался двум пользователям;
- письмо не доставлено, повторная доставка не должна порождать новый код;
- код просрочен, использован дважды, применён к чужому заказу.
Скажите и про то, чем проверяете: контракт события, интеграционные прогоны с подменённым отправителем, сверка состояния в базе, а не только факт письма.
Где спотыкаются
Уходят в роль архитектора. Кандидат полчаса рисует шину и балансировщики, ни разу не назвав проверку, и оставляет впечатление разработчика, который ошибся вакансией.
Второе: не уточняют требования. Без ответа про модерацию и про лимит на пользователя схема получается не про ту задачу, и обсуждать дальше нечего.
Третье: проверяют только через интерфейс по факту пришедшего письма. Повтор события, гонка и исчерпание пула кодов через интерфейс не воспроизводятся, а убытки приносят именно они.