Может ли прийти пустой список детей в функцию распределения ширин

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

Уточняете ли вы граничные случаи до того, как писать код. Правильная реакция на такой вопрос: «да, может, и вот что функция вернёт». Следом обычно спрашивают про остаток от деления и нулевую сумму весов.

Как отвечать

Сначала зафиксируйте контракт. В реальной вёрстке пустой список детей нормален: контейнер отрисован до загрузки данных, все дети скрыты через GONE, в Compose Layout получил пустой measurables. Значит, это не ошибка входа, а штатный случай.

Каркас решения:

• ранний выход: для пустого списка вернуть emptyList() до любых вычислений. Иначе totalWidth / children.size на Int бросит ArithmeticException, а на Float даст Infinity;
• остаток: 100 пикселей на троих это 33, 33 и 33, один пиксель теряется. Раздайте остаток totalWidth % n первым детям по одному, чтобы сумма совпала с шириной контейнера;
• веса: при распределении по весам проверьте, что сумма больше нуля. Деление на нулевую сумму в Float даёт NaN, а NaN.roundToInt() бросает IllegalArgumentException;
• ограничения: в Compose ширина может быть неограниченной внутри горизонтального скролла. Проверяйте constraints.hasBoundedWidth, а не делите Constraints.Infinity.

Контракт стоит закрепить в коде: require(totalWidth >= 0) для недопустимого входа и отдельная ветка для пустого списка, который допустим. В Compose при пустом measurables всё равно нужно вызвать layout(width, height), обычно с constraints.minWidth.

Тесты назовите сами: пустой список, один ребёнок, ширина делится нацело и не делится, нулевые веса, ширина меньше числа детей.

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

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

Теряют остаток от деления. Сумма ширин не равна ширине контейнера, и справа появляется щель в пиксель, которую потом долго ищут.

Бросают исключение на пустом списке. Для функции вёрстки это неверный контракт: экран с пустым контейнером упадёт при первом же запуске без данных.