Работали ли вы с многопоточностью, потоками, синхронизацией и взаимодействием потоков

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

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

Как отвечать

Опишите слои. Для фоновой работы внутри экрана это корутины: Dispatchers.IO для ожидания ввода и вывода, Dispatchers.Default для расчётов, запуск через viewModelScope или lifecycleScope, чтобы задача отменилась вместе с владельцем. Для потока событий Flow, для работы, которая должна пережить закрытие процесса, планировщик фоновых задач. Если проект на Java, то пул потоков через ExecutorService и отдельный поток с очередью сообщений.

Про синхронизацию скажите в правильном порядке. Сначала способ обойтись без неё: неизменяемые объекты и передача данных сообщением вместо общего изменяемого поля. Если общее состояние неизбежно, тогда Mutex в корутинах, который не блокирует поток, а приостанавливает корутину, synchronized в обычном коде, @Volatile для флага, атомарные счётчики и потокобезопасные коллекции. Хорошо добавить про видимость: гонка это не только одновременная запись, но и чтение устаревшего значения, поэтому правила видимости важны не меньше взаимного исключения.

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

Приносят AsyncTask. Он объявлен устаревшим, удерживает ссылку на экран и переживает поворот, поэтому рассказ о нём как об основном подходе читается как давно не обновлявшийся опыт.

Считают @Volatile заменой атомарности. Он даёт видимость записи другим потокам, но увеличение счётчика остаётся тремя операциями, и два потока спокойно теряют одно значение.

Блокируют главный поток. Ожидание через блокирующий вызов или защёлку прямо в обработчике интерфейса приводит к зависанию и сообщению системы о неотвечающем приложении. Смена диспетчера тоже не делает код безопасным: она лишь уводит его с главного потока.