Technical Interview in Mobile Development: Process, Stages, and Preparation

What is a Technical Interview in IT?

Technical Interview (coding interview) is a structured process of evaluating a developer’s professional competencies, including hard skills (technical knowledge) and soft skills (communication, teamwork). A standard mobile developer interview cycle consists of 3-5 rounds with a total duration of 4-6 hours. The success rate from initial applications is 2-5% in large technology companies.

The hiring process in mobile development differs from web development: platform-specific questions are added — Activity/Fragment lifecycle, ARC and memory management in Swift, threading models (Main Thread, Dispatch Queue, Coroutines), working with network requests and data caching. An Android developer must know Jetpack Compose, Room, WorkManager, Dagger/Hilt. An iOS developer must know SwiftUI, Core Data, Combine, URLSession. The difference in requirements grows with experience: for Senior positions, system design and overall app architecture are added.

The interview structure depends on the grade. For Junior positions, basic knowledge of the language and platform is sufficient (1-2 rounds). A Middle developer goes through 2-3 rounds with an algorithms block. Senior interview includes 4-5 rounds: algorithms, mobile app architecture, system design, behavioral interview, and a final interview with VPE (Vice President of Engineering) or CTO.

Stages of a Technical Interview

HR Screening is the first stage lasting 20-30 minutes. The recruiter checks if the experience matches the job requirements, discusses working conditions, salary expectations, and the candidate’s motivation. At this stage, it’s important to clearly articulate your experience: projects, tech stack, achievements in metrics (reducing load time, decreasing crash rate, speeding up builds). HR screening does not test technical knowledge but filters out up to 40% of candidates who don’t meet formal requirements.

After screening comes the algorithmic interview — a key stage for most companies. Duration: 45-90 minutes. The candidate is given 1-2 algorithm and data structure problems. The solution is written on an online board (Codility, HackerRank, CoderPad) or on paper. What is evaluated is not only correctness, but also speed of thinking, the ability to ask clarifying questions and optimize the solution. According to interviewing.io (2025), 73% of candidates fail precisely at the algorithmic stage.

Architecture Interview

The Architecture Round tests the ability to design mobile applications. The candidate is asked to design an app (to-do list, messenger, news aggregator, streaming service). The evaluation covers the choice of architectural pattern (MVP, MVVM, MVI, VIPER), layer organization (Presentation, Domain, Data), DI implementation (Dagger, Hilt, Swinject), and navigation. For Android — knowledge of Jetpack Navigation, for iOS — Coordinator pattern and SwiftUI NavigationStack.

At the behavioral interview, soft skills are evaluated: ability to work in a team, resolve conflicts, and argue decisions. The STAR method (Situation, Task, Action, Result) is used — the candidate describes a specific situation from their experience. Example question: “Tell us about the most complex bug you found and fixed.” The final round with the team lead or VPE tests strategic thinking and cultural fit with the company.

Algorithms and Data Structures at an Interview

Algorithmic problems are a mandatory component of interviews at large technology companies (Google, Meta, Yandex, Tinkoff, Avito). The main goal is to assess the ability to solve problems, not language knowledge. The candidate is allowed to use any programming language — preference is given to Kotlin for Android and Swift for iOS. Typical topics: arrays, hash tables, graphs, dynamic programming, trees (Binary Tree, Trie, Segment Tree).

According to LeetCode (2025), solving 250-400 problems is required to confidently pass an algorithmic interview. Key topics by frequency: Two Pointers (12%), Sliding Window (10%), DFS/BFS on graphs (14%), Binary Search (8%), Dynamic Programming (18%), Hash Map / Set (15%). Big O notation is a mandatory element: the candidate must explain the time and space complexity of their solution and propose optimizations.

Example Problem: 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)

The Two Sum problem is the most popular interview problem (according to LeetCode, over 20 million submissions). The O(n) solution uses a HashMap: for each element, we check if the complement target - nums[i] has already been encountered. If yes — return the indices. If not — save the current element in the HashMap. The naive O(n²) solution with two nested loops is considered insufficient for Senior positions.

Mobile Development Questions

Platform questions at a mobile developer interview are divided into three blocks: fundamental platform knowledge, UI and multithreading, network requests and data storage. For Android, mandatory topics: Activity and Fragment lifecycle, Fragment v1 vs Fragment v2 differences, ActivityResult API (replacement for onActivityResult), ViewModel + StateFlow, Compose lifecycle. For iOS: UIViewController lifecycle, ARC (Automatic Reference Counting), DispatchQueue and OperationQueue, SwiftUI lifecycle (View — @State — @Binding — @ObservedObject).

Example Question: Lifecycle

Typical question: “Which Activity lifecycle callbacks are called during screen rotation?” Correct answer: onPause → onStop → onDestroy → onCreate → onStart → onResume. Follow-up question: “How to preserve state during rotation?” — via SavedStateHandle in ViewModel, onSaveInstanceState Bundle, or rememberSaveable in Jetpack Compose. For iOS: “What happens to UIViewController when the app goes to the background?” — viewWillDisappear → viewDidDisappear → didEnterBackground (AppDelegate).

System Design of a Mobile App

System Design Interview for a mobile developer tests the ability to design a client application’s architecture and its interaction with the server. Standard tasks: design a news feed (like Instagram/TikTok), chat (like Telegram), video player (like YouTube), first-level cache (L1 — in-memory, L2 — disk). Duration: 60 minutes. Structured thinking is evaluated, not the number of details.

System Design answer template: 1) Clarify requirements — specify functional (feed, likes, comments, photo upload) and non-functional requirements (offline, loading speed, battery consumption). 2) High-level design — draw a layer diagram: UI Layer → ViewModel → Repository → Network / Cache / DB. 3) Deep dive — detail key components, for example, the pagination mechanism (Paging 3 for Android, Offset-based vs Cursor-based for iOS). 4) Trade-offs — discuss compromises: cache vs data freshness, offline-first vs online-only.

Key System Design topics for mobile: caching (LRU Cache, Disk Cache with limit), image handling (Coil, Glide, SDWebImage — loading, cache, placeholder, progress), traffic optimization (protobuf instead of JSON, compression, Differ/GraphQL), offline work (Room + Sync Adapter, Core Data + iCloud, WorkManager for background synchronization). Offline-first is one of the most common topics for Senior positions.

For iOS, questions about App Thinning, Slicing, On-Demand Resources, and build optimization are added. For Android — about R8/ProGuard, App Bundles (AAB vs APK), Dynamic Delivery, and Minification. The architectural question “H How to implement an image cache with memory limits?” tests understanding of LRU Cache (LinkedHashMap with access order), Disk LRU Cache (Jake Wharton’s DiskLruCache), and Coil/Glide memory cache layer.

Interview Preparation Strategy

Interview preparation requires a systematic approach 4-8 weeks before the planned interview. Basic strategy: 2 weeks for theory review (language, platform, algorithms), 2-4 weeks for solving algorithmic problems (100-300 problems on LeetCode), 1-2 weeks for mock interviews (Pramp, interviewing.io, with friends). For Senior positions, System Design preparation is added (2-3 weeks). The plan provides a 70-80% success rate for the target level.

For mobile developers, specific preparation includes: reading Android Developers Guide / iOS Developer Library, analyzing source code of popular libraries (Retrofit, OkHttp, Coil, Koin, Alamofire, Kingfisher), building a pet project with Clean Architecture and CI/CD (GitHub Actions, Fastlane). Create a sample app on GitHub with modular architecture, DI, tests (Unit + UI + Snapshot) — this will demonstrate deep understanding and serve as an argument at the interview.

Typical Candidate Mistakes

Mistake 1: silent problem-solving. The candidate writes code silently without commenting on their thought process. The interviewer cannot evaluate the problem-solving approach. Correct approach: talk through each step — “I see that the problem boils down to searching a graph. I suggest using BFS because we need to find the shortest path.” Such communication allows the interviewer to guide the candidate if they make a mistake, which is evaluated positively.

Mistake 2: writing code immediately. Starting to code without clarifying requirements and discussing approaches is one of the main reasons for failure. Before writing code, you need to: clarify input/output data, discuss corner cases, compare 2-3 approaches with Big O estimation, and only after agreeing with the interviewer, write the optimal solution. Correct pattern: Clarify → High-level approach → Big O → Write code → Test with examples → Discuss trade-offs.

Mistake 3: lack of platform knowledge. The candidate solves algorithms excellently but cannot explain the difference between Activity and Fragment or between weak/unowned in Swift. For mobile positions, platform knowledge is evaluated on par with algorithms. Study: SDK version differences (compileSdk vs minSdk vs targetSdk), ProGuard/R8 rules for popular libraries, Swift Concurrency (async/await, actors) and MainActor. Every third candidate for an iOS position fails on ARC questions.