Q: Bạn cần implement tính năng thanh toán bằng vân tay/Face ID cho ứng dụng fintech (tương tự MoMo, ZaloPay). Hãy thiết kế flow bảo mật end-to-end và những điểm cần lưu ý đặc biệt cho thị trường Việt Nam.

Flow bảo mật chuẩn: (1) Enrollment - user đặt PIN/password trước, sau đó opt-in biometrics; lưu ý biometrics KHÔNG thay thế PIN, chỉ là convenience layer; (2) Key management - khi user enable biometrics, generate asymmetric key pair (RSA-2048 hoặc EC P-256) trong Secure Enclave (iOS) / Android Keystore - private key không bao giờ rời thiết bị; (3) Authentication flow - khi thanh toán: biometric prompt → OS verify locally → unlock private key → sign transaction payload → gửi signature lên server → server verify bằng public key đã lưu; (4) Thực tế với React Native: react-native-biometrics hoặc Expo LocalAuthentication; luôn fallback về PIN/password. Đặc thù thị trường VN: (a) Regulation - NHNN yêu cầu xác thực 2 yếu tố cho giao dịch > 5 triệu VND (Thông tư 35/2016), biometrics tính là 1 yếu tố; (b) Device fragmentation - nhiều thiết bị Android giá rẻ không có Secure Enclave đạt chuẩn, cần fallback graceful; (c) User trust - nhiều user VN vẫn e ngại cho phép app dùng vân tay, cần UX giải thích rõ dữ liệu không rời thiết bị; (d) SIM-based OTP vẫn được dùng song song (VNPT, Viettel) như 2FA alternative. Câu hỏi này kết hợp security knowledge với VN market awareness. Ứng viên phải biết private key không rời thiết bị - đây là điểm quan trọng nhất về mặt security. Điểm cộng nếu đề cập FIDO2/WebAuthn standard mà MoMo đang hướng tới. Hỏi thêm về cách xử lý khi user thêm vân tay mới vào thiết bị sau khi đã enroll (cần invalidate key cũ).

Question 1

React Native New Architecture (JSI, Fabric, TurboModules) giải quyết những hạn chế gì của Bridge cũ? Trong thực tế, bạn sẽ migrate một app production sang New Architecture như thế nào và rủi ro nào cần lưu ý?

Accepted Answer

Bridge cũ có 3 vấn đề cốt lõi: (1) Bất đồng bộ bắt buộc - mọi giao tiếp JS-Native đều phải serialize/deserialize JSON qua async bridge, tạo ra latency và không thể call synchronous native APIs; (2) Single-threaded JS - JS thread block UI thread khi xử lý events nặng; (3) Không có type-safety tại biên giới JS-Native. New Architecture giải quyết bằng: JSI (JavaScript Interface) - C++ layer cho phép JS giữ direct reference đến native objects, call sync khi cần; Fabric - UI renderer được viết lại hoàn toàn trong C++, hỗ trợ concurrent rendering và tích hợp với React 18 Concurrent Mode; TurboModules - lazy loading native modules (thay vì load tất cả lúc startup). Migration thực tế: (1) Enable New Architecture trong gradle.properties và Podfile, (2) Kiểm tra third-party dependencies đã support chưa (npmjs.com/package/react-native-compatibility-check), (3) Convert custom native modules sang TurboModules dần dần, (4) Test kỹ trên thiết bị low-end vì Fabric rendering khác Fabric cũ. Ứng viên senior phải phân biệt được JSI vs Bridge ở mức kỹ thuật (direct C++ reference vs JSON serialization), không chỉ nói chung chung 'nhanh hơn'. Điểm cộng nếu đề cập Hermes + JSI synergy và vấn đề backward compat với native modules chưa migrate. Hỏi thêm: 'Bạn làm gì nếu một thư viện third-party quan trọng chưa support New Architecture?'

Question 2

Flutter đang chuyển từ Skia sang Impeller làm rendering engine mặc định. Sự khác biệt kỹ thuật cốt lõi giữa hai engine là gì, và tại sao Impeller giải quyết được vấn đề shader compilation jank mà Skia không làm được?

Accepted Answer

Vấn đề gốc rễ của Skia: Skia compile GLSL shaders tại runtime (lần đầu một widget mới xuất hiện), gây ra jank frames đột ngột không thể predict được - đặc biệt rõ trên Android low-end và lần đầu launch animation. Flutter team không thể fix triệt để vì đây là fundamental limitation của cách Skia hoạt động. Impeller giải quyết bằng cách: (1) Pre-compile tất cả shaders vào Metal (iOS) hoặc Vulkan/OpenGL (Android) tại build time thay vì runtime - không còn runtime compilation jank; (2) Sử dụng Metal trực tiếp trên iOS (Skia dùng OpenGL rồi translate sang Metal, thêm overhead); (3) Rendering pipeline được thiết kế lại hoàn toàn với predictable frame budget. Tình trạng platform hiện tại (2025): iOS - Impeller là default từ Flutter 3.10, stable; Android - Impeller là default từ Flutter 3.24 trên Vulkan-capable devices, vẫn còn fallback Skia cho OpenGL-only devices; Web/Desktop - vẫn dùng CanvasKit (Skia-based) hoặc HTML renderer, chưa có Impeller. Câu hỏi này phân biệt Flutter developer làm việc bề mặt vs developer thực sự quan tâm đến rendering internals. Ứng viên giỏi sẽ biết Impeller chưa cover 100% platform. Hỏi thêm: 'Bạn đã gặp regression nào khi bật Impeller chưa? Và bạn debug như thế nào?' (một số custom shaders và path effects có thể render khác nhau).

Question 3

FlashList của Shopify được thiết kế để thay thế FlatList. Hãy giải thích cơ chế kỹ thuật giúp FlashList đạt performance tốt hơn, và khi nào bạn KHÔNG nên dùng FlashList?

Accepted Answer

Cơ chế FlashList: (1) Recycling pool thực sự - FlashList tái sử dụng component instances (thay đổi props) thay vì unmount/remount, tương tự RecyclerView của Android. FlatList mặc dù có virtualization nhưng vẫn mount/unmount components khi ra khỏi viewport window; (2) Không đo dynamic height mặc định - FlashList yêu cầu `estimatedItemSize` và tính toán height một lần, FlatList đo lại mỗi render nếu không có `getItemLayout`; (3) Blank area detection - FlashList có built-in BlankAreaTracker để report khi có blank areas (giúp tune performance); (4) Bộ nhớ thấp hơn vì fewer React component instances. Khi KHÔNG nên dùng FlashList: (1) Lists có item type đa dạng phức tạp (FlashList dùng `overrideItemType` nhưng nhiều types = ít recycling hiệu quả hơn); (2) Items có animations phức tạp per-item (recycling có thể gây visual glitch nếu animation state không reset đúng); (3) Sections với headers phức tạp (FlashList hỗ trợ nhưng không ngon bằng SectionList trong một số edge case); (4) Lists rất ngắn (< 50 items) - overhead không đáng. Nhà tuyển dụng muốn kiểm tra ứng viên đã thực sự dùng FlashList trong thực tế chứ không chỉ đọc tài liệu. Ứng viên mạnh sẽ giải thích được cơ chế tái sử dụng thành phần (recycling pool) khác với cơ chế ảo hóa của FlatList như thế nào, khi nào không nên dùng FlashList như danh sách có hoạt ảnh trạng thái, và tầm quan trọng của `estimatedItemSize` đối với độ chính xác của thanh cuộn. Điểm cộng nếu ứng viên đề cập đến `overrideItemType` để tối ưu bể tái sử dụng khi danh sách có nhiều loại thành phần khác nhau. Nhà tuyển dụng có thể hỏi thêm: "Bạn đo mức cải thiện như thế nào sau khi chuyển từ FlatList sang FlashList?"

Question 4

Bạn cần implement tính năng thanh toán bằng vân tay/Face ID cho ứng dụng fintech (tương tự MoMo, ZaloPay). Hãy thiết kế flow bảo mật end-to-end và những điểm cần lưu ý đặc biệt cho thị trường Việt Nam.

Accepted Answer

Flow bảo mật chuẩn: (1) Enrollment - user đặt PIN/password trước, sau đó opt-in biometrics; lưu ý biometrics KHÔNG thay thế PIN, chỉ là convenience layer; (2) Key management - khi user enable biometrics, generate asymmetric key pair (RSA-2048 hoặc EC P-256) trong Secure Enclave (iOS) / Android Keystore - private key không bao giờ rời thiết bị; (3) Authentication flow - khi thanh toán: biometric prompt → OS verify locally → unlock private key → sign transaction payload → gửi signature lên server → server verify bằng public key đã lưu; (4) Thực tế với React Native: react-native-biometrics hoặc Expo LocalAuthentication; luôn fallback về PIN/password. Đặc thù thị trường VN: (a) Regulation - NHNN yêu cầu xác thực 2 yếu tố cho giao dịch > 5 triệu VND (Thông tư 35/2016), biometrics tính là 1 yếu tố; (b) Device fragmentation - nhiều thiết bị Android giá rẻ không có Secure Enclave đạt chuẩn, cần fallback graceful; (c) User trust - nhiều user VN vẫn e ngại cho phép app dùng vân tay, cần UX giải thích rõ dữ liệu không rời thiết bị; (d) SIM-based OTP vẫn được dùng song song (VNPT, Viettel) như 2FA alternative. Câu hỏi này kết hợp security knowledge với VN market awareness. Ứng viên phải biết private key không rời thiết bị - đây là điểm quan trọng nhất về mặt security. Điểm cộng nếu đề cập FIDO2/WebAuthn standard mà MoMo đang hướng tới. Hỏi thêm về cách xử lý khi user thêm vân tay mới vào thiết bị sau khi đã enroll (cần invalidate key cũ).

Question 5

Bạn cần xây dựng một ứng dụng ghi chú cộng tác (collaborative note-taking) cho phép nhiều user chỉnh sửa đồng thời khi offline và sync lại sau. Bạn sẽ chọn chiến lược conflict resolution nào (CRDT, Operational Transformation, hay Last-Write-Wins) và tại sao?

Accepted Answer

Phân tích từng chiến lược: (1) Last-Write-Wins (LWW) - đơn giản nhất, dùng timestamp để resolve conflict. Phù hợp cho dữ liệu atomic (profile settings, toggle). KHÔNG phù hợp cho collaborative text vì một user có thể mất hoàn toàn công việc của mình; (2) Operational Transformation (OT) - Google Docs dùng OT, track operations (insert/delete tại position) và transform chúng để consistent. Rất phức tạp để implement đúng, cần server làm trung gian để order operations; (3) CRDT (Conflict-free Replicated Data Type) - data structure được thiết kế toán học để merge không cần central coordinator. Có nhiều loại: LWW-Register, G-Counter, Sequence CRDT (Logoot, LSEQ, Yjs). Cho collaborative text: Sequence CRDT (cụ thể là Yjs hoặc Automerge) là lựa chọn tốt nhất vì: merge tự động không cần server làm trung gian, P2P capable, đã được battle-tested trong production (Notion dùng, Linear dùng). Implementation thực tế: Yjs với y-websocket provider + y-indexeddb cho offline storage. Nhược điểm CRDT: document size tăng theo thời gian (tombstones), cần garbage collection strategy. Nhà tuyển dụng đánh giá tư duy thiết kế hệ thống ở cấp độ senior - ứng viên cần biết khi nào dùng công cụ nào và sự đánh đổi giữa các lựa chọn. Ứng viên mạnh sẽ giải thích được khi nào Last-Write-Wins phù hợp và khi nào gây mất dữ liệu, sự khác biệt căn bản giữa CRDT và Operational Transformation, và đề cập đến các thư viện thực tế như Yjs hoặc Automerge. Điểm cộng lớn nếu ứng viên nhắc đến bài toán xóa mềm (tombstone problem) trong CRDT và đề xuất được phương án đơn giản hơn cho nhóm nhỏ không cần độ phức tạp đầy đủ. Nhà tuyển dụng có thể hỏi thêm: "Nếu không dùng thư viện CRDT, bạn xây dựng trải nghiệm xử lý xung đột thân thiện nhất cho người dùng theo cách nào?"

Question 6

Zalo Mini App là một nền tảng đặc thù của thị trường Việt Nam. Hãy so sánh việc develop Zalo Mini App với phát triển app native/React Native thông thường về kiến trúc, giới hạn kỹ thuật, và khi nào nên chọn Mini App thay vì app riêng.

Accepted Answer

Kiến trúc Zalo Mini App: Chạy trong WebView của Zalo app (tương tự WeChat Mini Program). Sử dụng Zalo Mini App SDK - framework dựa trên JavaScript với component library riêng (tương tự nhưng không phải React). Build ra file .zapp (bundle). Giới hạn kỹ thuật: (1) Không thể dùng native modules tùy chỉnh - chỉ dùng được API mà Zalo SDK expose (ZMP API); (2) Bundle size limit (thường 4MB); (3) Performance giới hạn bởi WebView container; (4) Không access được camera/GPS trực tiếp, phải qua ZMP API; (5) Design phải follow Zalo design guidelines; (6) Không có App Store distribution - phân phối qua Zalo Store hoặc deep link trong chat. Ưu điểm so với app riêng: (1) Không cần user install - tap link trong Zalo là chạy ngay; (2) Tận dụng được 80M+ user base của Zalo và social graph; (3) ZaloPay integration built-in; (4) User đã tin tưởng Zalo → lower friction; (5) Phân phối qua chat/groups = viral loop tự nhiên. Nên chọn Mini App khi: B2C với target audience chắc chắn dùng Zalo, cần viral distribution, tích hợp ZaloPay, hoặc MVP nhanh. Nên chọn native app khi: cần full device capabilities, UX phức tạp, không phụ thuộc vào ecosystem của Zalo. Nhà tuyển dụng muốn tìm ứng viên có kinh nghiệm phát triển ứng dụng cho thị trường Việt Nam, không chỉ biết React Native hay Flutter tổng quát. Ứng viên mạnh sẽ phân biệt được Zalo Mini App với Zalo OA, hiểu giới hạn kỹ thuật như kích thước gói và hạn chế API so với ứng dụng native, đồng thời lý giải được khi nào nên chọn Mini App dựa trên lợi thế phân phối qua hệ sinh thái Zalo. Điểm cộng nếu ứng viên so sánh được với WeChat Mini Programs và biết công cụ Zalo Developer Tool để kiểm thử cục bộ. Nhà tuyển dụng có thể hỏi thêm: "Bạn xử lý giới hạn kích thước gói của Zalo Mini App như thế nào khi ứng dụng phức tạp?"

Question 7

Ứng dụng React Native production của bạn có startup time 4 giây và báo cáo jank khi scroll. Hãy mô tả quy trình profiling từng bước bạn sẽ thực hiện, bao gồm tools cụ thể và metrics bạn theo dõi.

Accepted Answer

Profiling startup time: (1) Đo baseline với Systrace (Android) / Instruments (iOS) - phân biệt Native startup time vs JS bundle load time vs First render time; (2) Kiểm tra Hermes bundle - với Hermes, dùng `perf_hooks` hoặc Metro bundler's `--profile` flag để đo JS parse time; nếu chưa bật Hermes (RN < 0.70), đây thường là nguyên nhân lớn nhất; (3) Lazy loading - dùng dynamic import() để defer loading các screen không cần thiết lúc startup; (4) Reduce JS bundle size - dùng `react-native-bundle-visualizer` để xem dependency nào chiếm nhiều size nhất; (5) Native splash screen - react-native-splash-screen hoặc expo-splash-screen để giấu startup time. Profiling scroll jank: (1) Bật Performance Monitor (shake device → Perf Monitor) - xem JS FPS và UI FPS riêng biệt. Nếu UI FPS thấp hơn JS FPS = native rendering issue. Nếu JS FPS thấp = JS thread bị block; (2) Flipper với React DevTools plugin - xem component re-renders; (3) Android GPU Profiler (adb shell dumpsys gfxinfo) cho frame timing chi tiết; (4) Memory profiling - Android Studio Memory Profiler hoặc Instruments Leaks để detect memory leaks gây jank theo thời gian. Metrics cần track: Time To Interactive (TTI), JS bundle size (KB), JS FPS / UI FPS (target 60fps), memory usage over session, và ANR rate (Android). Ứng viên giỏi sẽ nhấn mạnh việc đo lường TRƯỚC khi fix (không premature optimize) và phân biệt JS thread vs UI thread (vì cách fix khác nhau hoàn toàn). Điểm cộng nếu đề cập đến sự khác biệt giữa debug build và release build performance. Hỏi thêm: 'Sau khi profiling bạn phát hiện startup chậm do một third-party library khởi tạo nặng. Bạn làm gì nếu không thể bỏ thư viện đó?'

Question 8

Công ty bạn cần chọn state management cho ứng dụng Flutter enterprise với 50+ screens, 10 developers, và cần maintainable trong 3+ năm. Hãy so sánh Riverpod 2.x, BLoC, và GetX, rồi đưa ra quyết định có lập luận rõ ràng.

Accepted Answer

Phân tích theo tiêu chí enterprise: (1) BLoC (Business Logic Component): - Ưu: tách biệt rõ UI vs business logic, testability cao (stream-based = dễ unit test), Flutter team recommend, pattern nhất quán cho team lớn, nhiều tài liệu; - Nhược: boilerplate nhiều (Event/State/Bloc class cho mỗi feature), learning curve dốc cho người mới, verbose; - Phù hợp: team có Flutter experience, app phức tạp với nhiều business rules. (2) Riverpod 2.x: - Ưu: type-safe compile-time, không cần BuildContext để access providers, code generation (riverpod_generator) giảm boilerplate, dễ test (ProviderContainer), reactive và composable providers; - Nhược: Riverpod 2.x với code gen là mới (docs ít hơn BLoC), learning curve về Provider types (StateNotifier vs AsyncNotifier vs Notifier); - Phù hợp: team mới setup, app với nhiều async data fetching, modern Flutter dev. (3) GetX: - Ưu: ít code nhất, all-in-one (state + routing + DI), dễ học nhanh; - Nhược: magic quá nhiều (dùng static context), không type-safe, anti-patterns phổ biến (GetxController dùng như god object), coupling cao, khó test, community chia rẽ về quality; - KHÔNG phù hợp: enterprise với 10 devs và long-term maintenance. Quyết định đề xuất: Riverpod 2.x với code generation cho project mới, hoặc BLoC nếu team đã có BLoC experience. GetX nên tránh cho enterprise. Key deciding factor: nếu team chủ yếu từ backend/React Native background → Riverpod dễ adopt hơn. Nếu team đã quen BLoC → không có lý do migrate. Nhà tuyển dụng đánh giá cả kiến thức kỹ thuật lẫn khả năng phán đoán kỹ thuật trong bối cảnh doanh nghiệp lớn với nhiều người phát triển và vòng đời dài. Ứng viên mạnh sẽ không chỉ liệt kê tính năng mà đưa ra quyết định rõ ràng có lập luận phù hợp với yêu cầu cụ thể: 10 người phát triển, hơn 50 màn hình, 3 năm bảo trì, và lấy khả năng kiểm thử là tiêu chí quan trọng. Điểm cộng nếu ứng viên chỉ ra được cảnh báo khi dùng GetX cho dự án doanh nghiệp và phân biệt được Provider package với Riverpod dù cùng tác giả. Nhà tuyển dụng có thể hỏi thêm: "Nếu gia nhập dự án đang dùng GetX với hơn 30 nghìn dòng code, bạn có đề xuất chuyển đổi không và tại sao?"