На собеседованиях в крупных банках сейчас любят один и тот же жанр: дают Spring-контроллер на 50 строк и прося

На собеседованиях в крупных банках сейчас любят один и тот же жанр: дают Spring-контроллер на 50 строк и просят за 15–20 минут найти минимум 8 багов.

Почему это важно не только джунам? Потому что такой код — не просто «ошибки в Java», а срез зрелости команды: где сломана валидация, где течёт безопасность, где бизнес-логика живёт в контроллере, а где уже затаился будущий инцидент с деньгами.

Разбор задачи полезен как мини-аудит:

1) Сначала ищите то, что бьёт по продакшену сразу: null, гонки, неправильные статусы, утечки данных.
2) Потом — то, что портит продуктовую метрику: дубли, некорректные сценарии оплаты, неидемпотентность.
3) И в конце — архитектурные сигналы: слишком толстый контроллер, смешение слоёв, отсутствие границ ответственности.

Для студий и продуктовых команд это хороший тест на качество ревью: если баги в таком коде не находятся быстро, значит, у вас не только «код хрупкий», но и cost of change уже вырос 📉

Проверка простая: дайте этот формат своему тимлиду или senior’у. Если он ловит только 4–5 проблем — у вас есть повод не гордиться, а пересматривать процесс разработки.