Что такое масштабирование кода
Что проверяют
Вопрос про рост кодовой базы, а не про серверы. В Android боль конкретная: приложение обрастает экранами, над ним работает несколько команд, правка в одном месте пересобирает весь проект. Проверяют, отличаете ли вы масштабирование кода от масштабирования инфраструктуры и умеете ли назвать приёмы, которые держат проект управляемым на сотнях экранов.
Как отвечать
Сформулируйте критерий: код масштабируется, если добавление функции стоит примерно столько же на сотом экране, сколько на десятом, а время сборки и прогона тестов растёт не быстрее объёма изменений.
Дальше перечислите рычаги.
Модуляризация Gradle по фичам: отдельный модуль на фичу плюс общие модули ядра. Это и параллельная сборка, и физическая граница, через которую нельзя случайно дотянуться до чужого класса.
Стабильные контракты между модулями: наружу интерфейс и модель, внутрь реализация. Навигация через фасад или идентификаторы, чтобы фича не знала классов соседней фичи.
Единый каркас экрана: однонаправленный поток состояния, состояние в модели представления, эффекты отдельно. Однотипные экраны новый человек пишет по образцу, а не изобретает.
Внедрение зависимостей с построением графа на сборке, чтобы связи проверял компилятор, а не рантайм.
Инструменты дисциплины: запрет циклов и лишних зависимостей между модулями, общие настройки сборки в одном месте вместо копий в каждом модуле, тесты на публичный контракт модуля.
Где спотыкаются
Отвечают про горизонтальное и вертикальное масштабирование, добавление серверов и балансировщик. К мобильному коду это отношения не имеет, и интервьюер слышит заученный шаблон не по теме.
Дробят проект на десятки модулей без правил зависимостей. Граф превращается в паутину, типовая правка задевает половину дерева, и выигрыш в скорости сборки съедается целиком.
Не могут назвать измеримый признак проблемы. Время чистой и инкрементальной сборки, число модулей, которые задевает средняя задача, доля экранов на общем каркасе: без таких величин разговор остаётся вкусовым.