Какие задачи были интересные или сложные в вашем опыте?

Что проверяют

Интервьюер хочет увидеть потолок ваших задач и то, как вы рассуждаете, когда готового решения нет. По истории видно, где ваш личный вклад, а где работа команды. Следом почти всегда спрашивают: «Какие варианты рассматривали и почему выбрали этот?» или «Что бы сделали иначе сейчас?»

Как отвечать

Возьмите одну задачу из своего опыта и разберите её по шагам: контекст, в чём была сложность, какие были варианты, что сделали лично вы, чем кончилось и что бы поменяли. Для Java-разработчика хорошо работают истории, где есть диагностика и компромисс:

• утечка памяти или долгие паузы GC: как сняли heap dump через jcmd или -XX:+HeapDumpOnOutOfMemoryError, разобрали его в Eclipse MAT, что нашли и как проверили исправление;
• производительность базы: N+1 в Hibernate, решённый через JOIN FETCH или @EntityGraph, медленный запрос, разобранный через EXPLAIN ANALYZE;
• конкурентность: дедлок или исчерпание пула потоков, найденные по thread dump, переход на виртуальные потоки в Java 21 и что при этом всплыло;
• миграция: переход на Spring Boot 3 с заменой javax.* на jakarta.*, обновление JDK с 8 или 11 на 17 и 21;
• надёжность интеграций: идемпотентность консьюмеров Kafka, паттерн transactional outbox вместо распределённой транзакции.

Цифры нужны ваши и проверяемые: было p99 1,2 секунды, стало 200 мс, или сервис перестал падать по OOM раз в неделю. Если по-настоящему сложных задач в коммерческом опыте не было, честно скажите об этом и расскажите о самой сложной задаче из учебного или pet-проекта, но с тем же разбором вариантов.

Где спотыкаются

Рассказывают о проекте, а не о задаче: «мы делали интеграцию с платформой». Интервьюеру нужно, что именно сделали вы и где было трудно.

Приносят заготовку с круглыми процентами вроде «сроки сократились на 20%». Первый уточняющий вопрос о том, как это посчитали, такую историю разваливает.

Выбирают задачу, где не было выбора: обычный CRUD на Spring сложным не выглядит, даже если он был большим. Сложность в неопределённости и компромиссах, а не в объёме кода.