Тестовое собеседование на позицию Android Developer (III и IV этапы)
Запись тестового Android-собеседования с алгоритмическими задачами и проектированием SDK достижений для игр. В конце разобраны ошибки и удачные решения кандидата.
DevGym
Открыть на YouTube- Опубликовано на YouTube:
- Просмотры на YouTube: 1,6 тыс.
- Лайки на YouTube: 51
Таймлайн
Коротко о видео
Это тестовое собеседование Android-разработчика: сначала кандидат решает две алгоритмические задачи, затем проектирует SDK достижений для мобильных игр. В первой задаче обсуждается поиск первого неповторяющегося символа через HashMap подсчётов, во второй — представление бинарного дерева справа с помощью BFS по уровням. В System Design интервьюер и кандидат уточняют API, офлайн-работу, хранение, синхронизацию и архитектуру SDK, после чего интервьюер даёт развёрнутую обратную связь.
Затронутые темы
Что взять на заметку
- Для первого неповторяющегося символа подходит два прохода: сначала собрать частоты в HashMap, затем вернуть первый индекс, у которого частота равна 1; сложность — O(n) по времени и O(n) по памяти.
- В задаче про вид дерева справа нельзя выбирать максимальные значения: дерево не обязано быть бинарным деревом поиска. При BFS нужно обрабатывать фиксированный размер очереди для каждого уровня и добавлять в ответ последнюю обработанную ноду уровня.
- В System Design сначала следует выяснить пользователей SDK, целевые платформы, способ интеграции игр, ключевые сценарии, состав и объём данных — иначе проектирование строится на неподтверждённых допущениях.
- Для SDK достижений игра должна сообщать о факте достижения, а SDK хранит и выдаёт состояние достижений, не вычисляя игровые условия самостоятельно.
- Офлайн-события о выданных достижениях нужно сохранять до успешной отправки на backend; при logout допустимо очистить неактуальные локальные данные, но не потерять ещё не синхронизированные изменения.
- В предложенной архитектуре публичный фасад SDK обращается к репозиторию, который скрывает локальное хранилище и сеть; интервьюер рекомендует не перегружать единый CacheDataSource и разделять ответственность на более узкие интерфейсы.