Співбесіда Java-розробника охоплює семантику мови, колекції, багатопотоковість, Spring та вміння міркувати про JVM. Нижче — питання, які ставлять найчастіше, кожне з еталонною відповіддю. Junior: базова теорія, визначення та прості практичні кейси.
== порівнює посилання — чи вказують дві змінні на один обʼєкт у памʼяті. equals() порівнює вміст, якщо клас його перевизначив; за замовчуванням Object.equals зводиться до того самого ==. Саме тому два рядки, зібрані в рантаймі, дають false при == і true при equals(), і це найчастіша пастка на співбесіді з Java.
Абстрактний клас може зберігати стан і мати конструктори, він описує, чим обʼєкт є; успадкуватися можна лише від одного. Інтерфейс описує, що обʼєкт вміє, і реалізувати їх можна багато. З Java 8 інтерфейси мають default-методи, тому практичне правило таке: спільний стан — абстрактний клас, спільна здатність — інтерфейс.
Автопакування — це автоматичне перетворення між примітивами та обгортками. Підводить воно у двох місцях: порівняння обгорток через == випадково працює для малих значень через кеш Integer від -128 до 127 і потім тихо перестає працювати, а розпакування null-Integer кидає NullPointerException у рядку, що виглядає звичайною арифметикою.
Попри схожі імена вони не повʼязані. final забороняє перепризначення змінної, перевизначення методу або успадкування класу. finally — блок, який виконується незалежно від того, було виключення чи ні, для звільнення ресурсів. finalize — метод, який збирач сміття міг викликати перед видаленням обʼєкта; він ненадійний і застарілий, замість нього try-with-resources.
ArrayList обгортає розширюваний масив: доступ за індексом O(1), але вставка в середину зсуває все, що після неї. LinkedList — двозвʼязний список: вставка у відомого вузла O(1), але дістатися до індексу n коштує n кроків, і кожен елемент несе накладні витрати на вказівники. На практиці ArrayList виграє майже завжди, бо локальність кешу важливіша за асимптотику на реальному залізі.
Static-член належить класу, а не екземпляру: він існує в одному примірнику незалежно від кількості обʼєктів і доступний без створення обʼєкта. Забувають про наслідок — статичне поле це спільний змінюваний стан на весь застосунок, що зручно для констант і є джерелом важких багів для всього, що змінюється.
Checked успадковуються від Exception, і компілятор змушує їх зловити або оголосити; вони описують ситуації, з яких викликач може розумно відновитися, наприклад відсутність файлу. Unchecked успадковуються від RuntimeException і сигналять про помилки програміста — null, невірний аргумент. Unchecked для багів, checked помірно, бо примус обробляти зазвичай народжує порожні catch-блоки.
Якщо два обʼєкти рівні, вони зобовʼязані повертати однаковий хеш-код; зворотне не вимагається. Порушите — і HashMap перестане працювати: ви кладете обʼєкт, шукаєте за рівним йому й отримуєте null, бо пошук пішов в іншу корзину. Тому перевизначення одного без іншого — баг, а не питання стилю.
Бо він спільний. Літерали живуть у пулі рядків, і на один екземпляр може посилатися багато місць, тож змінюваний рядок дозволив би одному тримачеві змінити значення в іншого. Незмінність заодно робить рядки потокобезпечними без синхронізації, дозволяє кешувати хеш-код і лишає їх безпечними для завантаження класів і параметрів підключення, де пізня підміна була б дірою в безпеці.
Ні, його можна лише сховати. Перевизначення розвʼязується під час виконання за типом обʼєкта, а статичний метод — під час компіляції за типом посилання. Тому підклас із тією самою статичною сигнатурою не заміняє батьківський: виконається той, що відповідає оголошеному типу, а не фактичному обʼєкту, — саме тому викликати статику через посилання на екземпляр не рекомендують.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю Junior Java Backend →