Собес в мобильной разработке: суть проведения, этапы и подготовка

Что такое собес в IT?

Техническое собеседование (собес) — структурированный процесс оценки профессиональных компетенций разработчика, включающий проверку hard skills (технические знания) и soft skills (коммуникация, работа в команде). Стандартный цикл собеседования мобильного разработчика занимает 3-5 раундов общей длительностью 4-6 часов. Процент успешного прохождения от числа первичных откликов составляет 2-5% в крупных технологических компаниях.

Процесс найма в мобильной разработке отличается от веб-разработки: добавляются вопросы по платформенной специфике — жизненный цикл Activity/Fragment, ARC и управление памятью в Swift, threading модели (Main Thread, Dispatch Queue, Coroutines), работа с сетевыми запросами и кэшированием данных. Android-разработчик должен знать Jetpack Compose, Room, WorkManager, Dagger/Hilt. iOS-разработчик — SwiftUI, Core Data, Combine, URLSession. Разница в требованиях растёт с опытом: для Senior-позиций добавляется системный дизайн и архитектура всего приложения.

Структура собеседования зависит от грейда. Для Junior-позиций достаточно базового знания языка и платформы (1-2 раунда). Middle-разработчик проходит 2-3 раунда с блоком алгоритмов. Senior-собес включает 4-5 раундов: алгоритмы, архитектура мобильного приложения, системный дизайн, поведенческое интервью и финальное собеседование с VPE (Vice President of Engineering) или CTO.

Этапы технического собеседования

HR-скрининг — первый этап длительностью 20-30 минут. Рекрутер проверяет соответствие опыта требованиям вакансии, обсуждает условия работы, зарплатные ожидания и мотивацию кандидата. На этом этапе важно чётко сформулировать свой опыт: проекты, стек технологий, достижения в метриках (снижение времени загрузки, уменьшение crash rate, ускорение сборки). HR-скрининг не проверяет технические знания, но отсеивает до 40% кандидатов по несоответствию формальным требованиям.

После скрининга следует алгоритмическое интервью — ключевой этап для большинства компаний. Длительность — 45-90 минут. Кандидату дают 1-2 задачи на алгоритмы и структуры данных. Решение пишется на онлайн-доске (Codility, HackerRank, CoderPad) или на бумаге. Оценивается не только правильность, но и скорость мышления, умение задавать уточняющие вопросы и оптимизировать решение. По данным interviewing.io (2025), 73% кандидатов проваливаются именно на алгоритмическом этапе.

Архитектурное интервью

Архитектурный раунд проверяет умение проектировать мобильные приложения. Кандидату предлагают спроектировать приложение (TODO-лист, мессенджер, новостной агрегатор, стриминговый сервис). Оценивается выбор архитектурного паттерна (MVP, MVVM, MVI, VIPER), организация слоёв (Presentation, Domain, Data), работа с DI (Dagger, Hilt, Swinject) и навигация. Для Android — знание Jetpack Navigation, для iOS — Coordinator паттерн и SwiftUI NavigationStack.

На поведенческом интервью оценивают soft skills: умение работать в команде, решать конфликты, аргументировать решения. Используется метод STAR (Situation, Task, Action, Result) — кандидат описывает конкретную ситуацию из опыта. Пример вопроса: «Расскажите о самом сложном баге, который вы нашли и исправили». Финальный раунд с тимлидом или VPE проверяет стратегическое мышление и культурное соответствие компании.

Алгоритмы и структуры данных на собеседовании

Алгоритмические задачи — обязательный компонент собеседований в крупные технологические компании (Google, Meta, Яндекс, Tinkoff, Avito). Основная цель — оценить ability to solve (способность решать задачи), а не знание языка. Кандидату разрешается использовать любой язык программирования — предпочтение отдаётся Kotlin для Android и Swift для iOS. Типичные темы: массивы, хеш-таблицы, графы, динамическое программирование, деревья (Binary Tree, Trie, Segment Tree).

По данным LeetCode (2025), для уверенного прохождения алгоритмического собеседования необходимо решить 250-400 задач. Ключевые темы по частоте появления: Two Pointers (12%), Sliding Window (10%), DFS/BFS на графах (14%), Binary Search (8%), Dynamic Programming (18%), Hash Map / Set (15%). Big O нотация — обязательный элемент: кандидат должен объяснить временную и пространственную сложность своего решения и предложить оптимизацию.

Пример задачи: Two Sum

// LeetCode 1: Two Sum — classic HashMap problem
fun twoSum(nums: IntArray, target: Int): IntArray {
    // Store complement = target - nums[i] and its index
    val map = mutableMapOf<Int, Int>()

    for (i in nums.indices) {
        val complement = target - nums[i]

        // If complement found — pair found
        if (complement in map) {
            return intArrayOf(map[complement]!!, i)
        }
        map[nums[i]] = i
    }
    throw IllegalArgumentException("No two sum solution")
}

// Time: O(n), Space: O(n)

Задача Two Sum — самая популярная задача на собеседованиях (по данным LeetCode, более 20 млн отправок). Решение за O(n) использует HashMap: для каждого элемента проверяем, встречалась ли уже разность target - nums[i]. Если да — возвращаем индексы. Если нет — сохраняем текущий элемент в HashMap. Наивное решение за O(n²) с двумя вложенными циклами считается непроходным для Senior-позиций.

Вопросы по мобильной разработке

Платформенные вопросы на собеседовании мобильного разработчика делятся на три блока: фундаментальные знания платформы, работа с UI и многопоточность, сетевые запросы и хранение данных. Для Android обязательны: жизненный цикл Activity и Fragment, различия Fragment v1 vs Fragment v2, ActivityResult API (замена onActivityResult), ViewModel + StateFlow, Compose lifecycle. Для iOS: жизненный цикл UIViewController, ARC (Automatic Reference Counting), DispatchQueue и OperationQueue, SwiftUI lifecycle (View — @State — @Binding — @ObservedObject).

Пример вопроса: жизненный цикл

Типичный вопрос: «Какие колбэки жизненного цикла Activity вызываются при повороте экрана?». Правильный ответ: onPause → onStop → onDestroy → onCreate → onStart → onResume. Дополнительный вопрос: «Как сохранить состояние при повороте?» — через SavedStateHandle в ViewModel, onSaveInstanceState Bundle или rememberSaveable в Jetpack Compose. Для iOS: «Что происходит с UIViewController при заходе в фон?» — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

Системный дизайн мобильного приложения

System Design Interview для мобильного разработчика проверяет умение спроектировать архитектуру клиентского приложения и его взаимодействие с сервером. Стандартные задачи: спроектировать ленту новостей (как Instagram/TikTok), чат (как Telegram), видеоплеер (как YouTube), кеш первого уровня (L1 — in-memory, L2 — диск). Длительность — 60 минут. Оценивается структурированность мышления, а не количество деталей.

Шаблон ответа на System Design: 1) Clarify requirements — уточнить функциональные (лента, лайки, комментарии, загрузка фото) и нефункциональные требования (offline, скорость загрузки, потребление батареи). 2) High-level design — нарисовать схему слоёв: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — детализировать ключевые компоненты, например, механизм пагинации (Paging 3 для Android, Offset-based vs Cursor-based для iOS). 4) Trade-offs — обсудить компромиссы: кэш vs свежесть данных, offline-first vs online-only.

Ключевые темы System Design для мобильных: кэширование (LRU Cache, Disk Cache с лимитом), работа с изображениями (Coil, Glide, SDWebImage — загрузка, кэш, placeholder, прогресс), оптимизация трафика (protobuf вместо JSON, сжатие, Differ/GraphQL), работа в офлайне (Room + Sync Adapter, Core Data + iCloud, WorkManager для фоновой синхронизации). Offline-first — одна из самых частых тем для Senior-позиций.

Для iOS добавляются вопросы по App Thinning, Slicing, On-Demand Resources и оптимизации билда. Для Android — по R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery и Minification. Архитектурный вопрос «Как реализовать кэш изображений с ограничением по памяти?» проверяет понимание LRU Cache (LinkedHashMap с access order), Disk LRU Cache (Jake Wharton's DiskLruCache) и Coil/Glide memory cache layer.

Стратегия подготовки к собеседованию

Подготовка к собеседованию требует системного подхода за 4-8 недель до планируемого интервью. Базовая стратегия: 2 недели на повторение теории (язык, платформа, алгоритмы), 2-4 недели на решение алгоритмических задач (100-300 задач на LeetCode), 1-2 недели на mock-собеседования (Pramp, interview.io, с друзьями). Для Senior-позиций добавляется подготовка System Design (2-3 недели). План даёт 70-80% успешного прохода на целевой уровень.

Для мобильных разработчиков специфичная подготовка включает: чтение Android Developers Guide / iOS Developer Library, разбор source code популярных библиотек (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), написание pet-проекта с Clean Architecture и CI/CD (GitHub Actions, Fastlane). Напишите приложение-пример на GitHub с модульной архитектурой, DI, тестами (Unit + UI + Snapshot) — это покажет глубокое понимание и станет аргументом на собеседовании.

Типичные ошибки кандидатов

Ошибка 1: молчаливое решение. Кандидат пишет код молча, не комментируя ход мыслей. Интервьюер не может оценить процесс решения. Правильно: проговаривать каждый шаг — «Я вижу, что задача сводится к поиску в графе. Предлагаю использовать BFS, потому что нужно найти кратчайший путь». Такая коммуникация даёт интервьюеру возможность направить кандидата при ошибке, что оценивается положительно.

Ошибка 2: сразу писать код. Начинать кодить без уточнения требований и обсуждения подходов — одна из главных причин провала. Перед написанием кода нужно: уточнить входные/выходные данные, обсудить corner cases, сравнить 2-3 подхода с оценкой Big O и только после оговорки с интервьюером писать оптимальное решение. Правильный паттерн: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Ошибка 3: незнание платформы. Кандидат отлично решает алгоритмы, но не может объяснить разницу между Activity и Fragment или между weak/unowned в Swift. Для мобильных вакансий платформенные знания оцениваются наравне с алгоритмами. Изучите: различия версий SDK (compileSdk vs minSdk vs targetSdk), ProGuard/R8 правила для популярных библиотек, Swift Concurrency (async/await, actors) и MainActor. Каждый третий кандидат на iOS-позицию проваливается на вопросах по ARC.