Главная › Блог › Как готовиться к собеседованию Java: план на 30 дней

Как готовиться к собеседованию Java: план на 30 дней

Почему «просто повторить теорию» не работает

Типичная ошибка при подготовке — открыть список тем (JVM, GC, JMM, Spring, SQL, коллекции) и читать про каждую по порядку. Через две недели голова забита фактами, но на собеседовании при вопросе «а как работает happens-before между volatile-записью и обычным чтением» наступает пауза. Проблема не в объёме знаний, а в формате: чтение даёт узнавание, а собеседование требует воспроизведения под давлением и без подсказок.

30 дней — это не про «выучить всё», это про то, чтобы перевести знания из пассивных в активные и закрыть дыры, которые обычно всплывают на реальных интервью.

Это как готовиться к спаррингу, а не к контрольной. Знать теорию удара недостаточно — нужно отработать его в условиях, когда тебе отвечают и время ограничено.

Неделя 1: аудит и база памяти/многопоточности

Первая неделя — не про новые знания, а про диагностику пробелов. Возьмите 15-20 типовых senior-вопросов (JMM, volatile, synchronized, ConcurrentHashMap, GC) и попробуйте ответить на них вслух, без подготовки, с таймером 90 секунд на вопрос. Записывайте, где зависаете.

День 1-2: самопроверка по памяти JVM и GC — что где лежит, зачем нужны разные сборщики.
День 3-4: JMM, happens-before, volatile, synchronized — не просто «что делает», а «почему без этого возможен баг».
День 5-7: закрытие конкретных пробелов, найденных на 1-2 днях, через практику — написать код с состоянием гонки, объяснить, где оно возникает.

Ловушка: перечитывать статью про volatile третий раз, потому что «не до конца запомнилось». Если тема не закрепляется чтением — переходите к объяснению вслух или написанию кода, чтение не добавит глубины.

Неделя 2: коллекции, ConcurrentHashMap, Spring

Вторая неделя — Spring и коллекции, потому что это то, что спрашивают почти на каждом собесе middle/senior уровня. Хэш-таблицы, деревья, устройство ArrayList/LinkedList под капотом, прокси в Spring, жизненный цикл бина, транзакции и их изоляция.

Здесь важно не просто помнить факты, а уметь объяснить, зачем это устроено именно так. Вопрос «почему load factor 0.75» — это не про цифру, это про баланс между памятью и коллизиями.

Неделя 3: БД, SQL, Kafka, сети

Третья неделя закрывает то, что часто недооценивают: индексы, MVCC, уровни изоляции транзакций, блокировки в БД, основы Kafka (партиции, консьюмер-группы, семантика доставки), базовые вопросы про сети (TCP handshake, что происходит при обрыве соединения).

Здесь работает тот же принцип: не читать про MVCC, а нарисовать на бумаге, что произойдёт с двумя параллельными транзакциями при REPEATABLE READ, и проверить себя.

Неделя 4: мок-интервью и system design

Последняя неделя — не про новые темы, а про интеграцию. Проведите 3-4 мок-интервью (с коллегой, менторов, или хотя бы сами себе с таймером и вопросами вслух). Добавьте пару задач по system design — не для того чтобы стать архитектором за неделю, а чтобы потренировать формат «думаю вслух, задаю уточняющие вопросы, строю решение поэтапно».

Сколько реально нужно готовиться перед собеседованием?

Зависит от текущего уровня, но 30 дней активной практики (не чтения) обычно достаточно, чтобы закрыть типовые пробелы senior-уровня и почувствовать уверенность в разборе живых вопросов.

Что делать, если 30 дней нет

Если времени меньше — сжимайте не темы, а глубину: лучше уверенно отвечать на 60% вопросов, чем поверхностно знать 100%. Приоритет — темы, которые встречаются чаще всего: JMM/многопоточность, коллекции, Spring, базовый SQL. Их спрашивают почти всегда, а Kafka или system design — не на каждом интервью.

Не откладывайте практику ответов вслух на последний день. Разница между «я это знаю» и «я могу это объяснить за 60 секунд под вопросом с подвохом» — это отдельный навык, и он тренируется отдельно от чтения теории.