Есть ли кодовая база на Java

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

Почти в каждой Android-команде остались модули на Java, и интервьюер хочет понять, возьмётесь ли вы за них спокойно, без желания всё переписать. Следом спрашивают про интероп Kotlin и Java и про то, как бы вы мигрировали такой модуль. Этот же вопрос бывает и у кандидата в конце встречи, и это хороший способ узнать о техдолге команды.

Как отвечать

Каркас: где встречали Java, что с ней делали, как она уживалась с Kotlin. Примеры нужны свои: какой модуль, какого размера, что вы в нём меняли.

Покажите, что знаете, где проходят швы интеропа:

• nullability: Java-типы приходят в Kotlin платформенными (String!), компилятор не проверяет их на null. Спасают аннотации @Nullable и @NonNull из androidx.annotation на стороне Java;
• аргументы по умолчанию: Java их не видит, перегрузки генерирует @JvmOverloads;
• статические члены: функции из companion object видны в Java как статические только с @JvmStatic, поля с @JvmField;
• исключения: Kotlin не объявляет checked exceptions, и Java-код не сможет их поймать без @Throws.

Про миграцию: новый код пишется на Kotlin, старые классы переводятся по одному, когда в них всё равно идёт работа, и сначала покрываются тестами. Встроенный конвертер Android Studio даёт черновик, который приходится вычищать от !! и лишних nullable-типов. Заодно обычно меняются и подходы: RxJava и AsyncTask на корутины, XML-разметка на Compose.

Если с Java вы почти не работали, скажите об этом прямо и добавьте, что читаете её свободно, так как это та же JVM, и уже подключали Java-библиотеки через интероп.

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

Отвечают «на Java я не пишу, это легаси». Команда слышит, что половину кодовой базы вы трогать не будете.

Называют плюсом Java кроссплатформенность. В Android это не аргумент: и Java, и Kotlin компилируются в байткод JVM, а затем в один и тот же DEX.

Предлагают перевести весь проект конвертером за спринт. Без тестов это регрессия по всему приложению и огромный пулл-реквест, который никто не сможет толком проверить.