Вопросы на собеседовании Java-разработчика

Пример сильного ответа

JVM делит кучу на поколения: молодое и старое. Новые объекты попадают в Eden, пережившие сборки переезжают в Survivor, затем в Old. Отсюда два типа сборок: быстрые minor и более дорогие major. Сборщик выбираю под задачу: Serial и Parallel — когда важен throughput, G1 — компромисс по паузам, ZGC и Shenandoah — когда нужны минимальные паузы на больших кучах. Смотрю GC-логи, долю времени в сборках и длину пауз. На одном проекте после смены сборщика и настройки размеров поколений паузы упали с секунды до 100–150 мс, и это сняло жалобы на таймауты.

• Показана база: поколения, типы сборок, сборщики
• Есть критерий выбора сборщика под задачу
• Результат подтверждён цифрами по паузам

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Stack — это память потока: там фреймы вызовов и локальные переменные, размер небольшой, работа по принципу LIFO. Heap — общая память для объектов, ей управляет сборщик мусора. StackOverflowError возникает при слишком глубокой или бесконечной рекурсии: стек потока переполняется. OutOfMemoryError — когда в куче не хватает места под новые объекты, например из-за утечки через статическую коллекцию или слишком большого объёма данных в памяти. Мне приходилось искать утечку по дампу кучи: причина оказалась в статической коллекции, которая росла и не очищалась; после правки потребление памяти упало примерно на 40%.

• Чёткое различие Stack и Heap в одном абзаце
• Названы реальные причины обеих ошибок
• Есть опыт диагностики и метрика результата

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

HashMap внутри — массив корзин. Хеш ключа определяет индекс, коллизии разрешаются списком, а при большой длине — красно-чёрным деревом. При превышении порога по заполнению происходит resize. Контракт equals и hashCode критичен: если равные объекты дают разные хеши, ключ не найдётся, появятся дубликаты и утечки. В одном проекте кэш на 150 тысяч записей после исправления hashCode: время поиска сократилось с линейного до константного, а потребление памяти снизилось примерно на 20%. Поэтому всегда проверяю контракт в тестах.

• Показывает понимание внутреннего устройства и контракта
• Приводит конкретный измеримый результат из опыта
• Демонстрирует практический подход к тестированию

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Выбор начинается с профиля доступа. ArrayList — это массив: доступ по индексу очень быстрый, а вставка или удаление в середине требует сдвига элементов. LinkedList — двусвязный список: вставка по уже найденному узлу дешёвая, но доступ по индексу линейный, на каждый элемент уходит лишняя память, а из-за разбросанности узлов страдает локальность кэша. На практике LinkedList проигрывает почти всегда. Мне приходилось заменять его на ArrayList на горячем пути обработки заказов, и разбор пакета из двухсот тысяч записей ускорился примерно на треть. Очереди и стеки я строю на ArrayDeque.

• Показан критерий выбора, а не заученное определение
• Есть вывод из практики с конкретным ускорением
• Упомянут ArrayDeque как рабочая альтернатива

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

String неизменяем, и это даёт сразу несколько выгод. Объект безопасно передавать между потоками без синхронизации, использовать как ключ в HashMap — хеш считается один раз и кэшируется, — а также безопасно отдавать в API, где важна целостность значения. Благодаря неизменяемости работает и пул строк, поэтому одинаковые литералы переиспользуются. Обратная сторона — каждая модификация создаёт новый объект. В цикле конкатенация через плюс превращается в генератор мусора. Мне приходилось переписывать сборку большого отчёта на StringBuilder, и потребление памяти на этом участке снизилось примерно на сорок процентов, а паузы сборщика мусора стали заметно короче.

• Причины поданы через практические выгоды, а не заклинания
• Есть переход к обратной стороне неизменяемости
• Подкреплено измеренным снижением памяти

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

JIT — это компиляция байт-кода в машинный код прямо во время работы приложения. Сначала код исполняет интерпретатор, а горячие методы, по данным профилирования, компилируются и оптимизируются: инлайнинг, устранение мёртвого кода, escape-анализ. Если предположения перестают выполняться, происходит деоптимизация. Для практики важно, что приложение разогревается: первые запросы заметно медленнее. Мне приходилось видеть, как сервис на старте показывал задержки в разы выше, чем через несколько минут работы. Поэтому нагрузочные замеры я делаю только на прогретой JVM, и после прогрева время ответа на типовой запрос падало примерно вдвое.

• Объяснена суть и типовые оптимизации без лишних деталей
• Показано практическое следствие — эффект прогрева
• Есть вывод про методику замеров и цифра улучшения

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

synchronized — это встроенный монитор: кода меньше, блокировка освобождается автоматически, компилятор такие блоки хорошо оптимизирует, поэтому по умолчанию я выбираю именно его. ReentrantLock нужен, когда требуется больше контроля: попытка захвата с таймаутом, прерываемое ожидание, честная очередь или несколько Condition на одной блокировке. В одном сервисе внешний вызов иногда деградировал, и потоки надолго зависали на мониторе. Перевод критической секции на tryLock с таймаутом в полсекунды вернул управляемость: зависаний больше не было, а пропускная способность выросла примерно на двадцать процентов.

• Сразу назван выбор по умолчанию и его причина
• Перечислены конкретные возможности ReentrantLock
• Пример с таймаутом и цифрой пропускной способности

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

volatile гарантирует видимость записи для других потоков и запрещает переупорядочивание операций вокруг обращения к переменной. Но атомарности он не даёт: составные операции вроде инкремента остаются небезопасными, взаимного исключения тоже нет, поэтому две записи могут перекрыться. Отсюда и выбор: volatile уместен для флага остановки, для ссылки на неизменяемый объект, который публикуется целиком. Для счётчиков и накопителей я беру атомарные классы или блокировку. Мне приходилось разбирать случай, когда флаг остановки без volatile не был виден, и сервис останавливался по таймауту; после правки остановка укладывалась в две секунды.

• Чётко разделены гарантии volatile и их отсутствие
• Показано, когда какой инструмент уместен
• Живой пример из отладки с измеримым результатом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В основе ConcurrentHashMap — идея блокировать не всю коллекцию, а отдельные бакеты. При чтении значение берётся из volatile-поля без блокировки, запись идёт через CAS, и только при коллизии поток синхронизируется на первом узле бакета. Поэтому параллельные читатели и писатели в разные бакеты почти не мешают друг другу, тогда как синхронизированная обёртка держит один монитор на весь HashMap и выстраивает все операции в очередь. В одном из проектов кэш на 200 000 записей под нагрузкой 3000 RPS работал через обёртку, а перевод на ConcurrentHashMap дал снижение времени ответа p99 примерно в десять раз.

• Показан механизм, а не заученное определение
• Сравнение с обёрткой через общий монитор — суть вопроса
• Есть измеримый результат из своей практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Deadlock — это взаимная блокировка, когда потоки держат ресурсы и ждут те, что заняты друг другом. Для поиска снимаю thread dump через jstack или профилировщик, смотрю блоки «waiting to lock», строю граф ожиданий и ищу цикл; дополнительно помогают алерты по времени ответа и логи с таймаутами. Профилактика проще: единый порядок захвата блокировок, tryLock с таймаутом вместо бесконечного ожидания, короткие критические секции, отказ от вложенных чужих мониторов. В сервисе с интеграциями такие зависания случались примерно раз в месяц; после введения общего порядка захвата и таймаутов подобных инцидентов за полгода не было.

• Есть и диагностика, и профилактика
• Названы конкретные инструменты снятия дампа
• Честный пример с измеримым эффектом

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Пул настраиваю явно через ThreadPoolExecutor: отдельный пул для расчётных задач и отдельный для блокирующих вызовов, чтобы медленный ввод-вывод не съедал потоки вычислений. Размер первого привязываю к числу ядер, второго беру заметно больше, потому что потоки там в основном ждут. Очередь выбираю по смыслу: ArrayBlockingQueue с ограничением даёт backpressure, SynchronousQueue — прямой хендофф, а неограниченную не беру, она копит задачи до падения по памяти. Плюс политика отказа, понятные имена потоков, метрики по размеру очереди и activeCount, корректное завершение через shutdown и awaitTermination. Типовая конфигурация: 8 потоков под расчёты и 32 под интеграции с очередью на 200 задач.

• Видно понимание разделения CPU- и IO-задач
• Объяснён выбор очереди и политики отказа
• Есть конкретные параметры пула

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Промежуточные операции ленивы: они только описывают конвейер и возвращают новый Stream, а работа запускается терминальной — collect, reduce, forEach. Отсюда правило: один терминальный вызов на поток и никакого повторного использования. С parallelStream нужна осторожность: по умолчанию это общий ForkJoinPool с ограниченным числом потоков, поэтому блокирующие вызовы и ввод-вывод там вредят всему приложению, а разбиение и слияние дают накладные расходы. Есть и неочевидности с порядком, состоянием и побочными эффектами. В расчёте по миллиону записей параллельный вариант с общим состоянием дал ускорение около 1,3 раза, а после переписывания на чистый reduce — почти четырёхкратное.

• Чётко разграничены ленивые и терминальные операции
• Названы реальные риски общего ForkJoinPool
• Подкреплено личным замером производительности

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

IoC — это передача контейнеру управления созданием объектов и их связями: класс не ищет зависимости самостоятельно, а объявляет их, а Spring решает, что и когда создать. Внедрение зависимостей через конструктор делает зависимости явными, объект всегда в согласованном состоянии, его легко подменить в тестах на мок. Появляется единая точка конфигурации, управление жизненным циклом и областями видимости, слабая связанность слоёв. В проекте с несколькими десятками бинов это позволяло менять реализацию хранилища или клиента внешней системы одной конфигурацией, без правок в бизнес-логике, и покрывать сервисы модульными тестами без запуска контекста.

• Сначала суть идеи, потом польза на практике
• Отмечена роль конструкторного внедрения и тестов
• Приведён пример без лишних деталей

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

@Transactional работает через прокси: Spring открывает транзакцию до вызова метода и коммитит или откатывает после. По умолчанию откат идёт только по RuntimeException и Error, поэтому проверяемое исключение без rollbackFor доведёт дело до коммита. Ещё три ловушки: самовызов внутри того же бина идёт мимо прокси, исключение поймано внутри метода и не проброшено, вложенная транзакция помечает внешнюю как rollback-only. В проекте по сверке платежей такие случаи встречались на возвратах: помогли rollbackFor и вынос вызовов в отдельный сервис. Количество «зависших» операций снизилось примерно на 90% — с нескольких сотен до десятков в месяц.

• Объяснён механизм прокси и дефолт по исключениям
• Названы три реальные причины отсутствия отката
• Есть измеримый результат из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

N+1 — когда один запрос загружает список сущностей, а потом для каждой из них Hibernate шлёт отдельный запрос за связью: вместо пары запросов получается N+1. Диагностирую по логам SQL: включаю вывод запросов и смотрю, повторяется ли один и тот же select с разными параметрами; в тестах помогает статистика Hibernate и профилировщик. Устраняю через join fetch или @EntityGraph в JPQL, а если нужна пагинация по коллекции — через DTO-проекцию или @BatchSize. На списке заказов вместо 300 запросов стало 2, страница ускорилась с 4 секунд до 250 миллисекунд.

• Дано чёткое определение проблемы
• Показана диагностика через SQL-логи и статистику
• Устранение подкреплено цифрами до и после

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

LazyInitializationException возникает, когда код обращается к ленивой связи после закрытия сессии или выхода из транзакции: прокси уже не может сходить в базу. Чаще всего это всплывает при сериализации сущности в контроллере, в toString или equals. Правильный путь — загружать нужные данные внутри транзакции: join fetch, @EntityGraph или DTO-проекция, а не открытая на весь запрос сессия. В сервисе отчётности такая ошибка встречалась в экспорте; после перехода на DTO с выборкой нужных полей инциденты прекратились, а экспорт ускорился примерно на 30%.

• Названа суть ошибки и типичные места появления
• Предложен правильный путь вместо открытой сессии
• Есть результат из реальной задачи

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Основной scope — singleton, один бин на контекст. Дальше prototype — новый экземпляр на каждое получение, request и session — на HTTP-запрос и на сессию пользователя, есть ещё application и websocket. Prototype применяется для состояния и не потокобезопасных объектов: парсеры, билдеры, тяжёлые конвертеры; важная деталь — в singleton его нельзя просто заинжектить, нужен ObjectProvider или @Lookup. Request реально нужен для данных конкретного запроса: идентификатор корреляции, арендатор, пользовательский контекст, кэш в рамках запроса. В одном сервисе так хранился контекст арендатора, и ручная передача параметра через несколько десятков методов исчезла.

• Перечислены все scope и их назначение
• Показана ловушка с внедрением prototype в singleton
• Приведён пример request-scope из практики

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Сначала воспроизвожу и измеряю: включаю логи SQL и статистику, смотрю, сколько запросов уходит на один рендер страницы и какие из них самые долгие. Дальше проверяю типовые причины после перехода на Spring Data: вместо одного запроса появились сотни из-за N+1, ленивые связи подгружаются по одной, пагинация считается в памяти, нет индекса под фильтр. Помогают join fetch или @EntityGraph, DTO-проекция, батчинг и индекс. В похожем случае страница открывалась 10 секунд: 240 запросов превратились в 3, отклик стал около 300 миллисекунд.

• Сначала измерение, потом гипотезы — правильный порядок
• Перечислены типовые причины после миграции на JPA
• Есть цифры до и после оптимизации

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом смотрю метрики и логи: когда именно замирания — по расписанию, на пиках трафика или после релиза. Дальше снимаю несколько thread dump с интервалом и подключаю профайлер, обычно картина проясняется быстро. Частые причины: длинные паузы сборщика мусора, исчерпание пула потоков или пула соединений, блокировки на общем ресурсе, вызовы внешних сервисов без таймаутов. В одном случае помогло вернуть таймауты и ограничить параллелизм: время ответа на пике снизилось примерно на 40%, а секундные замирания исчезли. После фикса всегда добавляю метрику или алерт, чтобы проблема ловилась заранее, а не от пользователей.

• Показан системный порядок диагностики, а не догадки
• Есть конкретная причина и измеримый результат
• Финал про мониторинг говорит о зрелости подхода

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Основа здесь — идемпотентность. Клиент передаёт уникальный ключ операции, и на его основе в базе стоит уникальное ограничение: повтор с тем же ключом не создаёт вторую операцию, а возвращает результат первой. Обработка идёт в одной транзакции, поэтому результат либо есть целиком, либо его нет. На стороне клиента — повторные попытки с нарастающей задержкой и случайным разбросом, чтобы не добивать сервис. Дополнительно ставлю проверку на дубли в мониторинге. После такой схемы повторные списания, случавшиеся несколько раз в месяц, прекратились, а обращения в поддержку по этой теме упали примерно вдвое.

• Названы ключ идемпотентности, транзакция и ретраи
• Есть конкретный измеримый результат
• Ответ показывает понимание всей цепочки, а не только кода

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Самый памятный случай — постепенная деградация сервиса: раз в несколько дней инстанс перезапускался из-за нехватки памяти, хотя нагрузка была ровной. Метрики ничего не показывали, поэтому снимаю heap dump перед падением и сравниваю два снимка — вижу стабильный рост числа объектов одного типа, которые никто не освобождает. Причина оказалась в собственном кеше без ограничения по размеру. Ограничиваю размер, добавляю алерт на потребление памяти: перезапуски прекратились, потребление стало стабильным. Поиск занял около двух недель, зато после фикса тема больше не всплывала.

• Есть конкретная методика поиска, а не только итог
• Указаны сроки и эффект от исправления
• Видно умение работать без подсказок мониторинга

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В одном проекте предлагалось синхронно вызывать внешний сервис прямо в обработке заказа. Мне такой вариант казался рискованным: любая задержка на той стороне тормозила бы весь поток. Вместо спора на словах собираю небольшой прототип с очередью и замеряю оба варианта на тестовой нагрузке — разница в устойчивости на пиках оказалась заметной. Показываю результаты команде, вместе обсуждаем компромиссы и выбираем вариант с очередью. Если бы решение всё равно приняли иначе, моя позиция — зафиксировать риски и дальше делать общее дело хорошо, а не тянуть в свою сторону.

• Спор переведён в данные и прототип
• Показано уважение к решению команды
• Назван критерий — устойчивость под нагрузкой

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Ревью для меня — про качество и общий контекст, а не про поиск виноватых. Смотрю небольшими порциями, в первую очередь логику и границы: обработку ошибок, конкурентность, тесты, читаемость. Замечания формулирую как вопросы или предложения с примерами, чтобы автору было понятно, почему. Критику своего кода воспринимаю спокойно: уточняю аргументы, объясняю решение, и если оппонент прав — правлю, а не спорю. Стараюсь укладываться в один рабочий день на ревью, чтобы задача не стояла. В команде из шести человек такой подход заметно снизил число возвратов на доработку.

• Показаны и свои замечания, и реакция на критику
• Есть конкретные критерии ревью и срок
• Назван измеримый командный эффект

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.