Люблю такие задачи за одно: они проверяют не Spring, а привычку команды смотреть на систему целиком.

Люблю такие задачи за одно: они проверяют не Spring, а привычку команды смотреть на систему целиком.

Контроллер на 50 строк, где «просто обработка платежа», — это почти всегда не про код. Это про то, как продукт ломает сам себя:
- нет границ ответственности;
- бизнес-логика живёт в слое доставки;
- ошибки маскируются под «временные баги»;
- метрики потом врут, потому что событие уже потеряно или продублировано.

И вот контраргумент к мейнстриму: чем старше собеседование, тем меньше там ценится знание синтаксиса и тем больше — умение увидеть, где будет дорогой инцидент. Senior — это не тот, кто находит 8 багов быстрее всех. Это тот, кто первым замечает девятый: архитектурный долг, который потом съест retention, платежи или выручку.

Если хотите проверить себя, ищите не только NPE и race condition. Спросите:
— что станет с консистентностью?
— что увидит аналитика в логах и event tracking?
— кто заплатит за повторную обработку?
— как это ударит по CAC payback, если платежи начнут «зависать»?

Хороший код ревью — это не про «поймать косяк». Это про то, чтобы не дать команде построить продукт на хрупком фундаменте. 🔍