На собесе по Java в банках любят один и тот же паттерн: контроллер на 50 строк, а багов — как в плохом postbac

На собесе по Java в банках любят один и тот же паттерн: контроллер на 50 строк, а багов — как в плохом postback-цепочке после редиректов.

Что там обычно проверяют:
- неверные scope/DI инициализации
- `null` без валидации
- транзакции, которые “есть”, но не там
- `@RequestBody` vs `@ModelAttribute`
- race condition на изменении баланса
- утечки через логирование
- неправильный HTTP-код
- бизнес-логика в контроллере вместо сервиса

Смысл задачи не в синтаксисе. Смысл — видит ли человек, где сломается прод: при ретрае, при дубле запроса, при таймауте, при конкуренции потоков.
Junior находит 3–4 дефекта. Middle — уже видит обработку ошибок и границы транзакции. Senior должен сразу резать архитектуру: контроллер тонкий, валидация отдельно, идемпотентность отдельно, логирование без PII, все события — через сервисный слой.

Если в коде есть платежи, но нет идемпотентности и нормального error handling — это не “мелкий баг”, это минус деньги.