Junior Mobile Engineer Interview Questions

What's expected at the Junior level

Expect platform fundamentals, basic UI and guided feature work.

Sample Mobile Engineer interview questions

• TechnicalWalk through the activity/view-controller lifecycle and common pitfalls.
  What a strong answer covers

  • Lifecycle method order (onCreate, onStart, onResume...)
  • Handling configuration changes and state saving
  • Memory leaks from inner classes and anonymous handlers
  • Async task cancellation and lifecycle awareness

  View a sample answer

  Both Android Activity and iOS UIViewController have a defined lifecycle: onCreate/viewDidLoad, onStart/viewWillAppear, onResume/viewDidAppear, onPause/viewWillDisappear, onStop/viewDidDisappear, onDestroy. Common pitfalls include not saving UI state in onSaveInstanceState (Android) or not restoring it on configuration changes, leading to data loss. Memory leaks occur when inner classes or anonymous handlers hold a strong reference to the activity/controller, preventing garbage collection; use weak references or lifecycle-aware components. Async tasks (AsyncTask, coroutines, closures) should be cancelled in onStop/onDisappear to avoid updating detached views. Always test rotation and backgrounding scenarios.

• TechnicalHow do you keep a long scrolling list smooth on a low-end device?
  What a strong answer covers

  • View recycling (RecyclerView/UICollectionView)
  • Efficient image loading and caching
  • Simplified layouts and reduced overdraw
  • Hardware acceleration and profiling tools

  View a sample answer

  To keep a long list smooth on low-end devices, use RecyclerView (Android) or UICollectionView (iOS) with view holder pattern to recycle item views, minimizing inflation and layout passes. Use image loading libraries like Glide or SDWebImage that handle caching, downsampling, and background decoding. Keep item layouts shallow with ConstraintLayout (Android) or Auto Layout with correct priorities; avoid nested weights. Reduce overdraw by removing unnecessary backgrounds and using `clipChildren=false` sparingly. Enable hardware acceleration and profile with Systrace (Android) or Instruments (iOS) to identify jank frames. Use `setHasFixedSize(true)` if the list size doesn't change dynamically.

• TechnicalHow would you design offline support with later synchronization?
  What a strong answer covers

  • Local database as single source of truth
  • Sync queue with operation type and timestamp
  • Conflict resolution strategies (LWW, merge)
  • Network observer triggering background sync

  View a sample answer

  Design offline support by storing all data in a local database (Room, Core Data) which acts as the single source of truth. All write operations go to the local DB first and are recorded in a sync queue table with fields like operation type (INSERT, UPDATE, DELETE), table, record ID, payload, and timestamp. A sync service monitors network connectivity (using ConnectivityManager or NWPathMonitor) and when online, processes the queue in order, sending changes via API. Conflicts are resolved using last-write-wins (comparing timestamps) or by showing a merge UI for user resolution. The system reads only from the local DB, providing a seamless offline experience. Use WorkManager or BGTaskScheduler for reliable background sync.

• CodingImplement an image cache with memory and disk tiers.
  What a strong answer covers

  • LRU eviction in memory cache
  • Disk cache with LRU (DiskLruCache)
  • Thread safety with locks/ConcurrentHashMap
  • Async image loading with callbacks/coroutines

  View a sample answer

  Implement a two-tier image cache: memory and disk. The memory cache uses an LRU algorithm (e.g., LinkedHashMap with size limit or LruCache). The disk cache can be DiskLruCache or a file-based LRU. On request, check memory first (O(1)), then disk (O(1) with hashing), then fetch from network, storing in both. Ensure thread safety with locks or ConcurrentHashMap. Async loading uses coroutines or callbacks, returning cached image immediately if present. Common pitfalls: not invalidating cache on memory pressure, and blocking UI thread during disk reads. Use soft references for memory but prefer strong references with a fixed max size to prevent GC thrashing.

  class ImageCache(private val maxMemorySize: Int = Runtime.getRuntime().maxMemory() / 8,
                  private val diskCacheDir: File = File(context.cacheDir, "images"),
                  private val diskCacheSize: Long = 50L * 1024 * 1024) {
      
      private val memoryCache = object : LruCache<String, Bitmap>(maxMemorySize.toInt()) {
          override fun sizeOf(key: String?, value: Bitmap?): Int = value?.byteCount ?: 0
      }
      
      private val diskCache: DiskLruCache? = try {
          DiskLruCache.open(diskCacheDir, 1, 1, diskCacheSize)
      } catch (e: IOException) { null }
      
      fun get(url: String): Bitmap? {
          val key = md5(url)
          memoryCache.get(key)?.let { return it }
          val bitmap = diskCache?.let { disk ->
              disk[key]?.getInputStream(0)?.use { BitmapFactory.decodeStream(it) }
          }
          bitmap?.let { memoryCache.put(key, it) }
          return bitmap
      }
      
      fun put(url: String, bitmap: Bitmap) {
          val key = md5(url)
          memoryCache.put(key, bitmap)
          diskCache?.let { disk ->
              disk.edit(key)?.apply {
                  getOutputStream(0).use { bitmap.compress(Bitmap.CompressFormat.PNG, 100, it) }
                  commit()
              }
          }
      }
      
      private fun md5(input: String): String {
          val digest = MessageDigest.getInstance("MD5")
          return digest.digest(input.toByteArray()).joinToString("") { "%02x".format(it) }
      }
  }

• CodingBuild a paginated list that loads more as the user scrolls.
  What a strong answer covers

  • RecyclerView OnScrollListener for pagination
  • Page number or cursor-based pagination
  • Loading indicator at the bottom
  • Duplicate request prevention and error handling

  View a sample answer

  Build a paginated list using RecyclerView with an OnScrollListener that triggers loading more data when the last visible item is near the end. Use a dedicated data source (e.g., repository) that fetches pages from API using page numbers or cursors. Show a loading spinner at the bottom via an adapter item type. Implement a ViewModel to hold the list and loading state, preventing duplicate requests with a flag. Handle errors by showing retry UI. For large lists, use Paging 3 library which handles prefetching, lifecycle, and database integration. On iOS, use UICollectionView with prefetching delegate and combine publishers.

  class PaginatedAdapter : RecyclerView.Adapter<RecyclerView.ViewHolder>() {
      private val items = mutableListOf<String>()
      private var isLoading = false
      private var isLastPage = false
      private val PAGE_SIZE = 20
      
      override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
          if (holder is ItemViewHolder) {
              holder.bind(items[position])
          } else if (holder is LoadingViewHolder) {
              // show loading indicator
          }
      }
      
      fun addPage(newItems: List<String>) {
          val startPos = items.size
          items.addAll(newItems)
          notifyItemRangeInserted(startPos, newItems.size)
          if (newItems.size < PAGE_SIZE) isLastPage = true
          isLoading = false
      }
      
      // In your fragment/activity:
      recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() {
          override fun onScrolled(recyclerView: RecyclerView, dx: Int, dy: Int) {
              super.onScrolled(recyclerView, dx, dy)
              val layoutManager = recyclerView.layoutManager as LinearLayoutManager
              val visibleItemCount = layoutManager.childCount
              val totalItemCount = layoutManager.itemCount
              val firstVisibleItemPosition = layoutManager.findFirstVisibleItemPosition()
              if (!adapter.isLoading && !adapter.isLastPage) {
                  if ((visibleItemCount + firstVisibleItemPosition) >= totalItemCount 
                      && firstVisibleItemPosition >= 0) {
                      adapter.isLoading = true
                      viewModel.loadNextPage()
                  }
              }
          }
      })
  }

• System DesignDesign a mobile chat app that works offline and syncs on reconnect.
  What a strong answer covers

  • Local database for message storage
  • Pending message queue with sync on reconnect
  • WebSocket for real-time updates
  • Conflict resolution using timestamps

  View a sample answer

  Design a mobile chat app with offline support by storing messages locally in SQLite (Room) as the source of truth. When the user sends a message, it is saved locally with status 'pending' and added to a sync queue table. On network availability, a sync service sends pending messages via a REST API or WebSocket. Use WebSocket for real-time incoming messages; if offline, messages are queued on the server and delivered on reconnect. Conflict resolution uses client and server timestamps: messages are ordered by server timestamp, and duplicate detection uses unique client IDs. Delivery status is tracked locally (sent, delivered, read) and updated from server acknowledgments. Use reactive streams (RxJava/Combine) to update UI automatically.

• BehavioralTell me about a tough crash or memory bug you tracked down.
  What a strong answer covers

  • Memory leak from static inner class holding Activity reference
  • Heap dump analysis with MAT/LeakCanary
  • Root cause: anonymous Runnable in AsyncTask
  • Fix: use weak reference or application context

  View a sample answer

  Situation: The app crashed with OutOfMemoryError on a low-end device after prolonged use. Task: Identify and fix the memory leak. Action: I used LeakCanary, which immediately detected a leak in an Activity. I took a heap dump and analyzed it with MAT (Memory Analyzer Tool). The leak was caused by an anonymous Runnable posted to a Handler inside an AsyncTask. The Runnable held an implicit reference to the enclosing AsyncTask, which held a reference to the Activity. The Activity couldn't be garbage collected after rotation. Fix: I replaced the anonymous class with a static inner class holding a WeakReference to the Activity, and cancelled the task in onStop. Result: Memory usage stabilized, no more OOM crashes. This taught me to always use lifecycle-aware components like ViewModel and to avoid inner classes that outlive the activity.

• BehavioralHow do you balance new features against app size and performance?
  What a strong answer covers

  • Feature flags for gradual rollout
  • Size budget (APK Analyzer, ProGuard)
  • Performance metrics (cold start, frame rate)
  • User impact analysis and A/B testing

  View a sample answer

  Balancing new features with app size and performance requires a structured approach. I set a size budget (e.g., <100MB) and use APK Analyzer to identify large assets or libraries. Use ProGuard/R8 to shrink code and remove unused resources. For performance, define a budget for cold start time (<2s) and jank (<5% frames >16ms). New features are evaluated against these budgets using feature flags, allowing gradual rollout and easy rollback. I measure the impact of each feature on size and performance via A/B testing. For example, adding a heavy animation library might degrade frame rate; I would optimize it or find a lighter alternative. Prioritize features that deliver high user value with low impact. Use on-demand delivery for optional features. Regularly review user feedback and crash reports to decide which features to keep.

What interviewers assess

How to prepare

• Lead with lifecycle and memory — they're the most common failure points.
• Discuss offline and flaky networks proactively; mobile reviewers expect it.
• Show you measure: profiling, crash rates and frame timing beat hand-waving.

Frequently asked questions