Question 1

Bạn sẽ chọn React Native, Flutter hay native (Swift/Kotlin) cho một ứng dụng mới cần hỗ trợ cả iOS và Android với team 3 người? Hãy giải thích quyết định của bạn dựa trên trade-offs cụ thể.

Accepted Answer

Không có câu trả lời đúng duy nhất - quan trọng là reasoning: (1) React Native - team có JS/React background, ecosystem mạnh, nhưng bridge overhead và JS thread; (2) Flutter - Dart learning curve nhưng performance gần native, single codebase thực sự (kể cả UI rendering), tốt cho UI-heavy apps; (3) Native - performance tốt nhất, full API access, nhưng 2 codebases = gấp đôi effort với team nhỏ. Với team 3 người và budget hạn chế: Flutter hoặc React Native thực tế hơn. Ứng viên mạnh sẽ hỏi lại về loại app (game, e-commerce, fintech), tính năng cần thiết (camera, biometrics, BLE), và background của team trước khi đưa ra quyết định. Tránh ứng viên chỉ nói 'tôi quen React Native nên chọn React Native'.

Question 2

Ứng dụng của bạn bị user phàn nàn lag khi scroll danh sách dài (FlatList với 1000+ items). Bạn sẽ debug và tối ưu như thế nào?

Accepted Answer

Debug trước khi optimize: (1) Dùng React DevTools Profiler + Flipper để identify re-renders không cần thiết, (2) Kiểm tra FlatList config: `getItemLayout` để tránh dynamic measurement, `keyExtractor` đúng, `windowSize` và `maxToRenderPerBatch`, (3) Tối ưu render: `React.memo` cho list item component, tránh inline functions trong render, tránh anonymous objects trong props, (4) Nếu vẫn chậm: xem xét FlashList (Shopify) thay FlatList, hoặc virtualization tùy chỉnh. Ứng viên tốt sẽ nhắc đến `getItemLayout` như bước đầu tiên vì đây thường là nguyên nhân lớn nhất của scroll jank trong FlatList. Hỏi thêm về cách họ measure 'lag' - bằng frame rate (Perf Monitor trong dev mode) hay chỉ cảm giác?

Question 3

Bạn được yêu cầu xây dựng ứng dụng đặt hàng thực phẩm cần hoạt động offline khi mất kết nối mạng. Hãy thiết kế kiến trúc offline-first cho ứng dụng này.

Accepted Answer

Kiến trúc offline-first: (1) Local database - SQLite (via WatermelonDB hoặc expo-sqlite) hoặc AsyncStorage cho data nhỏ; (2) Sync engine - conflict resolution strategy (last-write-wins vs. CRDT), queue operations khi offline; (3) Network layer - Retry logic với exponential backoff, optimistic UI updates; (4) UX considerations - hiển thị trạng thái sync, xử lý conflict khi user thêm item offline rồi sản phẩm đó bị xóa trên server. Điểm phân biệt ứng viên giỏi là cách xử lý conflict. Hỏi: 'Nếu user thêm sản phẩm vào giỏ hàng khi offline, nhưng khi online lại thì sản phẩm đó đã hết hàng, bạn xử lý thế nào?' Câu trả lời mạnh sẽ thảo luận về optimistic UI và rollback.

Question 4

Bạn đã implement push notifications trên mobile chưa? Hãy mô tả kiến trúc từ server đến device và những edge case bạn cần xử lý.

Accepted Answer

Kiến trúc: Server → FCM (Firebase Cloud Messaging)/APNs → Device. Chi tiết: (1) Token management - device token thay đổi khi reinstall, cần sync với server; (2) Permission flow - iOS yêu cầu explicit permission, Android 13+ cũng vậy; (3) Background vs. foreground handling khác nhau; (4) Notification payload types: notification-only, data-only (background processing), notification+data; (5) Edge cases: app bị force-killed, thiết bị offline (FCM lưu lại bao lâu?), notification grouping, deep linking khi tap notification. Deep linking khi tap notification là điểm nhiều developer bỏ qua. Hỏi cụ thể: 'Khi user tap notification và app đang closed, bạn xử lý navigation như thế nào?' - cần xử lý initialNotification trong React Native Firebase.

Question 5

Bạn đã triển khai CI/CD cho mobile app chưa? Hãy mô tả pipeline của bạn từ code commit đến khi app lên TestFlight/Firebase App Distribution.

Accepted Answer

Pipeline điển hình: (1) Trigger: PR merge vào develop/main, (2) Lint + Unit tests (Jest), (3) Build: Fastlane để tự động hóa signing (match cho iOS certificates), (4) iOS: xcodebuild → .ipa → TestFlight via Fastlane pilot; Android: gradle → .aab → Firebase App Distribution hoặc Play Console internal track; (5) Notify: Slack message với build status và download link, (6) Platform: GitHub Actions, Bitrise, hoặc EAS Build (Expo). iOS certificate management là điểm đau lớn nhất trong mobile CI/CD. Ứng viên mạnh sẽ đề cập đến Fastlane Match (cert management) hoặc Xcode Cloud. Hỏi về cách xử lý khi certificate expire trong production.

Question 6

Bạn đã gặp vấn đề gì khi hiển thị và nhập liệu tiếng Việt trên mobile app? Các font chữ, bàn phím ảo, và xử lý dấu có những thách thức kỹ thuật gì đặc thù?

Accepted Answer

Các thách thức cụ thể: (1) Font - cần font hỗ trợ đầy đủ Unicode Vietnamese (Noto Sans, Inter). Một số font bị thiếu glyphs, đặc biệt các tổ hợp dấu như ộ, ướ; (2) Keyboard height - bàn phím tiếng Việt (Telex, VNI) tốn nhiều space hơn, cần KeyboardAvoidingView xử lý đúng; (3) String length - 'Việt Nam' nhiều byte hơn ký tự thực, ảnh hưởng đến character limit và text truncation; (4) Search/sorting - normalize về dạng không dấu để search, dùng `localeCompare` với `vi` locale để sort. Nhà tuyển dụng đánh giá kinh nghiệm thực tế xử lý tiếng Việt trên ứng dụng di động - đây là câu hỏi phân biệt ứng viên đã thực sự làm sản phẩm cho thị trường Việt Nam. Ứng viên mạnh sẽ nêu được các thách thức kỹ thuật cụ thể như sự khác biệt giữa phương thức nhập Telex và VNI, cách đếm ký tự chính xác với Unicode tổ hợp, và kinh nghiệm kiểm thử với thiết bị thật thay vì giả lập. Điểm cộng nếu ứng viên đề cập đến các trường hợp đặc biệt như tên người Việt dài trong ô nhập liệu ngắn. Nhà tuyển dụng có thể hỏi thêm: "Bạn kiểm thử bàn phím ảo tiếng Việt trên thiết bị thật theo quy trình nào?"

Question 7

Bạn đã xử lý state management trong mobile app như thế nào? Hãy so sánh Redux, Zustand, Jotai và Context API - khi nào bạn chọn cái nào?

Accepted Answer

Framework quyết định theo scale và team size: (1) Context API - phù hợp cho global state đơn giản (theme, language, auth user), không phù hợp cho state update frequent (re-render toàn bộ consumers); (2) Zustand - sweet spot cho hầu hết apps: minimal boilerplate, performant, selector pattern, dễ devtools; (3) Redux Toolkit - justified cho large teams cần strict patterns, thời gian travel debugging; (4) Jotai/Recoil - atom-based, tốt cho fine-grained reactivity. Với React Native: tránh over-engineering, Zustand thường là lựa chọn tối ưu. Nhà tuyển dụng đánh giá khả năng chọn công cụ quản lý trạng thái phù hợp với độ phức tạp của bài toán, không phải biết nhiều nhất. Ứng viên mạnh sẽ giải thích được tại sao Context API gây vấn đề hiệu năng khi giá trị thay đổi khiến toàn bộ cây thành phần phụ thuộc phải vẽ lại, cách giải quyết qua phân tách ngữ cảnh hoặc ghi nhớ, và khi nào nên chọn Zustand hoặc Jotai thay vì Redux. Điểm cộng nếu ứng viên phân biệt rõ trạng thái toàn cục và trạng thái máy chủ - React Query không phải công cụ quản lý trạng thái mà là công cụ lấy dữ liệu. Nhà tuyển dụng có thể hỏi thêm: "Bạn xử lý thế nào khi ứng dụng hiện tại đang dùng Redux nhưng cần tối ưu hiệu năng?"