Співбесіда Java-розробника у 2026: що насправді питають і як не провалитися

Зізнаюся одразу: у мене є улюблене питання на співбесіді. Воно просте, як двері. «Чим == відрізняється від equals()?»

Здавалося б, що тут складного. Це знає кожен, хто дійшов хоча б до десятого рівня. Кандидат бадьоро відповідає: «== порівнює посилання, equals — вміст». Чудово. А потім я показую йому ось це:

Integer small1 = 127;Integer small2 = 127;Integer big1 = 128;Integer big2 = 128;boolean sameSmall = small1 == small2; // trueboolean sameBig = big1 == big2;       // false

І в кімнаті стає дуже тихо.

Річ не в тому, що кандидат поганий. Річ у тому, що він вивчив відповідь, а не зрозумів, як це працює. Java кешує об'єкти Integer від −128 до 127, тому 127 — це той самий об'єкт, а 128 — уже два різні. Людина, яка розуміє, пояснить це за десять секунд. Людина, яка завчила, довго дивитиметься в екран.

Отак і виглядає співбесіда з Java у 2026 році. Питання майже ті самі, що й п'ять років тому. Змінилося інше: тепер майже завжди питають «а чому?» — і з другої відповіді одразу видно, завчено чи зрозуміло.

Вийти на таку співбесіду, просто визубривши «топ-100 питань», — це як вийти на ринг проти Майка Тайсона, переглянувши кілька його боїв на YouTube. Технічно ти на рингу. Але перше ж уточнювальне питання прилетить швидше, ніж устигнеш сказати «а в туторіалі такого не було».

Розберімося, що питають зараз, де спотикаються найчастіше і як підготуватися так, щоб уточнювальні питання тебе тішили, а не лякали.

Що змінилося на співбесідах з Java

Якщо зовсім коротко: питання з основ Java майже не змінюються, але у 2026 році до них додалися сучасна Java (17, 21 і 25), Spring Boot 4 і новий формат — лайвкодинг, на якому іноді дозволяють користуватися AI.

Три головні зміни:

• Java 25 — поточна LTS. Вона вийшла у вересні 2025 року, це перша версія з довгостроковою підтримкою після Java 21. На співбесідах дедалі частіше питають не лише «що нового в Java 8», а й про records, sealed-класи, pattern matching і віртуальні потоки.
• Spring Boot 4. Вийшов у листопаді 2025 року разом зі Spring Framework 7: перехід на Jackson 3, анотації JSpecify для null-безпеки, вбудоване версіонування API. Якщо у вакансії є Spring, про нову мажорну версію можуть запитати.
• AI на співбесіді. Деякі компанії вже дозволяють кандидатам користуватися AI на технічних інтерв'ю, а Canva з 2025 року прямо вимагає цього від кандидатів у бекенд, фронтенд і машинне навчання. Але багато компаній, як і раніше, забороняють. Правило просте: запитай у рекрутера заздалегідь.

Як проходить співбесіда

Зазвичай це не одна розмова, а кілька етапів:

1. Скринінг із рекрутером — мотивація, досвід, очікування щодо зарплати. Коду немає, але адекватність перевіряють.
2. Технічний скринінг — 30–45 хвилин швидких питань з основ, щоб не витрачати час інженерів на тих, хто не дотягує.
3. Технічне інтерв'ю — 60–90 хвилин: Java Core, колекції, багатопотоковість, Spring, бази даних і багато «чому».
4. Лайвкодинг або тестове завдання — розв'язуєш задачу на очах в інтерв'юера або вдома.
5. Фінальна зустріч — команда, процеси, як працюєш у конфлікті й під дедлайном. Про HashMap тут уже не питають. Питають, що робитимеш, якщо прод упаде в п'ятницю о шостій вечора.

Джунів здебільшого питають з основ. Що вищий грейд, то менше теорії і то більше розмови про реальний досвід: що доводилося робити, які рішення ухвалювати і де траплялися помилки.

Далі — питання на співбесіді Java за темами. Це не повний список, а найчастіші, з короткими відповідями й пастками, на яких спотикаються. Докладний розбір сотень питань є в нашій великій серії «Розбір запитань та відповідей зі співбесід на Java-розробника» — до неї ми ще повернемося.

Java Core: база, без якої далі не пустять

Чим примітиви відрізняються від посилальних типів? У змінній примітивного типу лежить саме число чи символ, а в посилальній — адреса об'єкта, який живе в купі. Звідси класичне питання з підступом про Integer, з якого ми почали.

Чому String незмінний? Він незмінний, як думка тимліда про таби й пробіли. А якщо серйозно — заради безпеки, кешування хеш-коду і пулу рядків: той самий рядок можуть безпечно використовувати багато частин програми одночасно. Якщо треба багато разів склеювати рядки в циклі — бери StringBuilder, інакше на кожній ітерації створюватиметься новий об'єкт.

Як пов'язані equals() і hashCode()? Правило одне: однакові за equals() об'єкти зобов'язані повертати однаковий hashCode(). А от однаковий hashCode() у різних об'єктів цілком допустимий — це звичайна колізія. Перевизначити equals() і забути про hashCode() — гарантований спосіб отримати об'єкти, які HashMap «не знаходить», хоча вони там лежать.

Об'єкти в Java передаються за посиланням чи за значенням? Улюблене питання, на якому плутаються навіть упевнені мідли. Якщо хочеться блиснути, скажи так: «Java завжди передає за значенням, просто іноді це значення — посилання». Звучить як східна мудрість, а працює безвідмовно. Тому метод здатен змінити поля переданого об'єкта, але не здатен підмінити сам об'єкт у змінній ззовні.

Що поверне цей метод?

static String pick() {    try {        return "try";    } finally {        return "finally";    }}

Відповідь — "finally". Блок finally виконується завжди, і його return перекриває return із try. finally — як останній коментар на код-рев'ю: останнє слово завжди за ним. На співбесіді цей код показують не для того, щоб так писали, а щоб перевірити, чи розумієш ти порядок виконання. А правильна відповідь на «чи варто так писати?» — ні, ніколи.

Винятки: що ламається і хто за це відповідає

Питання про винятки здаються нудними аж до моменту, коли прод падає через проковтнутий catch.

• Checked і unchecked: у чому різниця? Щодо checked компілятор змушує або обробити виняток, або оголосити його в throws: наприклад, IOException, коли працюєш із файлом. Unchecked, нащадки RuntimeException, — зазвичай помилки в самому коді на кшталт NullPointerException або IllegalArgumentException, і обробляти їх компілятор не вимагає. Добра відповідь на співбесіді додасть: checked — для ситуацій, з яких програма може розумно вийти, unchecked — для багів, які треба лагодити, а не ловити.
• Що робить try-with-resources? Усе, що оголошено в дужках після try і реалізує AutoCloseable, закриється автоматично, навіть якщо всередині вилетить виняток:

try (var reader = Files.newBufferedReader(Path.of("orders.csv"))) {    return reader.readLine();}

Жодних finally з ручним close() і вкладених try всередині finally — як це було до Java 7.

• Чи можна перехоплювати OutOfMemoryError? Технічно можна: це нащадок Throwable. Але OutOfMemoryError — це Error, а не Exception, тобто сигнал про проблему, з якою програма зазвичай не може нормально впоратися. Ловити його, щоб «продовжити роботу», — те саме, що на кораблі, який іде на дно, акуратно переставляти шезлонги. Єдиний розумний варіант — записати в лог і акуратно завершитися.

ООП: не визначення, а приклади

Тут головна помилка — відповідати визначеннями з підручника. «Інкапсуляція — це приховування даних». Дякую, а де це знадобилося у твоєму коді?

• Абстрактний клас чи інтерфейс? Інтерфейс описує, що об'єкт уміє, і клас може реалізувати багато інтерфейсів. Абстрактний клас — спільна основа зі станом і частковою реалізацією, і успадковуватися можна лише від одного. З Java 8 в інтерфейсах є default-методи, тому межа стала тоншою — і про це люблять запитати.
• Перевантаження і перевизначення. Перевантаження — методи з однаковим ім'ям і різними параметрами, вибір на етапі компіляції. Перевизначення — нова реалізація методу батьківського класу в нащадку, вибір під час виконання.
• Як зробити клас незмінним? Поля private final, немає сетерів, клас final або із закритим конструктором, а змінювані об'єкти всередині — копіювати під час отримання й віддачі. Або просто взяти record, про нього нижче.

Колекції: про HashMap спитають майже напевно

Якщо з колекцій тобі поставлять лише одне питання, це буде HashMap. Якщо два — друге теж буде про HashMap.

Як улаштований HashMap? Усередині масив «кошиків». За hashCode() ключа обирається кошик, а всередині нього елементи зберігаються списком. Якщо в одному кошику їх стає більше восьми (а сам масив уже має щонайменше 64 кошики), список перетворюється на червоно-чорне дерево, щоб пошук не деградував. Коли масив заповнений на 75% — це типовий load factor, — він збільшується вдвічі й усі елементи перерозподіляються.

А тепер підступ:

Map<List<Integer>, String> map = new HashMap<>();List<Integer> key = new ArrayList<>(List.of(1));map.put(key, "value");key.add(2);String found = map.get(key); // null

Ми змінили ключ після того, як поклали його в мапу. Його hashCode() змінився, HashMap шукає його в іншому кошику і не знаходить. Запис при цьому лишився в мапі, просто дістати його за цим ключем уже не вийде. Звідси золоте правило: ключі HashMap мають бути незмінними.

Інші часті питання:

• ArrayList чи LinkedList? У реальному коді майже завжди ArrayList: доступ за індексом миттєвий, а дані лежать у пам'яті щільно. LinkedList виграє лише в рідкісних сценаріях із частими вставками в середину через ітератор. Його всі знають із підручників, а в продакшені бачили одиниці — приблизно як снігову людину.
• ConcurrentHashMap чи Collections.synchronizedMap()? Обидві потокобезпечні, але synchronizedMap блокує всю мапу цілком, а ConcurrentHashMap дає змогу багатьом потокам працювати з нею паралельно.
• Звідки береться ConcurrentModificationException? Від зміни колекції під час обходу for-each. Видаляти елементи під час обходу треба через ітератор або removeIf().

Stream API: код в один рядок, питання — у три

Стріми люблять і на співбесідах, і в реальному коді. А ще в них дуже легко написати щось гарне й неправильне.

• Чому стрім «нічого не робить»? Операції на кшталт filter, map і sorted — проміжні: вони повертають новий стрім і самі по собі нічого не запускають. Стрім лінивий: робота починається лише на термінальній операції — collect, count, forEach. До неї жоден елемент ніхто не чіпає. Звідси підступ: якщо написати стрім із map і забути термінальну операцію, код усередині map не виконається жодного разу. Стрім без термінальної операції — як список справ на понеділок: складений гарно, але нічого не відбувається.
• map() чи flatMap()? map — один елемент на вході, один на виході. flatMap — із кожного елемента виходить цілий стрім, а потім усі вони зливаються в загальний потік. Найчастіший приклад — «розплющити» список списків:

List<List<String>> teams = List.of(        List.of("Аня", "Борис"),        List.of("Віка"));List<String> people = teams.stream()        .flatMap(List::stream)        .toList(); // [Аня, Борис, Віка]

• Чи можна використати стрім двічі? Ні. Після термінальної операції стрім закритий, і повторний виклик кине IllegalStateException. Потрібен ще раз — створи новий.
• Optional: де його псують? Optional чесно попереджає: значення може й не бути. Зіпсувати його найпростіше викликом get() наосліп — це той самий NullPointerException, тільки в окулярах і з накладними вусами. Другий спосіб — робити Optional полем класу або параметром методу: його задумали як тип значення, яке повертає метод. Правильно — orElse, orElseThrow, map і ifPresent.
• Що таке функціональний інтерфейс? Інтерфейс рівно з одним абстрактним методом, наприклад Runnable, Comparator або Function. Саме такі інтерфейси можна реалізувати лямбдою. Анотація @FunctionalInterface не обов'язкова, але попросить компілятор перевірити, що метод справді один.

Багатопотоковість: де валяться мідли

Тут відсіюється найбільше кандидатів на мідла. Бо багатопотоковість не вивчиш за шпаргалкою — її треба зрозуміти. Ну і трохи боятися: це здорове почуття.

• Що гарантує volatile? Видимість змін між потоками: запис у volatile-змінну одним потоком одразу видно іншим. Але атомарності volatile не дає: інкремент count++ — це читання, додавання і запис, і два потоки однаково можуть загубити чиєсь оновлення.
• Що таке happens-before? Правило, яке гарантує, що результати однієї дії видно іншій. Наприклад, усе, що потік зробив до звільнення монітора, побачить потік, який потім цей монітор захопить.
• Як виникає deadlock? Два потоки захоплюють ті самі блокування в різному порядку й вічно чекають один одного. Як двоє дуже чемних людей у вузькому коридорі: «тільки після вас» — і так до кінця робочого дня. Лікується єдиним порядком захоплення блокувань, а знайти можна за дампом потоків.
• Runnable чи Callable? Callable уміє повертати результат і кидати перевірювані винятки. Запускають їх зазвичай через ExecutorService, а не вручну через new Thread().

І так, на мідла з багатопотоковості можуть ганяти довго: це окрема велика тема, яку варто розібрати ґрунтовно, а не з одного абзацу.

Сучасна Java: що питають у 2026

Це та частина, якої не було на співбесідах п'ять років тому, і тому саме вона вирізняє кандидата, який стежить за мовою.

Що таке record? Компактний клас для незмінних даних:

record Point(int x, int y) {}

Один рядок — і в тебе вже є конструктор, гетери x() і y(), equals(), hashCode() і toString(). Усі поля final. Lombok у цей момент мовчки пакує валізи. Ідеально підходить для DTO і тих самих ключів HashMap — якщо, звісно, всередині record не лежить змінюваний ArrayList: final захищає посилання, а не вміст списку.

Навіщо потрібні sealed-класи? Вони явно перелічують, хто може від них успадковуватися. У зв'язці з pattern matching у switch компілятор знає всі можливі варіанти й попередить, якщо якийсь варіант лишився без обробки.

Що таке віртуальні потоки? Легкі потоки, якими керує JVM, а не операційна система. Десять тисяч таких потоків — звичайна справа, можна й сотні тисяч:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {    for (int i = 0; i < 10_000; i++) {        executor.submit(() -> callSlowService());    }}

Добре питання на співбесіді звучить так: коли віртуальні потоки не допоможуть? Відповідь: коли задача впирається в процесор, а не в очікування. Віртуальні потоки добрі там, де код багато чекає — мережа, база, зовнішні сервіси. А обчислювальну задачу вони швидшою не зроблять — як нове крісло не пришвидшить написання коду.

Бонус для мідла: раніше віртуальний потік «прилипав» до системного, якщо блокувався всередині synchronized, і вся вигода зникала. У Java 24 це виправили, але про таку пастку корисно знати — проєкти на Java 21 нікуди не зникли.

Що нового в Java 25? Перелічувати всі зміни не треба, але кілька варто знати. Наприклад, тепер можна написати програму без оголошення класу і зі спрощеним методом main — це зробили для тих, хто тільки починає вчити мову. А конструктори тепер можуть виконувати код до виклику super(), наприклад перевіряти аргументи.

JVM і пам'ять

• З яких областей складається пам'ять JVM? Купа, де живуть об'єкти, стек кожного потоку з локальними змінними і викликами методів, і метаспейс, де зберігаються описи класів.
• Як працює збирач сміття? Видаляє об'єкти, на які більше немає посилань із «живих» частин програми. Він як прибиральник в офісі: викидає лише те, на що ніхто не претендує. Горнятка із запискою «не чіпати» він не торкнеться, навіть якщо воно стоїть там уже три роки. Більшість об'єктів живе дуже недовго, тому купа ділиться на покоління: молоді об'єкти збираються часто і швидко, старі — рідше.
• Чи бувають у Java витоки пам'яті? Так. Збирач сміття не видалить об'єкт, на який хтось усе ще посилається. Класика — статична колекція, до якої лише додають і ніколи нічого не видаляють. Те саме горнятко із запискою, тільки на гігабайт. Або той самий HashMap зі зміненим ключем: записи лишаються, а дістати їх уже не можна.

Spring і бази даних

Якщо у вакансії є Spring, а він там є майже завжди (іноді здається, що навіть у вакансії баристи), готуйся до цього блоку окремо.

• IoC і DI: що це і чому впровадження через конструктор краще? Spring сам створює об'єкти й передає їм залежності. Через конструктор краще, бо залежності видно одразу, поля можна зробити final, а клас легко протестувати без Spring.
• Чому @Transactional не спрацьовує? Класика: метод з @Transactional викликають з іншого методу того самого класу. Транзакцією керує проксі, а виклик усередині класу проходить повз нього — як співробітник, який заходить до офісу через чорний хід і оминає турнікет на прохідній. Це одне з найчастіших питань на мідла.
• Що таке проблема N+1? Завантажили список зі 100 замовлень одним запитом, а потім для кожного замовлення окремим запитом підтягнули покупця. Усього 101 запит замість одного-двох. База даних у цей момент тихо плаче. Лікується JOIN FETCH або EntityGraph.
• Які бувають рівні ізоляції транзакцій? Від READ UNCOMMITTED до SERIALIZABLE. Важливо не лише перелічити, а й пояснити, від яких аномалій захищає кожен: брудне читання, неповторюване читання, фантомне читання.
• INNER JOIN чи LEFT JOIN? Уяви дві таблиці: покупці та замовлення. INNER JOIN залишить лише тих покупців, у кого є хоча б одне замовлення, — решта просто зникне з результату. LEFT JOIN збереже всіх покупців, а в колонках замовлення в «порожніх» буде NULL. Класичне питання на розуміння: як знайти покупців, у яких немає жодного замовлення? Відповідь — LEFT JOIN і умова, що поле з таблиці замовлень IS NULL.
• Навіщо потрібні індекси і чому не можна повісити їх на все? Індекс пришвидшує пошук, як зміст у книжці: базі не треба читати всю таблицю. Але кожен індекс сповільнює вставлення й оновлення, бо його теж треба підтримувати, і займає місце. Тому індекси створюють під реальні запити, а не про всяк випадок. Індекси на все — як виділити маркером увесь підручник: виділено все, отже, не виділено нічого.

Окремо щодо баз даних у нас є докладний розбір питань зі співбесід щодо баз даних.

Лайвкодинг і AI: що змінилося

Лайвкодинг лякає найбільше. Розв'язувати задачу, коли на тебе дивляться, — ще той стрес: навіть звичайний цикл for раптом починає виглядати підозріло. Але ось секрет: інтерв'юерові майже завжди важливіше, як ти думаєш, ніж те, чи правильною вийшла відповідь.

Що цінують на лайвкодингу:

• Говорити вголос. Мовчазний кандидат — чорна скринька. Кандидат, який міркує, показує хід думок, навіть якщо десь збивається.
• Уточнювати умову. «Чи можуть у вхідних даних бути null?», «Який розмір масиву?» — це не тупість, а професіоналізм.
• Починати з простого рішення. Спершу робоче, потім оптимальне. Краще робочий перебір, ніж гарна ідея, яку не встигли дописати.

Розбір задачі: як це виглядає наживо

Візьмімо типову задачу з лайвкодингу: знайти перший символ у рядку, який трапляється рівно один раз. Для рядка "swiss" відповідь — "w".

Крок 1. Уточни умову. Перш ніж писати код, постав кілька запитань. Що повернути, якщо такого символу немає? Чи розрізняються великі й малі літери? Чи може рядок бути порожнім? Інтерв'юер відповість, а заразом побачить, що ти думаєш про крайові випадки.

Крок 2. Просте рішення. Для кожного символу пробігти весь рядок і порахувати, скільки разів він трапляється. Працює, але це O(n²): на рядку в мільйон символів буде дуже довго. Скажи це вголос — інтерв'юерові важливо, що ти розумієш ціну рішення.

Крок 3. Оптимізація. Досить двох проходів: спершу порахувати всі символи, потім знайти перший з одиницею. Щоб не втратити порядок символів, підійде LinkedHashMap. А оскільки символу може й не бути, повертаємо Optional, як і домовлялися в розділі про стріми:

static Optional<Character> firstUnique(String text) {    Map<Character, Integer> counts = new LinkedHashMap<>();    for (char c : text.toCharArray()) {        counts.merge(c, 1, Integer::sum);    }    for (Map.Entry<Character, Integer> entry : counts.entrySet()) {        if (entry.getValue() == 1) {            return Optional.of(entry.getKey());        }    }    return Optional.empty();}

Тепер це O(n): кожен символ обробляємо сталу кількість разів.

Крок 4. Перевір себе. Прожени в голові кілька прикладів: "swiss" — поверне "w", "aabb" — порожній Optional, порожній рядок — теж порожній Optional. Якщо інтерв'юер запитає, чому саме LinkedHashMap, а не HashMap, у тебе вже є відповідь: звичайний HashMap не пам'ятає порядку вставлення, і «першим» міг би виявитися будь-який символ.

А тепер бонус, який приємно здивує інтерв'юера: можна обійтися і звичайним HashMap, якщо вдруге пройти не по мапі, а по самому рядку. Порядок тоді задає рядок, а мапа лише зберігає лічильники. Два робочі варіанти й зрозумілий вибір між ними — саме те, що хочуть побачити на лайвкодингу.

Ось і весь секрет лайвкодингу. Не блискуче рішення з першої спроби, а зрозумілий шлях: уточнити умову, розв'язати просто, оцінити складність, покращити, перевірити.

А чи можна користуватися AI? Залежить від компанії, а іноді й від етапу. Якщо дозволено, інтерв'юер зазвичай дивиться не на те, що згенерувала нейромережа, а на те, як ти її використовуєш: що просиш, як перевіряєш результат, чи помічаєш помилки. У Canva, наприклад, прямо кажуть: важливо не те, що AI написав за кандидата, а вміння прочитати згенерований код, зрозуміти його й покращити — і пояснити кожне технічне рішення. Якщо ти не можеш пояснити, що робить код, AI тобі не допоміг, а підставив. Це як прийти на іспит зі шпаргалкою, написаною незнайомою мовою.

Чесно кажучи, це найсильніший аргумент на користь фундаменту, який я знаю. Нейромережа напише тобі HashMap зі змінюваним ключем за секунду. А помітити, що так не можна, зможеш тільки ти.

Шпаргалка: що насправді перевіряють

Кожне питання на співбесіді — це питання з подвійним дном. Ось що стоїть за найчастішими:

Як підготуватися за три тижні

Тиждень 1 — основи. Java Core, ООП, винятки, колекції та Stream API. Не читай відповіді — пиши код. Поклади змінюваний ключ у HashMap і подивись, що буде. Зламай equals() і hashCode() і знайди, де це вилізе.

Тиждень 2 — багатопотоковість і сучасна Java. Напиши програму з deadlock і знайди його за дампом потоків. Перепиши кілька класів на record. Запусти десять тисяч віртуальних потоків і подивись, як це працює.

Тиждень 3 — Spring, бази даних і практика. Збери маленький застосунок на Spring Boot із базою даних, злови в себе проблему N+1 і полагодь її. І обов'язково проведи кілька пробних співбесід — із другом, ментором або хоча б уголос перед дзеркалом.

І головне правило: не завчай відповіді. Кожне питання з цієї статті можна перевірити кодом за п'ять хвилин. Перевірене руками запам'ятовується назавжди, завчене — до першого «а чому?».

І тоді в кімнаті знову стане тихо. Тільки тепер — тому, що інтерв'юерові нічого додати.

Де практикуватися

На курсі Java у JavaRush майже кожна тема з цієї статті — від колекцій і винятків до багатопотоковості — відпрацьовується на задачах із миттєвою перевіркою. Помилка в equals() і hashCode() спливає одразу, а не на співбесіді.

А якщо хочеться пройти шлях до першого оферу з ментором, рев'ю коду і проєктами в портфоліо, є Java University: там є й кар'єрний центр, де допомагають із резюме і готують до співбесід.

Ну а якщо хочеться ще більше питань із докладними відповідями — відкривай нашу серію «Розбір запитань та відповідей зі співбесід на Java-розробника» і великий гайд із підготовки до перших співбесід на Java Junior. Там вистачить на багато вечорів.

Часті запитання

Які питання на співбесіді Java ставлять розробникам у 2026 році? Основа не змінюється: Java Core, ООП, винятки, колекції, Stream API, багатопотоковість, JVM, Spring і бази даних. У 2026 році до них додалися питання із сучасної Java — records, sealed-класи, pattern matching, віртуальні потоки і зміни в Java 25 — а також зі Spring Boot 4.

Що питають на співбесіді Java Junior? Здебільшого базу: чим == відрізняється від equals(), як пов'язані equals() і hashCode(), чому String незмінний, як улаштований HashMap, чим ArrayList відрізняється від LinkedList, різницю між checked і unchecked винятками, try-with-resources і різницю між map() і flatMap() у Stream API. Важливо не лише знати відповідь, а й пояснити, чому це так.

Які питання ставлять мідлу на співбесіді з Java? Багатопотоковість (volatile, happens-before, deadlock, ExecutorService), будову JVM і збирача сміття, Spring (DI, @Transactional і його пастки), Hibernate (проблема N+1, ліниве завантаження) і рівні ізоляції транзакцій. Плюс багато питань про реальний досвід.

Чи можна користуватися AI на співбесіді з Java? Залежить від компанії і навіть від етапу. Деякі компанії дозволяють або вимагають AI на технічному інтерв'ю, багато хто, як і раніше, забороняє. Уточнюй у рекрутера заздалегідь. Якщо AI дозволений, перевіряють, чи вмієш ти пояснити й перевірити згенерований код.

Яка версія Java зараз актуальна для співбесід? Поточна LTS-версія — Java 25, що вийшла у вересні 2025 року. Водночас багато компаній ще працюють на Java 17 і 21, тому корисно знати, що з'явилося в кожній із цих версій.

Які задачі дають на лайвкодингу з Java? Зазвичай невеликі алгоритмічні задачі на рядки, масиви й колекції: знайти перший символ, що не повторюється, дублікати в масиві, перевірити паліндром, згрупувати дані через HashMap. Інтерв'юер дивиться не лише на результат, а й на те, як ти уточнюєш умову, оцінюєш складність і перевіряєш крайові випадки.

Як швидко підготуватися до співбесіди з Java? За три тижні можна добре освіжити базу: перший тиждень — Java Core і колекції, другий — багатопотоковість і сучасна Java, третій — Spring, бази даних і пробні співбесіди. Головне — перевіряти кожну відповідь кодом, а не завчати.