На собесах по Java я всё чаще вижу не «проверку знаний Spring», а игру в найди мину в контроллере. И да, это п

На собесах по Java я всё чаще вижу не «проверку знаний Spring», а игру в найди мину в контроллере. И да, это плохой знак.

Если вас на интервью 20 минут гоняют по куску кода на 50 строк и просят вытащить 8 багов — это не про depth. Это про то, как быстро вы замечаете:
- неправильные транзакции,
- кривую валидацию,
- гонки в потоках,
- nullable-ловушки,
- утечки ответственности между слоями.

То есть ровно то, что потом убивает прод.

Я бы смотрел на такую задачу не как на «завалили», а как на фильтр мышления: умеете ли вы видеть код как систему, а не как набор строчек. И вот тут senior отличается от junior не количеством заученных аннотаций, а привычкой задавать неудобный вопрос: «а почему это вообще живёт в контроллере?» ⚙️

Самый неприятный баг в таких задачах обычно не в синтаксисе. Он в архитектуре. Когда один метод делает всё: принимает запрос, валидирует, считает деньги, пишет в БД, дергает внешний сервис и ещё пытается быть “чистым”.

Вот это и есть реальная проверка на собесе: не найти опечатку, а увидеть, где код уже начал врать бизнесу.