Собеседование Гончаров-Бадретдинов
Учебный разбор архитектурного Android-интервью на примере приложения такси. Участники проектируют масштабируемый клиент, обсуждая технические решения и качество ответов кандидата.
Android Broadcast. Все об Андроид разработке
Открыть на YouTube- Опубликовано на YouTube:
- Просмотры на YouTube: 9,7 тыс.
- Лайки на YouTube: 315
Таймлайн
Коротко о видео
Это учебное Android design-интервью: кандидат проектирует пассажирское приложение такси, а интервьюер последовательно уточняет ограничения и проверяет аргументацию решений. Обсуждаются структура репозиториев и ветвления, Kotlin, Coroutines/Flow, DI, архитектура UI, Compose, офлайн-режим, GraphQL, безопасность и real-time-трекинг машин. В конце интервьюер отмечает, что ответы кандидата содержательны, но часто уходят от сформулированного вопроса; для интервью полезнее сначала давать прямое решение, затем кратко раскрывать альтернативы и причины выбора.
Затронутые темы
Что взять на заметку
- Выбор между monorepo и несколькими репозиториями нужно привязывать к структуре команд, числу приложений и объёму общего кода; для тесно связанных приложений водителя и пассажира кандидат предпочёл monorepo с модулями.
- Для большой команды обсуждаются Gitflow и trunk-based-подход: короткоживущие ветки, частые интеграции и обязательные CI-проверки уменьшают расхождение веток, но требуют дисциплины релизов и feature flags.
- Стек предлагается выбирать не по моде, а по горизонту продукта, опыту команды, скорости сборок и поддерживаемости: Kotlin, Coroutines и Flow рассматриваются как базовый вариант, а Dagger и Koin — как компромисс между масштабированием и скоростью разработки.
- Для приложения с динамической картой архитектура должна давать явное состояние и тестируемый поток событий; кандидат склоняется к MVI / unidirectional data flow и разделению бизнес-логики с UI.
- Compose на момент обсуждения признаётся перспективным, но для экранов с картами и сложными списками кандидат осторожно оставляет классические View и RecyclerView, чтобы снизить риски незрелой технологии.
- Офлайн-поддержка должна быть сформулирована заранее: от простого кэша ответов до offline-first, где пользователь может создавать действия без сети и синхронизировать их позже.
- Для real-time-геолокации стоит отделять канал обновлений активной поездки, например WebSocket, от push-уведомлений, которые нужны для пробуждения приложения; каждое событие должно содержать идентификатор конкретной поездки.
- Данные банковской карты не следует хранить на устройстве даже в зашифрованном виде: безопаснее передать их платёжному провайдеру и хранить токен или иной результат токенизации.