В каком случае не стоит использовать MutableList при необходимости редактирования листа

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

Понимаете ли вы, что в Android список почти всегда часть состояния, а изменение на месте ломает механизмы, которые реагируют на смену ссылки. Следом спрашивают, чем List в Kotlin отличается от по-настоящему неизменяемого списка и как обновлять состояние во ViewModel.

Как отвечать

Сама необходимость править данные не повод брать MutableList. Его не стоит использовать там, где кто-то следит за состоянием:

• StateFlow и LiveData: _items.value.add(x) не вызовет эмиссию, ссылка та же. StateFlow сравнивает значения через equals, поэтому даже присвоить тот же изменённый экземпляр бесполезно. Правильно держать List и обновлять копией: _items.update { it + x };
• Compose: обычный mutableListOf() внутри remember не вызывает рекомпозицию при add. Нужен либо mutableStateListOf(), он же SnapshotStateList, либо неизменяемый список в mutableStateOf с заменой целиком;
• ListAdapter и DiffUtil: если передать в submitList тот же изменённый экземпляр, адаптер решит, что ничего не поменялось. Нужен новый список;
• публичный API класса: наружу отдают List, а MutableList держат в приватном поле, чтобы экран не менял данные в обход ViewModel;
• несколько потоков: ArrayList не потокобезопасен. Изменение во время обхода даёт ConcurrentModificationException, одновременная запись теряет элементы. Здесь нужны неизменяемые снимки, Mutex в корутинах или CopyOnWriteArrayList для редких записей.

Уточните, что List в Kotlin только интерфейс для чтения: под ним может лежать тот же ArrayList, и приведение типа позволит его изменить. Настоящую неизменяемость даёт kotlinx.collections.immutable с persistentListOf(), а в Compose ImmutableList ещё и считается стабильным типом.

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

Мутируют список внутри StateFlow и удивляются, что экран не обновился. Это самая частая ошибка в тестовых заданиях.

Считают, что List защищает от изменений. Это защита на уровне компилятора, а не самого объекта.

Советуют Collections.synchronizedList как универсальное решение. Он защищает отдельные вызовы, но обход списка всё равно требует внешней синхронизации.