System design для Android: как проходит секция и что оценивают

Почему именно эта секция отсеивает сильных

В пуле у меня 15 задач на system design. Четырнадцать рассчитаны на senior, тринадцать - на middle+, и только две можно смело давать крепкому middle. На тех-скрининге всё ровно наоборот: там потолок упирается в middle.

Отсюда простая арифметика. Человек уверенно проходит скрининг, бодро пишет код, а потом приходит на system design и впервые за весь процесс получает вопрос без единственного правильного ответа. Грейд теряют именно здесь - и не потому, что не знают Android, а потому что никогда не проектировали вслух под чужим взглядом. На работе как-то обходилось и без этого.

Чем мобильный system design отличается от бэкендового

Про шардирование базы и репликацию между дата-центрами тебя не спросят, можно выдохнуть. Спросят, что будет с твоим экраном в метро, в роуминге, при переключении с Wi-Fi на LTE и когда система убьёт процесс ровно между отправкой и подтверждением.

Мобильный клиент живёт в мире, где сеть отваливается по умолчанию, процесс прибивают в любой момент, а пользователь держит то же приложение на втором устройстве. Хороший ответ здесь - не красивая схема слоёв, а список того, что сломается, и решение для каждого пункта.

Какие задачи дают

Пять жанров, которые кочуют из компании в компанию:

• ➖Offline-first и синхронизация. Перевод денег без сети, общий список покупок на всю семью, календарь с повторяющимися событиями. Главное - слить изменения и ничего не потерять.
• ➖Realtime. Котировки с биржи, трекинг курьера на карте, чат с доставкой сообщений. Десятки обновлений в секунду и канал, который моргает.
• ➖Медиа. Отправка фото с прогрессом и дожатием при обрыве, голосовые сообщения с фоновым воспроизведением и управлением с экрана блокировки.
• ➖Системные задачи. Нотификации с группировкой, ответом из шторки и поведением при убитом процессе. Или расследование: старт приложения за полгода вырос с 1,5 до 3,5 секунды - что делать.
• ➖Лидовые. Спроектируй продукт, оцени команду, декомпозируй и защити сроки. Тут проверяют уже не Android, а инженерное руководство.

Правило, на котором спотыкается половина

Транспорт и протокол в условии не называются. «Цены обновляются в реальном времени» - это не «возьми WebSocket». Выводить решение должен ты сам: из частоты обновлений, допустимой задержки, поведения при обрыве и того, что происходит, когда биржа закрыта.

Задачи я специально формулирую так, чтобы соблазн назвать технологию в первую же минуту был максимальным. Кандидат, который начинает с «поднимем сокет», в девяти случаях из десяти дальше не может объяснить, что делать с переподключением и дублями. А кандидат, который начал с требований, приходит к тому же сокету - только уже с обоснованием. Решение одинаковое, оценка - нет.

Что оценивают

• ➖Требования раньше решения. Сколько данных, какая задержка допустима, что считается успехом и что делаем при отказе.
• ➖Деградация. Обрыв связи, смена сети, убитый процесс, роуминг. На каждом шаге - что в этот момент видит пользователь.
• ➖Идемпотентность и дедуп. Ретрай с новым идентификатором превращает один перевод в два. Пользователь, скорее всего, заметит.
• ➖Где живёт очередь. Отправка в viewModelScope умирает вместе с экраном. Всё, что обязано доехать, живёт в WorkManager или в собственной очереди с персистентным хранилищем.
• ➖Разрешение конфликтов как отдельный механизм. Не размазанное тонким слоем по ViewModel и репозиторию, а выделенное и тестируемое.
• ➖Путь данных по слоям. Сокет живёт в data-слое, наружу отдаётся поток, а не suspend-функция - иначе реактивность заканчивается на первом же слое.
• ➖Деньги. Никакого Float для цен и сумм. В финтехе это отдельный маркер, и очень заметный.

На чём сыпятся

На этот этап у меня накопилось 44 отметки о типичных провалах - больше, чем на все остальные секции вместе взятые. Самые частые:

• ➖«Пуши сами доставят сообщения». Пуш - это сигнал, а не транспорт. При убитом процессе notification payload вообще минует код приложения, и за данными всё равно придётся сходить самому.
• ➖Загрузка в viewModelScope. Пользователь свернул приложение, экран уничтожен, загрузка файла тихо умерла вместе с ним. А ведь обещали, что доедет.
• ➖Каждая котировка перерисовывает весь список. Пятьдесят бумаг, десятки обновлений в секунду по каждой. Проблему обычно не видят до прямого вопроса «а что в это время с UI-потоком?».
• ➖PUT всего списка, побеждает последний. Классика совместного редактирования. Один вычеркнул пункт офлайн, другой в это же время его переименовал - одна из правок исчезает без следа.
• ➖Realtime «просто через сокет». Без переподключения, backpressure и деградации до polling. На вопрос «а если сеть моргнула в лифте?» ответа обычно нет.

Лидовые задачи: сроки и команда

Если идёшь на senior или lead, половина секции будет вообще не про Android. Дадут продукт, срок в три месяца и попросят декомпозировать, назвать размер команды и защитить оценку.

Три надёжных способа это провалить: назвать сроки на глаз, без декомпозиции и буфера; сказать «добавим людей - успеем», не посчитав цену онбординга; закопаться в выбор технологий, так и не спросив, что именно показываем через три месяца и что можно вынести за рамки MVP. Какой DI-фреймворк ты возьмёшь, на этом этапе не волнует никого, честно.

Как готовиться

• ➖Возьми свой продукт и прогони его сценарии через отказы. Что будет на каждом шаге, если сеть пропала посередине, процесс убили, пользователь зашёл со второго устройства. Одно такое упражнение даёт больше, чем десяток статей.
• ➖Натренируй первые пять минут. Уточняющие вопросы к условию оцениваются раньше всего - и пропускаются чаще всего.
• ➖Нарисуй путь данных руками. От источника до пикселя, со слоями и типами. На секции попросят именно нарисовать, а не рассказать.
• ➖Разбери один жанр до конца. Лучше уверенно владеть offline-first, чем по верхам знать все пять.