Question 1

What limitations of the old Bridge does the React Native New Architecture (JSI, Fabric, TurboModules) address? In practice, how would you migrate a production app to the New Architecture, and what risks should be considered?

Accepted Answer

The old Bridge had 3 core problems: (1) Forced asynchrony - all JS-Native communication had to serialize/deserialize JSON over an async bridge, creating latency and preventing synchronous native API calls; (2) Single-threaded JS - the JS thread blocked the UI thread during heavy event processing; (3) No type-safety at the JS-Native boundary. New Architecture solves this with: JSI (JavaScript Interface) - a C++ layer that lets JS hold direct references to native objects and call synchronously when needed; Fabric - a fully rewritten UI renderer in C++ supporting concurrent rendering and integration with React 18 Concurrent Mode; TurboModules - lazy loading of native modules (instead of loading everything at startup). Practical migration: (1) Enable New Architecture in gradle.properties and Podfile, (2) Check third-party dependency compatibility (npmjs.com/package/react-native-compatibility-check), (3) Convert custom native modules to TurboModules incrementally, (4) Test thoroughly on low-end devices as Fabric rendering behaves differently. Senior candidates must distinguish JSI vs Bridge at a technical level (direct C++ reference vs JSON serialization), not just say 'faster'. Bonus points for mentioning Hermes + JSI synergy and backward compatibility issues with native modules not yet migrated. Follow up: 'What do you do if a critical third-party library doesn't support the New Architecture yet?'

Question 2

Flutter is transitioning from Skia to Impeller as its default rendering engine. What are the core technical differences between the two engines, and why does Impeller solve shader compilation jank that Skia could not?

Accepted Answer

Skia's root problem: Skia compiles GLSL shaders at runtime (the first time a new widget appears), causing sudden unpredictable jank frames - especially noticeable on low-end Android and during first-launch animations. The Flutter team couldn't fully fix this because it's a fundamental limitation of how Skia works. Impeller solves this by: (1) Pre-compiling all shaders to Metal (iOS) or Vulkan/OpenGL (Android) at build time instead of runtime - no more runtime compilation jank; (2) Using Metal directly on iOS (Skia used OpenGL then translated to Metal, adding overhead); (3) A completely redesigned rendering pipeline with a predictable frame budget. Current platform status (2025): iOS - Impeller is the default since Flutter 3.10, stable; Android - Impeller is the default since Flutter 3.24 on Vulkan-capable devices, still falls back to Skia for OpenGL-only devices; Web/Desktop - still uses CanvasKit (Skia-based) or HTML renderer, no Impeller yet. This question separates Flutter developers who work at the surface level from those who genuinely care about rendering internals. Strong candidates will know Impeller doesn't cover 100% of platforms. Follow up: 'Have you encountered any regressions when enabling Impeller? How did you debug them?' (some custom shaders and path effects may render differently).

Question 3

Shopify's FlashList is designed to replace FlatList. Explain the technical mechanisms that allow FlashList to achieve better performance, and when should you NOT use FlashList?

Accepted Answer

FlashList mechanisms: (1) True recycling pool - FlashList reuses component instances (changing props) instead of unmounting/remounting, similar to Android's RecyclerView. FlatList has virtualization but still mounts/unmounts components outside the viewport window; (2) No dynamic height measurement by default - FlashList requires `estimatedItemSize` and calculates height once, FlatList re-measures on every render without `getItemLayout`; (3) Blank area detection - FlashList has a built-in BlankAreaTracker to report blank areas (helps tune performance); (4) Lower memory due to fewer React component instances. When NOT to use FlashList: (1) Lists with complex diverse item types (`overrideItemType` exists but many types means less effective recycling); (2) Items with complex per-item animations (recycling can cause visual glitches if animation state is not properly reset); (3) Sections with complex headers (edge cases vs SectionList); (4) Very short lists under 50 items - overhead is not worth it. A good question to test whether the candidate has actually used FlashList or just read blog posts. Strong candidates will mention `overrideItemType` to optimize the recycling pool and the warning about animation state reset. Follow up: 'How do you measure the improvement when migrating from FlatList to FlashList?' - a good answer mentions blank area percentage and frame rate.

Question 4

You need to implement fingerprint/Face ID payment for a fintech app (similar to MoMo, ZaloPay). Design the end-to-end security flow and what specific considerations apply to the Vietnamese market.

Accepted Answer

Standard security flow: (1) Enrollment - user sets a PIN/password first, then opts into biometrics; note that biometrics do NOT replace the PIN, they are only a convenience layer; (2) Key management - when the user enables biometrics, generate an asymmetric key pair (RSA-2048 or EC P-256) in the Secure Enclave (iOS) / Android Keystore - the private key never leaves the device; (3) Authentication flow - during payment: biometric prompt → OS verifies locally → unlocks private key → signs transaction payload → sends signature to server → server verifies with stored public key; (4) In practice with React Native: react-native-biometrics or Expo LocalAuthentication; always fall back to PIN/password. Vietnamese market specifics: (a) Regulation - SBV requires 2-factor authentication for transactions over 5 million VND (Circular 35/2016), biometrics counts as 1 factor; (b) Device fragmentation - many low-cost Android devices lack a compliant Secure Enclave, need graceful fallback; (c) User trust - many Vietnamese users are still hesitant to allow apps to use fingerprints, need UX that clearly explains data never leaves the device; (d) SIM-based OTP is still widely used alongside (VNPT, Viettel) as a 2FA alternative. This question combines security knowledge with Vietnamese market awareness. Candidates must know that the private key never leaves the device - this is the most important security point. Bonus for mentioning the FIDO2/WebAuthn standard that MoMo is moving toward. Follow up on how to handle the case where a user adds a new fingerprint to the device after enrollment (the old key needs to be invalidated).

Question 5

You need to build a collaborative note-taking app that allows multiple users to edit simultaneously while offline and sync later. Which conflict resolution strategy would you choose (CRDT, Operational Transformation, or Last-Write-Wins) and why?

Accepted Answer

Analysis of each strategy: (1) Last-Write-Wins (LWW) - simplest, uses timestamps to resolve conflicts. Suitable for atomic data (profile settings, toggles). NOT suitable for collaborative text since one user may completely lose their work; (2) Operational Transformation (OT) - Google Docs uses OT, tracks operations (insert/delete at position) and transforms them for consistency. Very complex to implement correctly, needs a server intermediary to order operations; (3) CRDT (Conflict-free Replicated Data Type) - mathematically designed data structures that merge without a central coordinator. Many types: LWW-Register, G-Counter, Sequence CRDT (Logoot, LSEQ, Yjs). For collaborative text: Sequence CRDT (specifically Yjs or Automerge) is the best choice because: automatic merge without server mediation, P2P capable, battle-tested in production (used by Notion, used by Linear). Practical implementation: Yjs with y-websocket provider + y-indexeddb for offline storage. CRDT downsides: document size grows over time (tombstones), needs a garbage collection strategy. This is a senior-level system design question. Candidates don't need to know the math behind CRDTs but must know when to use what and the trade-offs. Major bonus points for mentioning the tombstone problem in CRDTs. Follow up: 'If you don't want to use a CRDT library and only need basic collaboration for a small team, what strategy would you fall back to with the best user experience?'

Question 6

Zalo Mini App is a platform unique to the Vietnamese market. Compare developing a Zalo Mini App with standard native/React Native development in terms of architecture, technical limitations, and when to choose a Mini App over a standalone app.

Accepted Answer

Zalo Mini App architecture: Runs inside Zalo app's WebView (similar to WeChat Mini Programs). Uses the Zalo Mini App SDK - a JavaScript-based framework with its own component library (similar to but not React). Builds to a .zapp file (bundle). Technical limitations: (1) Cannot use custom native modules - only APIs exposed by the Zalo SDK (ZMP API); (2) Bundle size limit (typically 4MB); (3) Performance constrained by the WebView container; (4) Cannot access camera/GPS directly - must go through ZMP API; (5) Design must follow Zalo design guidelines; (6) No App Store distribution - distributed via Zalo Store or deep links in chat. Advantages over standalone apps: (1) No installation required - tapping a link in Zalo launches it immediately; (2) Leverages Zalo's 80M+ user base and social graph; (3) Built-in ZaloPay integration; (4) Users already trust Zalo - lower friction; (5) Distribution via chat/groups creates a natural viral loop. Choose Mini App when: B2C with a target audience that definitely uses Zalo, needs viral distribution, ZaloPay integration, or a fast MVP. Choose native app when: full device capabilities are needed, complex UX is required, or you don't want to depend on Zalo's ecosystem. This question differentiates candidates with real practical experience in Vietnam. Many developers know React Native but have never built a Zalo Mini App. Bonus points for comparing it with WeChat Mini Programs (same concept, Zalo followed suit). Follow up: 'How do you test a Zalo Mini App during development? Is there an emulator?' (Zalo provides Zalo Developer Tool for local testing).

Question 7

Your production React Native app has a 4-second startup time and reports jank when scrolling. Describe the step-by-step profiling process you would carry out, including specific tools and metrics you would track.

Accepted Answer

Profiling startup time: (1) Measure baseline with Systrace (Android) / Instruments (iOS) - distinguish Native startup time vs JS bundle load time vs First render time; (2) Check Hermes bundle - with Hermes, use `perf_hooks` or Metro bundler's `--profile` flag to measure JS parse time; if Hermes is not enabled (RN < 0.70), this is often the biggest cause; (3) Lazy loading - use dynamic import() to defer loading screens not needed at startup; (4) Reduce JS bundle size - use `react-native-bundle-visualizer` to see which dependencies take the most space; (5) Native splash screen - react-native-splash-screen or expo-splash-screen to hide startup time. Profiling scroll jank: (1) Enable Performance Monitor (shake device → Perf Monitor) - view JS FPS and UI FPS separately. If UI FPS is lower than JS FPS = native rendering issue. If JS FPS is low = JS thread is blocked; (2) Flipper with React DevTools plugin - view component re-renders; (3) Android GPU Profiler (adb shell dumpsys gfxinfo) for detailed frame timing; (4) Memory profiling - Android Studio Memory Profiler or Instruments Leaks to detect memory leaks causing jank over time. Key metrics: Time To Interactive (TTI), JS bundle size (KB), JS FPS / UI FPS (target 60fps), memory usage over session, and ANR rate (Android). Strong candidates will emphasize measuring BEFORE fixing (no premature optimization) and distinguishing between the JS thread and UI thread (because the fixes are completely different). Bonus points for mentioning the difference in performance between debug builds and release builds. Follow up: 'After profiling you find startup is slow because of a heavy third-party library initialization. What do you do if you can't remove the library?'

Question 8

Your company needs to choose a state management solution for an enterprise Flutter app with 50+ screens, 10 developers, and a requirement for maintainability over 3+ years. Compare Riverpod 2.x, BLoC, and GetX, then make a decision with clear reasoning.

Accepted Answer

Analysis by enterprise criteria: (1) BLoC (Business Logic Component): - Pros: clear separation of UI vs business logic, high testability (stream-based = easy unit testing), Flutter team recommended, consistent pattern for large teams, abundant documentation; - Cons: high boilerplate (Event/State/Bloc class per feature), steep learning curve for newcomers, verbose; - Best for: teams with Flutter experience, complex apps with many business rules. (2) Riverpod 2.x: - Pros: compile-time type-safe, no BuildContext needed to access providers, code generation (riverpod_generator) reduces boilerplate, easy to test (ProviderContainer), reactive and composable providers; - Cons: Riverpod 2.x with code gen is relatively new (fewer docs than BLoC), learning curve around provider types (StateNotifier vs AsyncNotifier vs Notifier); - Best for: new project setup, apps with lots of async data fetching, modern Flutter dev. (3) GetX: - Pros: least code, all-in-one (state + routing + DI), fast to learn; - Cons: too much magic (uses static context), not type-safe, common anti-patterns (GetxController used as god object), high coupling, hard to test, community divided on quality; - NOT suitable for: enterprise with 10 devs and long-term maintenance. Recommended decision: Riverpod 2.x with code generation for new projects, or BLoC if the team already has BLoC experience. GetX should be avoided for enterprise. Key deciding factor: if the team mostly comes from backend/React Native backgrounds - Riverpod is easier to adopt. If the team is already familiar with BLoC - there's no reason to migrate. This question tests both technical knowledge and engineering judgment. Candidates should not just list features but must make a decision with clear reasoning appropriate to the context (enterprise, 10 devs, 3 years). Be wary of candidates who recommend GetX for enterprise without strong caveats. Follow up: 'If you join a project already using GetX with 30K lines of code, would you migrate or maintain as-is?'