Skip to main content

React Native engineer frontend interview questions

3 questions on frontend for react native engineer candidates. Expect prompts such as “Debug a slow React Native screen crossing the native bridge” and “Use Flow for UI state without overloading the app”, each with a worked answer outline and the follow-ups interviewers push on.

Questions

Showing 1 to 3 of 3 frontend questions.

As asked

A React Native feed screen drops frames when scrolling because it sends frequent events between JavaScript and native code. How do you diagnose and fix it?

Sample answer outline

Start with measurement in Flipper, React DevTools, native profilers, and frame timing rather than assuming React is the bottleneck. Look for expensive renders, oversized serialized payloads crossing the bridge, synchronous native calls, image decode work, and layout thrash. Fixes include moving high-frequency work to native or JSI, reducing event payloads, memoising row components, using FlatList correctly, and pre-sizing media. A senior answer explains the old bridge versus the new architecture without pretending migration alone fixes bad rendering. Candidates often miss that JavaScript can be idle while the UI thread is blocked.

Expect these follow-ups

  • What changes under Fabric and TurboModules?
  • How do you separate JavaScript thread stalls from UI thread stalls?
  • When would you write a native module instead of staying in JavaScript?
performancenative-bridgemobile

As asked

You have a Kotlin app where search input emits quickly while network responses arrive slowly. How would you design the Flow pipeline?

Sample answer outline

A solid answer uses debounce to avoid firing on every keystroke, distinctUntilChanged to skip repeated queries and flatMapLatest to cancel stale searches. Network work should run on the right dispatcher and expose a sealed UI state for loading, success and error. The pipeline should be collected from a lifecycle-aware scope so it stops when the screen is gone. Candidates often use collect on every query, which lets slow responses race and overwrite newer results. Strong answers mention testing with virtual time because timing-heavy Flow code is otherwise fragile.

Reference implementation (kotlin)

Kotlin
val uiState: StateFlow<SearchState> =
    queryFlow
        .debounce(300)
        .map { it.trim() }
        .distinctUntilChanged()
        .flatMapLatest { query ->
            flow {
                emit(SearchState.Loading(query))
                emit(SearchState.Results(repository.search(query)))
            }.catch { emit(SearchState.Error(query, it)) }
        }
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), SearchState.Idle)

Expect these follow-ups

  • What is the difference between flatMapLatest and flatMapMerge here?
  • How do you keep cached results visible while a refresh is loading?
  • How would you test the debounce behaviour?
flowstate-managementandroid

As asked

You are starting a major iOS feature that has complex navigation, custom animations and a long support window. How do you choose between SwiftUI, UIKit or a hybrid?

Sample answer outline

A strong answer starts with product and platform constraints rather than preference. SwiftUI is productive for state-driven screens and modern OS targets, but UIKit still gives mature control over complex navigation, collection views and custom transitions. A hybrid can work well if ownership boundaries are clear, for example SwiftUI feature screens hosted inside a UIKit shell. The candidate should mention minimum iOS version, team skill, testability, accessibility and long-term maintainability. Weak answers treat SwiftUI as automatically newer and better without naming the actual risks.

Expect these follow-ups

  • Where do SwiftUI and UIKit lifecycle models clash?
  • How do you test a hybrid screen?
  • What would make you reverse the decision after a prototype?
swiftuiuikitarchitecture