Расскажите про архитектурный спор по асинхронности и последовательности выполнения

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

Два слоя сразу. Технический: понимаете ли вы модель конкурентности в iOS и разницу между асинхронностью и параллельностью. Поведенческий: как вы спорите, на чём строите аргумент и что делаете, когда решили не по-вашему. Вопрос про спор задают именно ради второго слоя, техника тут проверяется попутно.

Как отвечать

Сформулируйте предмет спора точно. Типичные сюжеты: переходить ли с колбэков на async/await, нужен ли строгий порядок операций или их можно пускать параллельно, где именно делать переход на главный поток, стоит ли тянуть реактивную библиотеку ради цепочек вызовов.

Аргументируйте по существу задачи. Последовательность обязательна там, где операции меняют общее состояние или порядок важен по смыслу: отправка сообщений, запись в локальное хранилище, применение обновлений с сервера. Параллельность выигрывает на независимых загрузках. В Swift для защиты состояния есть actor и @MainActor, для параллельного запуска async let и группы задач, для строгого порядка последовательная очередь или тот же актор.

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

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

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

Путают асинхронность с параллельностью. async/await сам по себе не делает работу параллельной, он убирает блокирующее ожидание и вложенность колбэков. Параллельность появляется только тогда, когда задачи запущены независимо друг от друга.

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