В банковском Android-приложении 35 экранов, 12 долгоживущих репозиториев и целевое время навигации 150 мс. Как вы распределите владение корутинами между Activity, ViewModel и репозиториями?

Я закреплю каждую корутину за самым узким жизненным циклом, которому действительно нужен ее результат. - Работа по отображению UI остается в lifecycleScope с repeatOnLifecycle, а создание состояния экрана принадлежит viewModelScope, чтобы поворот не перезапускал полезную работу. - Репозитории отдают suspend-функции или холодные Flow и не создают скрытые application scope; отменой владеет вызывающая сторона, если процесс явно не должен переживать экран. - Редкие процессные задачи используют один внедренный application CoroutineScope с SupervisorJob, именованными дочерними задачами и явным завершением в тестах.

Ktor-сервис обрабатывает 8000 запросов в секунду с p99 SLA 200 мс и обновляет кеш каждую минуту. Как вы разделите request scope и application scope?

Я оставлю работу запроса дочерней к scope вызова, а application scope выделю только для задач, которыми явно владеет процесс. - Запросы к базе, downstream HTTP-вызовы и сборка ответа наследуют отмену и дедлайн запроса, поэтому отключившиеся или просроченные вызовы перестают расходовать ресурсы. - Обновления кеша работают под application SupervisorJob, потому что ошибка одного обновления не должна отменять обработку запросов или другие обновления. - При завершении сервис сначала прекращает прием, затем отменяет application scope и не более 10 секунд ждет завершения принадлежащих ему задач.

Android-клиент при старте декодирует изображения, выполняет запросы Room и три HTTP-вызова, но на слабых устройствах может использовать не более четырех фоновых потоков. Как вы распределите бюджеты диспетчеров?

Я подчиню все исполнители стартовых задач единому бюджету из четырех потоков, включая Room и HTTP-клиент. - Один общий Executor на четыре потока обслуживает диспетчер корутин, исполнители запросов и транзакций Room и Dispatcher HTTP-клиента; если клиенту нужен отдельный исполнитель, его потоки входят в тот же бюджет из четырех. - Представления диспетчера ограничивают декодирование двумя одновременными задачами и стартовую работу Room или HTTP двумя задачами для каждого типа, а общий Executor сохраняет глобальный лимит при их пересечении. - Трассировка старта и подсчет имен потоков на целевом двухъядерном устройстве должны показывать не более четырех фоновых потоков; один limitedParallelism не ограничит независимые пулы Room или HTTP.

Kotlin/JVM-сервис цен получает 2000 вычислений в секунду, каждое занимает 12 мс CPU, на контейнере с 8 ядрами и целевым p99 250 мс. Как вы спроектируете параллелизм корутин?

Я отклоню цель в 2000 вычислений в секунду на одном 8-ядерном контейнере, потому что требуемый CPU втрое превышает его физическую емкость. - Расчет емкости: 2000 × 12 мс = 24 CPU-секунды за секунду реального времени, тогда как восемь полностью занятых ядер дают только 8 CPU-секунд. - До учета запаса нужны минимум три 8-ядерных контейнера; я начну с четырех, что даст около 75% номинальной загрузки CPU и оставит ресурс для GC, разбора запросов и всплесков. - Каждый контейнер использует параллелизм по числу ядер и ограниченный прием, отклоняя запросы, которые не уложатся в 250 мс, вместо накопления бесконечной очереди. - Перед запуском четырех контейнеров нагрузочный тест на 2000 вычислений в секунду должен измерить время в очереди, насыщение CPU и число просроченных запросов.

Поисковый запрос обращается к шести провайдерам и должен ответить за 300 мс, даже если один необязательный провайдер не отвечает. Как вы структурируете корутины?

Я использую ограниченный coroutineScope для обязательной работы и изолирую только необязательного провайдера семантикой supervisorScope. - Обязательные дочерние async наследуют дедлайн 300 мс, а ошибка любого из них отменяет соседей, потому что полный обязательный результат уже невозможен. - Необязательный провайдер преобразует собственную ошибку в явный результат unavailable, не скрывая отмену родителя. - Каждый провайдер получает меньший таймаут, например 220 мс, чтобы осталось время на ранжирование и сериализацию общего ответа.

Общий Kotlin SDK используют 18 модулей приложения, и каждая операция должна отменяться не позднее 100 мс после ухода пользователя с экрана. Какой контракт coroutine API вы опубликуете?

Я опубликую suspend-API и холодные Flow, которые корректно реагируют на отмену вызывающей стороны и не запускают внутри отвязанные задачи. - Длинные циклы вызывают ensureActive или используют отменяемые suspend-примитивы, а блокирующие vendor-вызовы оборачиваются в отменяемый адаптер только при поддержке прерывания самим vendor. - Очистка остается в finally, а NonCancellable охватывает только минимальную обязательную операцию закрытия, но не весь сетевой повтор. - Контрактные тесты отменяют каждую публичную операцию и проверяют завершение за 100 мс вместе с освобождением базового ресурса.

У мобильного checkout есть end-to-end SLA 2 секунды на вызовы inventory, fraud и payment. Как вы передадите временные бюджеты через слои корутин?

Я передам по всему графу вызовов один монотонный дедлайн и буду вычислять каждый оставшийся таймаут от него. - Слой оркестрации явно выделяет подбюджеты, например 300 мс для inventory, 500 мс для fraud и 800 мс для payment, оставляя время на локальную запись и отображение. - Репозитории принимают контекст запроса или абстракцию дедлайна, а не начинают новый двухсекундный таймаут, способный умножить общую задержку. - На границе timeout преобразуется в типизированный доменный результат, а CancellationException без изменений идет вверх.

Сорок feature-модулей сейчас отдают собственные фабрики CoroutineScope, а архитектурное ревью требует единую модель владения за два релиза. Какой дизайн вы одобрите?

Я уберу фабрики scope из feature-модулей и стандартизирую scope по владельцу жизненного цикла, а не по модулю. - UI-модули получают scope ViewModel или lifecycle от Android-владельцев, обработчики запросов наследуют server call scope, а репозитории отдают structured API без хранения произвольных scope. - Небольшой platform-модуль предоставляет только именованные application и test scope с задокументированными владением, отменой и завершением. - Статическое правило в течение двухрелизной миграции запрещает GlobalScope и неуправляемое создание CoroutineScope вне platform-модуля.

Репозиторий обслуживает 15 экранов, и каждому collector нужен новый запрос с фильтром по собственному account ID. Должен ли публичный API возвращать Flow, StateFlow или SharedFlow?

Я верну холодный Flow, потому что запрос параметризован для каждого caller и у репозитория нет единственного собственного текущего значения. - Каждая подписка создает работу для конкретного account ID, поэтому API описывает, перезапускает ли инвалидация Room запрос и как отмена закрывает подписку. - ViewModel может преобразовать его в StateFlow через stateIn и WhileSubscribed для совместного использования экраном, но эта lifecycle-политика не принадлежит репозиторию. - Если дублирующиеся collectors дороги, Flow разделяет владелец на том слое, где известны правильный scope и длительность replay.

У Compose-экрана 11 независимых источников данных, и после поворота он должен сразу восстановить последнее отображаемое состояние. Как вы предоставите StateFlow?

Я предоставлю из ViewModel один неизменяемый StateFlow с полным состоянием экрана. - ViewModel объединяет доменные Flow в стабильный sealed UI state и применяет stateIn(viewModelScope, WhileSubscribed(5_000), initialState), чтобы пережить короткий разрыв подписчиков. - MutableStateFlow остается private, а изменения используют atomic update, чтобы параллельные действия не перезаписывали друг друга. - Навигация и временные эффекты не входят в долговечное состояние, если их повтор после поворота не является намеренной частью контракта.

Три подписчика наблюдают за состоянием входа, но команда навигации должна быть обработана один раз и не повторяться после 500-миллисекундной смены конфигурации. Используете ли вы SharedFlow?

Я не стану моделировать одноразовую команду навигации как общий поток событий с повторной доставкой. - Стабильное состояние входа хранится в StateFlow, а команду навигации текущий владелец UI выводит из перехода состояния или получает через Channel с одним потребителем. - Если SharedFlow нужен нескольким наблюдателям, replay равен нулю, а контракт допускает потерю события при отсутствии подписчиков. - Тест покрывает поворот устройства во время отправки, поскольку и повторная доставка, и потеря команды заметны пользователю.

Telemetry Flow получает 20 000 событий в секунду, uploader обрабатывает 5000, а память ограничена 32 МБ. Какой контракт backpressure вы зададите?

Я явно задам политику потерь и использую ограниченный буфер, рассчитанный по байтам и допустимой задержке. - Малоценные счетчики используют DROP_OLDEST с агрегацией, а audit-события идут в долговечное хранилище отдельно, потому что не могут разделять lossy-контракт. - Uploader собирает до 200 событий или 100 мс и ограничивает число параллельных загрузок, чтобы downstream pressure оставался конечным. - Метрики показывают потерянные события, заполнение буфера и возраст старейшего события, позволяя проверить лимит 32 МБ под синтетическим пиком.

Dashboard объединяет 25 StateFlow, и любое обновление должно отобразиться за 50 мс без пересчета всех дорогих агрегатов. Как вы построите граф Flow?

Я разделю граф по частоте обновлений и буду пересчитывать только агрегаты с изменившимися входами. - Стабильные доменные подграфы создают типизированные промежуточные StateFlow, поэтому тик часов не пересчитывает суммы счетов или разрешения. - Дорогой mapping выполняется до combine, применяет distinctUntilChanged к значимым неизменяемым значениям и не сравнивает изменяемые коллекции. - Бенчмарк проводит через граф 1000 обновлений и измеряет вычисления и main-thread rendering относительно бюджета 50 мс.

Bluetooth SDK отправляет callbacks из четырех потоков и разрешает только один активный listener на устройство. Как вы предоставите его как Flow десяти модулям приложения?

Я оберну callback в callbackFlow и размещу sharing для нескольких подписчиков за одним владельцем уровня устройства. - awaitClose удаляет ровно тот же listener, trySend безопасно принимает параллельные callbacks, а неудачные отправки учитываются вместо рекурсивных повторов. - Владелец применяет shareIn с задокументированными replay и stop timeout, чтобы десять collectors не регистрировали десять native listeners. - Отключение устройства представлено типизированным состоянием или завершением потока по контракту SDK, а отмена collector освобождает только его подписку.

Приложения для Android и iOS используют общие правила оформления заказа, но Android работает с Room, iOS с Core Data, а окончательную цену рассчитывает сервер. Что должно находиться в commonMain?

Я вынесу в общий код детерминированные правила и сценарии оформления заказа, а хранилища, UI и окончательный расчет цены оставлю их владельцам. - commonMain содержит денежные типы, валидацию, переходы корзины, интерфейсы репозиториев и модели сериализации, которые оба клиента должны трактовать одинаково. - androidMain и iosMain реализуют постоянное и защищенное хранение через Room и Core Data, не протаскивая их API в общий код. - Серверный расчет остается удаленным контрактом; его дублирование в commonMain создаст два источника истины и небезопасные суммы для автономного режима.

KMP-библиотека на 30 модулей нацелена на Android, iOS arm64, iOS simulator arm64 и JVM-сервер. Как вы спроектируете иерархию source sets?

Я использую default hierarchy template и добавляю промежуточные source sets только для кода с реальной общей платформенной возможностью. - commonMain хранит переносимый домен, iosMain владеет Apple-реализациями для обеих iOS-целей, а явный jvmAndAndroidMain оправдан только при настоящем совпадении зависимостей Android и сервера. - Target-specific source sets остаются тонкими для Keychain, Android Context и подобных API, без кастомной иерархии ради случайного совпадения одного файла. - CI компилирует каждую цель и публикует библиотеку из одной канонической сборки, чтобы неиспользуемый simulator source set не деградировал незаметно.

Общему модулю аутентификации нужно secure storage на Android, iOS и JVM, а политика ревью разрешает не более пяти expect-деклараций. Как вы примените expect и actual?

Я определю одну узкую common capability и применю expect только к платформенной фабрике, которая ее предоставляет. - commonMain объявляет SecureTokenStore с readToken, writeToken и clear плюс доменные ошибки, без типов Keychain, Keystore или файловой системы. - Каждая actual-фабрика возвращает небольшую платформенную реализацию, проверяемую одной common contract suite. - Общая политика expiry и refresh токена остается обычным common-кодом, сохраняя лимит пяти деклараций для настоящих платформенных разрывов.

KMP-фреймворк экспортирует Swift-команде 80 деклараций, а call sites должны читаться без знания Kotlin и пройти API-ревью за две недели. Как вы оформите границу?

Я опубликую небольшой Swift-facing facade вместо экспорта внутреннего графа Kotlin-модулей. - Методы facade используют стабильные имена, простые классы, nullable-значения и предсказуемые коллекции, а Kotlin-only sealed-иерархии остаются за адаптерами. - Suspend и Flow API оборачиваются в согласованную со Swift-командой модель async и observation, включая семантику отмены и доставки на main thread. - iOS sample target компилирует характерные Swift-вызовы в CI, делая изменения generated headers и несовместимые имена видимыми за двухнедельное ревью.

Общий SDK передает в Swift 100 обновлений в секунду и должен остановиться за 200 мс после исчезновения view. Какой interop-контракт вы выберете?

Я предоставлю явный subscription handle, отмена которого управляет базовой подпиской на общий Flow. - Kotlin владеет collection в дочернем scope этого handle, а Swift получает значения на задокументированной очереди без неявного global scope. - Адаптер применяет ограниченную conflated-политику, если Swift нужно только последнее состояние; lossless-записи используют отдельный durable или batch API. - Interop-тесты отменяют подписку из Swift, проверяют остановку collection за 200 мс и освобождение захваченных callbacks.

KMP-приложение поставляет 600 локализованных строк, изображения и юридический текст, который iOS должна обновлять своим native release process. Кто должен владеть ресурсами?

Я распределю ресурсы по владению presentation и release process, а не буду принудительно переносить все assets в общий код. - Общие доменные сообщения используют стабильные error keys или типизированные outcomes, а Android и iOS владеют пользовательским текстом по своим localization и legal workflow. - Полностью одинаковые Compose Multiplatform assets могут жить в shared resources, только если обе platform-команды согласны с упаковкой и cadence обновлений. - CI проверяет parity ключей и пропущенные переводы без зависимости commonMain от Android Resources или API iOS bundle.

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

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior Kotlin-разработчик.

Смотреть пример резюме: Kotlin-разработчик →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

ownershipcoroutinesviewmodel

Я закреплю каждую корутину за самым узким жизненным циклом, которому действительно нужен ее результат.

Работа по отображению UI остается в lifecycleScope с repeatOnLifecycle, а создание состояния экрана принадлежит viewModelScope, чтобы поворот не перезапускал полезную работу.
Репозитории отдают suspend-функции или холодные Flow и не создают скрытые application scope; отменой владеет вызывающая сторона, если процесс явно не должен переживать экран.
Редкие процессные задачи используют один внедренный application CoroutineScope с SupervisorJob, именованными дочерними задачами и явным завершением в тестах.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат превратить structured concurrency в обязательные правила владения для крупной Android-кодовой базы.

ktorcachingcoroutines

Я оставлю работу запроса дочерней к scope вызова, а application scope выделю только для задач, которыми явно владеет процесс.

Запросы к базе, downstream HTTP-вызовы и сборка ответа наследуют отмену и дедлайн запроса, поэтому отключившиеся или просроченные вызовы перестают расходовать ресурсы.
Обновления кеша работают под application SupervisorJob, потому что ошибка одного обновления не должна отменять обработку запросов или другие обновления.
При завершении сервис сначала прекращает прием, затем отменяет application scope и не более 10 секунд ждет завершения принадлежащих ему задач.

Зачем это спрашивают: Интервьюер оценивает разделение жизненных циклов, распространение отмены и корректное завершение серверного процесса под нагрузкой.

queriesroomhttp

Я подчиню все исполнители стартовых задач единому бюджету из четырех потоков, включая Room и HTTP-клиент.

Один общий Executor на четыре потока обслуживает диспетчер корутин, исполнители запросов и транзакций Room и Dispatcher HTTP-клиента; если клиенту нужен отдельный исполнитель, его потоки входят в тот же бюджет из четырех.
Представления диспетчера ограничивают декодирование двумя одновременными задачами и стартовую работу Room или HTTP двумя задачами для каждого типа, а общий Executor сохраняет глобальный лимит при их пересечении.
Трассировка старта и подсчет имен потоков на целевом двухъядерном устройстве должны показывать не более четырех фоновых потоков; один limitedParallelism не ограничит независимые пулы Room или HTTP.

Зачем это спрашивают: Интервьюер хочет увидеть конкретный бюджет параллелизма, связанный с типом нагрузки и ограничениями устройства.

kotlincoroutinesjvm

Я отклоню цель в 2000 вычислений в секунду на одном 8-ядерном контейнере, потому что требуемый CPU втрое превышает его физическую емкость.

Расчет емкости: 2000 × 12 мс = 24 CPU-секунды за секунду реального времени, тогда как восемь полностью занятых ядер дают только 8 CPU-секунд.
До учета запаса нужны минимум три 8-ядерных контейнера; я начну с четырех, что даст около 75% номинальной загрузки CPU и оставит ресурс для GC, разбора запросов и всплесков.
Каждый контейнер использует параллелизм по числу ядер и ограниченный прием, отклоняя запросы, которые не уложатся в 250 мс, вместо накопления бесконечной очереди.
Перед запуском четырех контейнеров нагрузочный тест на 2000 вычислений в секунду должен измерить время в очереди, насыщение CPU и число просроченных запросов.

Зачем это спрашивают: Интервьюер проверяет понимание того, что корутины дешевы как задачи, но CPU остается конечным ресурсом.

coroutines

Я использую ограниченный coroutineScope для обязательной работы и изолирую только необязательного провайдера семантикой supervisorScope.

Обязательные дочерние async наследуют дедлайн 300 мс, а ошибка любого из них отменяет соседей, потому что полный обязательный результат уже невозможен.
Необязательный провайдер преобразует собственную ошибку в явный результат unavailable, не скрывая отмену родителя.
Каждый провайдер получает меньший таймаут, например 220 мс, чтобы осталось время на ранжирование и сериализацию общего ответа.

Зачем это спрашивают: Интервьюер оценивает точное применение распространения ошибок, supervision и бюджетов дедлайна.

kotlincoroutinesapi

Я опубликую suspend-API и холодные Flow, которые корректно реагируют на отмену вызывающей стороны и не запускают внутри отвязанные задачи.

Длинные циклы вызывают ensureActive или используют отменяемые suspend-примитивы, а блокирующие vendor-вызовы оборачиваются в отменяемый адаптер только при поддержке прерывания самим vendor.
Очистка остается в finally, а NonCancellable охватывает только минимальную обязательную операцию закрытия, но не весь сетевой повтор.
Контрактные тесты отменяют каждую публичную операцию и проверяют завершение за 100 мс вместе с освобождением базового ресурса.

Зачем это спрашивают: Интервьюер проверяет, спроектирована ли отмена как измеримая гарантия публичного API.

e2ecoroutines

Я передам по всему графу вызовов один монотонный дедлайн и буду вычислять каждый оставшийся таймаут от него.

Слой оркестрации явно выделяет подбюджеты, например 300 мс для inventory, 500 мс для fraud и 800 мс для payment, оставляя время на локальную запись и отображение.
Репозитории принимают контекст запроса или абстракцию дедлайна, а не начинают новый двухсекундный таймаут, способный умножить общую задержку.
На границе timeout преобразуется в типизированный доменный результат, а CancellationException без изменений идет вверх.

Зачем это спрашивают: Интервьюер проверяет композицию дедлайнов и правильное различие между timeout, отменой и доменной ошибкой.

designownershipcoroutines

Я уберу фабрики scope из feature-модулей и стандартизирую scope по владельцу жизненного цикла, а не по модулю.

UI-модули получают scope ViewModel или lifecycle от Android-владельцев, обработчики запросов наследуют server call scope, а репозитории отдают structured API без хранения произвольных scope.
Небольшой platform-модуль предоставляет только именованные application и test scope с задокументированными владением, отменой и завершением.
Статическое правило в течение двухрелизной миграции запрещает GlobalScope и неуправляемое создание CoroutineScope вне platform-модуля.

Зачем это спрашивают: Интервьюер оценивает способность сделать владение корутинами единообразным и проверяемым во множестве модулей.

flowapiqueries

Я верну холодный Flow, потому что запрос параметризован для каждого caller и у репозитория нет единственного собственного текущего значения.

Каждая подписка создает работу для конкретного account ID, поэтому API описывает, перезапускает ли инвалидация Room запрос и как отмена закрывает подписку.
ViewModel может преобразовать его в StateFlow через stateIn и WhileSubscribed для совместного использования экраном, но эта lifecycle-политика не принадлежит репозиторию.
Если дублирующиеся collectors дороги, Flow разделяет владелец на том слое, где известны правильный scope и длительность replay.

Зачем это спрашивают: Интервьюер проверяет, следует ли тип Flow из семантики и владения, а не из удобства.

flow

Я предоставлю из ViewModel один неизменяемый StateFlow с полным состоянием экрана.

ViewModel объединяет доменные Flow в стабильный sealed UI state и применяет stateIn(viewModelScope, WhileSubscribed(5_000), initialState), чтобы пережить короткий разрыв подписчиков.
MutableStateFlow остается private, а изменения используют atomic update, чтобы параллельные действия не перезаписывали друг друга.
Навигация и временные эффекты не входят в долговечное состояние, если их повтор после поворота не является намеренной частью контракта.

Зачем это спрашивают: Интервьюер оценивает владение состоянием, политику sharing и отделение долговечного состояния от эффектов.

configflow

Я не стану моделировать одноразовую команду навигации как общий поток событий с повторной доставкой.

Стабильное состояние входа хранится в StateFlow, а команду навигации текущий владелец UI выводит из перехода состояния или получает через Channel с одним потребителем.
Если SharedFlow нужен нескольким наблюдателям, replay равен нулю, а контракт допускает потерю события при отсутствии подписчиков.
Тест покрывает поворот устройства во время отправки, поскольку и повторная доставка, и потеря команды заметны пользователю.

Зачем это спрашивают: Интервьюер проверяет понимание семантики доставки вместо использования SharedFlow как универсальной шины событий.

backpressurememoryflow

Я явно задам политику потерь и использую ограниченный буфер, рассчитанный по байтам и допустимой задержке.

Малоценные счетчики используют DROP_OLDEST с агрегацией, а audit-события идут в долговечное хранилище отдельно, потому что не могут разделять lossy-контракт.
Uploader собирает до 200 событий или 100 мс и ограничивает число параллельных загрузок, чтобы downstream pressure оставался конечным.
Метрики показывают потерянные события, заполнение буфера и возраст старейшего события, позволяя проверить лимит 32 МБ под синтетическим пиком.

Зачем это спрашивают: Интервьюер оценивает, включает ли backpressure продуктовую семантику, ограниченную память и наблюдаемые потери.

flowaggregation

Я разделю граф по частоте обновлений и буду пересчитывать только агрегаты с изменившимися входами.

Стабильные доменные подграфы создают типизированные промежуточные StateFlow, поэтому тик часов не пересчитывает суммы счетов или разрешения.
Дорогой mapping выполняется до combine, применяет distinctUntilChanged к значимым неизменяемым значениям и не сравнивает изменяемые коллекции.
Бенчмарк проводит через граф 1000 обновлений и измеряет вычисления и main-thread rendering относительно бюджета 50 мс.

Зачем это спрашивают: Интервьюер проверяет способность спроектировать масштабируемый реактивный граф, а не просто соединить операторы.

concurrencycallbacksflow

Я оберну callback в callbackFlow и размещу sharing для нескольких подписчиков за одним владельцем уровня устройства.

awaitClose удаляет ровно тот же listener, trySend безопасно принимает параллельные callbacks, а неудачные отправки учитываются вместо рекурсивных повторов.
Владелец применяет shareIn с задокументированными replay и stop timeout, чтобы десять collectors не регистрировали десять native listeners.
Отключение устройства представлено типизированным состоянием или завершением потока по контракту SDK, а отмена collector освобождает только его подписку.

Зачем это спрашивают: Интервьюер оценивает адаптацию callback, владение ресурсом и sharing при конкуренции.

pricingroom

Я вынесу в общий код детерминированные правила и сценарии оформления заказа, а хранилища, UI и окончательный расчет цены оставлю их владельцам.

commonMain содержит денежные типы, валидацию, переходы корзины, интерфейсы репозиториев и модели сериализации, которые оба клиента должны трактовать одинаково.
androidMain и iosMain реализуют постоянное и защищенное хранение через Room и Core Data, не протаскивая их API в общий код.
Серверный расчет остается удаленным контрактом; его дублирование в commonMain создаст два источника истины и небезопасные суммы для автономного режима.

Зачем это спрашивают: Интервьюер проверяет, следуют ли границы KMP из владения доменом, а не из максимального процента общего кода.

designjvm

Я использую default hierarchy template и добавляю промежуточные source sets только для кода с реальной общей платформенной возможностью.

commonMain хранит переносимый домен, iosMain владеет Apple-реализациями для обеих iOS-целей, а явный jvmAndAndroidMain оправдан только при настоящем совпадении зависимостей Android и сервера.
Target-specific source sets остаются тонкими для Keychain, Android Context и подобных API, без кастомной иерархии ради случайного совпадения одного файла.
CI компилирует каждую цель и публикует библиотеку из одной канонической сборки, чтобы неиспользуемый simulator source set не деградировал незаметно.

Зачем это спрашивают: Интервьюер оценивает дизайн source sets, сдержанность и полное покрытие multi-target сборки.

authjvm

Я определю одну узкую common capability и применю expect только к платформенной фабрике, которая ее предоставляет.

commonMain объявляет SecureTokenStore с readToken, writeToken и clear плюс доменные ошибки, без типов Keychain, Keystore или файловой системы.
Каждая actual-фабрика возвращает небольшую платформенную реализацию, проверяемую одной common contract suite.
Общая политика expiry и refresh токена остается обычным common-кодом, сохраняя лимит пяти деклараций для настоящих платформенных разрывов.

Зачем это спрашивают: Интервьюер проверяет, соединяют ли expect и actual возможности без распространения платформенных деталей по общему коду.

kotlin

Я опубликую небольшой Swift-facing facade вместо экспорта внутреннего графа Kotlin-модулей.

Методы facade используют стабильные имена, простые классы, nullable-значения и предсказуемые коллекции, а Kotlin-only sealed-иерархии остаются за адаптерами.
Suspend и Flow API оборачиваются в согласованную со Swift-командой модель async и observation, включая семантику отмены и доставки на main thread.
iOS sample target компилирует характерные Swift-вызовы в CI, делая изменения generated headers и несовместимые имена видимыми за двухнедельное ревью.

Зачем это спрашивают: Интервьюер оценивает удобство Swift, стабильность interop и минимизацию границы.

Я предоставлю явный subscription handle, отмена которого управляет базовой подпиской на общий Flow.

Kotlin владеет collection в дочернем scope этого handle, а Swift получает значения на задокументированной очереди без неявного global scope.
Адаптер применяет ограниченную conflated-политику, если Swift нужно только последнее состояние; lossless-записи используют отдельный durable или batch API.
Interop-тесты отменяют подписку из Swift, проверяют остановку collection за 200 мс и освобождение захваченных callbacks.

Зачем это спрашивают: Интервьюер проверяет жизненный цикл, backpressure и отмену на границе Kotlin и Swift.

concurrency

Я распределю ресурсы по владению presentation и release process, а не буду принудительно переносить все assets в общий код.

Общие доменные сообщения используют стабильные error keys или типизированные outcomes, а Android и iOS владеют пользовательским текстом по своим localization и legal workflow.
Полностью одинаковые Compose Multiplatform assets могут жить в shared resources, только если обе platform-команды согласны с упаковкой и cadence обновлений.
CI проверяет parity ключей и пропущенные переводы без зависимости commonMain от Android Resources или API iOS bundle.

Зачем это спрашивают: Интервьюер оценивает владение native-ресурсами и операционную цену sharing presentation assets.

Закрытые вопросы

21
Общий analytics client принимает события из background threads Android и iOS со скоростью 5000 событий в минуту. Как вы спроектируете его KMP concurrency model?
concurrencydesign
22
KMP-продукт на 25 модулей использует Hilt на Android и native Swift composition root на iOS. Как вы организуете dependency injection в общем коде?
injectiondependenciesoop
23
Compose Multiplatform-приложение делит 70 процентов UI между Android и desktop, но навигация и file pickers различаются. Где вы проведете границы UI и состояния?
kmp
24
Android и iOS должны использовать общий экран оформления заказа на Compose Multiplatform, но каждой платформе нужны нативная форма оплаты и отдельная проверка доступности. Как вы построите этот экран?
a11ykmp
25
Android-приложение выросло до 64 Gradle-модулей, и изменение одной feature сейчас перекомпилирует 38 модулей. Как вы перестроите границы?
build
26
Пять продуктовых команд используют общий payments-модуль, его реализация меняется еженедельно, а контракт должен быть стабилен шесть месяцев. Как вы примените границы Gradle api и implementation?
buildapi
27
В репозитории 52 модуля и шесть команд, а Android-конфигурация скопирована в каждый build file. Какую архитектуру convention plugins вы внедрите?
config
28
70-модульная Gradle-сборка должна поддерживать configuration cache и конфигурироваться на CI менее чем за 3 секунды. Как вы спроектируете и обеспечите это ограничение?
configbuilddesign
29
В 48-модульной сборке от core-utils зависят 41 модуль, а сам он меняется дважды в неделю. Какое изменение build graph вы предложите?
30
KSP-процессор генерирует adapters в 30 модулях и добавляет 90 секунд к clean build. Как вы перестроите его для incremental processing?
kotlin-symbol-processingconcurrency
31
Сгенерированный networking API используют 12 команд, и он должен сохранять source compatibility один год. Какую KSP-архитектуру вы одобрите?
apikotlin-symbol-processing
32
Вы проектируете Kotlin configuration DSL для 20 модулей с nested receivers и требованием binary compatibility на два года. Какую форму выберете?
designconfigkotlin
33
У order-системы 14 состояний, но разрешены только шесть переходов, а три состояния несут разные данные. Как вы смоделируете это в Kotlin?
system-designkotlin
34
Шесть сервисов сейчас передают customer, order и invoice ID как String, а ревью нашло 23 места возможной путаницы. Введете ли вы value classes?
classes
35
Data class для кредитного лимита должен всегда быть неотрицательным, но 17 модулей меняют его через copy. Как вы защитите инвариант без одномоментной миграции?
classes
36
Payload Kotlinx Serialization хранится offline 180 дней и читается версиями приложения с разницей до трех релизов. Как вы будете развивать схему?
schemaserializationkotlin
37
Kotlin-библиотеку вызывает Java-код объемом 2 миллиона строк, и null-контракты нужно обеспечить без миграции callers в этом году. Как вы спроектируете API?
fundamentalskotlinapi
38
Команда из восьми Spring-инженеров должна за четыре месяца создать Kotlin-сервис на 12 000 RPS с существующими Spring Security и transaction libraries. Вы выберете Ktor или Spring Boot?
transactionskotlinktor
39
Kotlin-сервис должен обрабатывать 6000 одновременных запросов, вызывать три downstream-сервиса и держать p99 ниже 400 мс при 1 ГБ RAM. Как вы спроектируете concurrency?
concurrencykotlindesign
40
Mobile aggregation service вызывает четырех партнеров с availability 99,5 процента каждый, но должен давать 99,9 процента и SLA 500 мс. Какую resilience architecture вы выберете?
fan-outaggregation
41
Spring Kotlin-сервис выполняет 300 транзакций в секунду, и каждому запросу нужны два запроса к базе и один remote call. Где вы проведете границы корутин и транзакций?
transactionsquerieskotlin
42
Order-сервис должен с бизнес-точки зрения ровно один раз сохранить заказ и опубликовать событие при 1500 записях в секунду. Какой persistence design вы примените?
design
43
У KMP domain library 20 реализаций на Android, iOS и JVM, а релизы выходят еженедельно. Какую testing architecture вы создадите?
testingjvm
44
Coroutine workflow включает debounce 30 секунд, три retry и refresh раз в пять минут, но весь test suite должен завершаться быстрее 10 секунд. Как вы его протестируете?
debouncetestingcoroutines
45
Android-приложение с 8 миллионами пользователей должно сократить cold startup с 1,8 секунды до менее 1,2 секунды на заданном mid-range устройстве. Как вы примените Baseline Profiles?
46
90-модульное Android-приложение должно уменьшить download на 18 МБ, сохранив reflection-based serialization и JNI entry points. Как вы спроектируете стратегию R8?
designserializationcode-shrinking
47
Compose-приложение инициализирует 22 SDK до первого frame и имеет cold-start budget 900 мс. Какую startup architecture вы предложите?
architecture
48
Android-приложение на 500 000 строк Java должно достичь 60 процентов Kotlin за 12 месяцев, продолжая релизы каждые две недели. Как вы спроектируете миграцию?
migrationsdatabase-migrationsdesign
49
Android-only продукт хочет за девять месяцев разделить с iOS 50 процентов business logic, не задержав шесть запланированных релизов. Как вы разделите KMP-миграцию на этапы?
migrationsdatabase-migrations
50
На ревью 45-модульной Kotlin-платформы два middle-инженера предлагают global CoroutineScope и одну shared events bus для упрощения API перед шестимесячным rollout. Как вы проведете техническое наставничество?
kotlincoroutinesdesign
51
За два часа до Android-релиза длительный тест показывает 18 000 активных Jobs после 300 открытий и закрытий одного экрана, а память выросла на 420 МБ. Что вы сделаете?
memoryperformance-testing
52
Ktor-сервис растёт с 600 до 9 000 живых корутин за 40-минутный нагрузочный тест даже после падения трафика до нуля, а запуск назначен на завтра. Как вы поступите?
coroutinesload-testingktor
53
После пятничного деплоя доля Android ANR выросла с 0,2% до 2,6% на слабых устройствах, а трассы показывают занятые хешированием изображений потоки DefaultDispatcher. Маркетинговая кампания начнётся через три часа. Что вы сделаете?
deployment
54
p99 Ktor-эндпоинта вырос со 180 мс до 4,8 с при 1 200 запросах в секунду после рефакторинга корутин, хотя CPU загружен лишь на 35%. До пикового трафика 90 минут. Что вы проверите и измените?
refactoringendpointscoroutines
55
Поисковые запросы продолжаются 12 секунд после ввода нового текста, создавая 4,2 миллиона лишних вызовов в день, а через шесть часов сработает лимит поставщика. Как вы исправите распространение отмены?
procurementqueriesresilience
56
При остановке Ktor 7% запросов работают дольше 30-секундного периода, потому что helper ловит Exception и повторяет вызов. Обновление кластера начнётся сегодня ночью. Что вы сделаете?
ktorerror-handling
57
Зависимость отвечает 503 в течение 90 секунд, а 24 инстанса Kotlin-сервиса превращают 8 000 запросов в секунду в 110 000 повторов в секунду. Владелец зависимости просит снизить нагрузку за десять минут. Каков ваш план?
dependencieskotlin
58
Flow отслеживания транспорта получает 6 000 GPS-точек в секунду, но map matching обрабатывает 600, и память процесса растёт на 780 МБ за 12 минут до OOM. Полевой тест начнётся через два часа. Как вы ответите?
concurrencyflowmemory
59
После поворота Android-устройства во время оплаты 3,8% пользователей не видят результат, потому что событие SharedFlow отправляется без активного collector. Релиз назначен на сегодня. Что вы измените?
flow
60
Экран цен остаётся устаревшим в 11% сессий после обновления, потому что StateFlow не отправляет значение при изменении mutable data class на месте. Кампания начнётся завтра. Как вы найдёте и исправите проблему?
flowclassessessions
61
Compose-лента перекомпоновывает все 500 строк при каждом тике таймера в 1 Гц, повышая CPU с 18% до 62% и расходуя 9% батареи в час. До запуска один день. Что вы сделаете?
coroutines
62
Production сообщает о 1 700 падениях в день с Compose snapshot exception после обновления mutableStateListOf фоновым sync на Dispatchers.IO. Hotfix ожидают за четыре часа. Как вы поступите?
error-handlingcoroutine-dispatcherssnapshot
63
Холодный старт Android ухудшился с 780 мс до 1,9 с после рефакторинга пакетов, хотя файл Baseline Profile всё ещё существует, а до релиза 48 часов. Что вы проверите?
refactoring
64
Debug-сборка проходит, но при 10% rollout release-сборки возникает 6,4% падений на старте после включения full-mode R8 для модуля Kotlin serialization. До автоматического расширения rollout 30 минут. Что вы сделаете?
serializationkotlincode-shrinking
65
Heap Kotlin-сервиса на Spring Boot растёт с 3 до 11 ГБ, а паузы GC достигают 1,4 секунды после удвоения трафика до 6 000 запросов в секунду. Следующий пик через 45 минут. Что вы сделаете?
data-structureskotlin
66
Batch-сервис нарушает двухчасовой SLA после увеличения thread pool с 32 до 256: throughput падает на 40%, а переключения контекста утраиваются. Какое решение вы примете перед сегодняшним ночным запуском?
batchthroughputconcurrency
67
Ktor-сервис исчерпывает Hikari pool из 50 соединений при 900 запросах в секунду, p99 достигает 8 секунд, а CPU базы остаётся на 25%. Через три часа разбор SLA. Как вы расследуете проблему?
databasektor
68
Эндпоинт Spring WebFlux на Kotlin Coroutines падает с 4 000 до 700 запросов в секунду после добавления legacy JDBC-запроса, а релиз назначен на завтра утром. Что вы сделаете?
kotlincoroutinesendpoints
69
Ревью нужно закончить за 40 минут: в PR suspend-вызов fraud API помещен внутрь транзакции базы, которая удерживает 30 блокировок строк, а на стенде ожидание блокировки уже достигает 12 секунд. Вы одобрите его?
databasetransactionsapi
70
Android sync-job использует Room withTransaction вокруг suspend-загрузки, и 8% пользователей получают database locked при 20-секундном замедлении сети. Hotfix нужен сегодня ночью. Что вы измените?
databaseroomcoroutines
71
После миграции вызова Java SDK на Kotlin platform-type NPE затрагивает 0,7% из 14 миллионов дневных запросов, потому что якобы nonnull getter иногда возвращает null. Патч нужен за два часа. Что вы сделаете?
fundamentalskotlin
72
Backend в полдень добавляет новый subtype sealed-события, и старые Android-клиенты падают при десериализации 3% сообщений; обновление приложения не дойдёт до пользователей несколько дней. Как вы ответите?
sealed-classes
73
Обновление Kotlin serialization меняет polymorphic discriminator с type на kind, из-за чего после rollout не читаются 18% сохранённых offline-записей. До обновления следующего региона четыре часа. Каков ваш план миграции?
migrationsdatabase-migrationsserialization
74
KMP-приложение на iOS падает 2 300 раз в день после того, как shared-обёртка изображения закрывает native buffer, пока Swift ещё рисует его. Hotfix нужен за шесть часов. Как вы организуете ownership?
soft-skillsownership
75
KMP-callback обновляет SwiftUI из фоновой корутины и вызывает 900 main-thread checker failures в день после удвоения трафика. Отправка в App Store завтра. Что вы измените?
concurrencycallbackscoroutines
76
Android компилируется после добавления timeout в shared expect API, но iOS actual молча сохраняет прежние 30 секунд и нарушает SLA в 5 секунд. Release-ветки создадут через два дня. Что вы сделаете?
resilienceapi
77
Релиз общего SDK превращает удобный для Swift completion API в сгенерированное имя с вложенными KotlinResult и ломает 11 мест вызова iOS в день подготовки релиз-кандидата. Каково ваше решение?
kotlin
78
Сборка Kotlin-проекта из 180 модулей выросла с 12 до 28 минут после слияния трёх feature-команд в понедельник, а release-ветка должна быть готова к среде. Как безопасно сократить время?
kotlin
79
Gradle configuration cache сокращает конфигурацию с 95 до 18 секунд, но 37 из 220 задач CI публикуют устаревшие адреса, потому что задача convention plugin читает DEPLOY_REGION в своем действии и не объявляет его входом. У вас один спринт на исправление сборок. Что вы сделаете?
deploymentconfigbuild
80
Чтобы избежать цикла проектов Gradle при разделении платежей, команда переносит платежные события в shared-core, от которого зависят domain, analytics и UI; теперь изменение одного события добавляет 70 секунд к инкрементальной сборке за три дня до релиза. Как вы решите ревью?
build
81
После обновления KSP processor incremental CI вырос с 6 до 19 минут, а generated sources появляются для неизменённых модулей. Завтра уходит patch train. Что вы проверите?
kotlin-symbol-processingconcurrency
82
Сгенерированный KSP mapper компилируется в producer-модуле, но consumers получают NoSuchMethodError после добавления лишь default parameter; сегодня ночью деплоятся 14 сервисов. Что вы сделаете?
deploymentkotlin-symbol-processing
83
Minor-релиз Kotlin SDK удаляет overload, сгенерированные @JvmOverloads, и ломает 26 Java consumers за два часа до публикации. Каково ваше решение?
kotlin
84
Команда должна мигрировать 420 000 строк Java на Kotlin, продолжая выпускать две доходные фичи в месяц, а первая массовая конвертация повысила дефекты на 35%. Как вы перезапустите миграцию?
migrationsdatabase-migrationsdefects
85
Android-команда должна за 12 недель поделиться checkout с iOS через KMP, пока оба приложения выходят еженедельно, а первый spike shared UI задержал Android на девять дней. Что вы измените?
86
Room migration с версии 17 на 18 переименовывает колонку, но 0,4% обновившихся пользователей теряют сохранённые черновики из-за включённого destructive fallback. Hotfix должен выйти сегодня. Что вы сделаете?
migrationsschemaroom
87
За 30-минутный outage 60 000 устройств offline редактируют одинаковый класс записей; после reconnect last-write-wins создаёт 7 500 тихих перезаписей. Support нужен mitigation за день. Каков ваш план?
88
Coroutine-тест падает примерно в 1 из 80 CI-запусков, потому что использует delay(500) и реальный Dispatchers.IO, а уверенность в релизе нужна к полудню. Как сделать его детерминированным?
coroutinescoroutine-dispatchers
89
Набор тестов проходит отдельно, но падает в 6% параллельных запусков, потому что один тест заменяет Dispatchers.Main и не восстанавливает его после отмены. CI должен остаться параллельным ради бюджета в 15 минут. Что вы измените?
resiliencecoroutine-dispatchers
90
Fan-out запрос запускает 40 корутин, но трассы показывают только parent span, поэтому регрессию p99 до 2,5 секунды нельзя локализовать перед завтрашним разбором инцидента. Какую наблюдаемость вы добавите?
coroutinesobservabilityincidents
91
После переноса работы в withContext 22% error logs теряют request_id и не соединяются с трассами во время живого инцидента. Полезные логи нужны за 30 минут. Что вы сделаете?
incidents
92
За 30 минут до code freeze вы проверяете fix с GlobalScope.launch для подтверждения заказа, чтобы HTTP-ответ был быстрее на 200 мс. Операция затрагивает 80 000 заказов в день. Вы одобрите его?
httpcoroutines
93
PR нужно выпустить сегодня, и он добавляет unlimited Channel для поглощения всплесков webhook; burst из 300 000 событий на staging увеличивает heap на 2,2 ГБ, но ничего не теряет. Каково ваше решение на ревью?
data-structuresconcurrencywebhooks
94
Первая coroutine-фича middle-инженера оставляет 6 000 Job за ночь из-за вручную созданного scope экрана; клиентское демо через два дня. Как вы совместите менторство и исправление инцидента?
mentoringincidentscoroutines
95
Junior-инженер пытается исправить рост памяти Flow увеличением buffer с 1 000 до 100 000, а дедлайн релиза завтра. Как вы направите решение?
incidentsestimationmemory
96
Таймаут платежа отменяет parent-корутину, но detached retry завершается позже и дважды списывает деньги у 41 клиента до срабатывания alert. Finance требует containment за 20 минут. Что вы сделаете?
resiliencealertingcoroutines
97
Actor на Channel для команд inventory накопил backlog в 1,8 миллиона, а возраст старейшего сообщения достиг 27 минут за два часа до flash sale. Каково ваше решение?
concurrencybacklog
98
Экран Compose Multiplatform на iOS падает с 60 до 24 FPS при наборе из 10 000 строк, хотя Android держит 55 FPS, а beta начнётся через пять дней. Как вы расследуете проблему?
kmp
99
Обновление с Kotlin 1.9 на 2.x и K2 сокращает компиляцию на 22%, но два compiler plugin генерируют другие nullability metadata, и 160 тестов падают; окно обновления закроется в пятницу. Что вы решите?
kotlin
100
Пятничное ревью предлагает за неделю вынести Android-only реализацию криптографии в KMP, но iOS actual использует другой формат ключей и не проходит 4% migration fixtures. Партнёрский запуск в следующий понедельник. Что вы сделаете?
migrationsdatabase-migrationsfixtures

Вопросы

2Ktor-сервис обрабатывает 8000 запросов в секунду с p99 SLA 200 мс и обновляет кеш каждую минуту. Как вы разделите request scope и application scope?

4Kotlin/JVM-сервис цен получает 2000 вычислений в секунду, каждое занимает 12 мс CPU, на контейнере с 8 ядрами и целевым p99 250 мс. Как вы спроектируете параллелизм корутин?

5Поисковый запрос обращается к шести провайдерам и должен ответить за 300 мс, даже если один необязательный провайдер не отвечает. Как вы структурируете корутины?

7У мобильного checkout есть end-to-end SLA 2 секунды на вызовы inventory, fraud и payment. Как вы передадите временные бюджеты через слои корутин?

8Сорок feature-модулей сейчас отдают собственные фабрики CoroutineScope, а архитектурное ревью требует единую модель владения за два релиза. Какой дизайн вы одобрите?

9Репозиторий обслуживает 15 экранов, и каждому collector нужен новый запрос с фильтром по собственному account ID. Должен ли публичный API возвращать Flow, StateFlow или SharedFlow?

10У Compose-экрана 11 независимых источников данных, и после поворота он должен сразу восстановить последнее отображаемое состояние. Как вы предоставите StateFlow?

12Telemetry Flow получает 20 000 событий в секунду, uploader обрабатывает 5000, а память ограничена 32 МБ. Какой контракт backpressure вы зададите?

13Dashboard объединяет 25 StateFlow, и любое обновление должно отобразиться за 50 мс без пересчета всех дорогих агрегатов. Как вы построите граф Flow?

14Bluetooth SDK отправляет callbacks из четырех потоков и разрешает только один активный listener на устройство. Как вы предоставите его как Flow десяти модулям приложения?

16KMP-библиотека на 30 модулей нацелена на Android, iOS arm64, iOS simulator arm64 и JVM-сервер. Как вы спроектируете иерархию source sets?

17Общему модулю аутентификации нужно secure storage на Android, iOS и JVM, а политика ревью разрешает не более пяти expect-деклараций. Как вы примените expect и actual?

18KMP-фреймворк экспортирует Swift-команде 80 деклараций, а call sites должны читаться без знания Kotlin и пройти API-ревью за две недели. Как вы оформите границу?

19Общий SDK передает в Swift 100 обновлений в секунду и должен остановиться за 200 мс после исчезновения view. Какой interop-контракт вы выберете?

20KMP-приложение поставляет 600 локализованных строк, изображения и юридический текст, который iOS должна обновлять своим native release process. Кто должен владеть ресурсами?

Закрытые вопросы