Bài Middle dành cho developer đã từng làm sản phẩm React Native thực tế và bắt đầu chịu trách nhiệm nhiều hơn về chất lượng, performance, architecture nhỏ, review PR và release.
Ở level Middle, câu trả lời tốt cần có trade-off. Bạn không chỉ nói dùng thư viện gì, mà phải giải thích vì sao chọn, khi nào không chọn và cách kiểm chứng trong app thật.
Đừng học thuộc máy móc. Với mỗi câu, hãy chuẩn bị một ví dụ thật từ project: bạn gặp vấn đề gì, chọn hướng nào, trade-off ra sao và kết quả đo được hoặc học được là gì.
Kiến trúc dự án và tổ chức code
1. Bạn tổ chức folder React Native app cỡ vừa như thế nào?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
2. Khi nào chọn feature-based structure thay vì type-based structure?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
3. Bạn thiết kế API client chung ra sao?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
4. Bạn đánh giá package trước khi thêm vào project thế nào?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
5. Khi nào nên tách design system nội bộ?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
6. Bạn quản lý config dev/staging/prod ra sao?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
7. Path alias có lợi và rủi ro gì?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
8. Bạn đặt boundary giữa feature và shared code như thế nào?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
9. Khi nào nên viết ADR cho app mobile?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
10. Bạn xử lý dependency vòng trong codebase ra sao?
Ở level Middle, câu trả lời nên thể hiện bạn biết giữ codebase dễ mở rộng chứ không chỉ làm màn hình chạy được. Hãy nói rõ tiêu chí tổ chức, ví dụ trong dự án thật, điểm đánh đổi và cách bạn giúp team đọc, review, test code dễ hơn.
State management và dữ liệu
11. Khi nào dùng Context, khi nào dùng Zustand hoặc Redux?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
12. Server state khác client state như thế nào?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
13. React Query giải quyết vấn đề gì trong app mobile?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
14. Optimistic update là gì và rollback ra sao?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
15. Bạn xử lý refresh token như thế nào?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
16. Cache invalidation nên thiết kế thế nào?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
17. Khi nào cần normalize dữ liệu?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
18. Offline mode cần lưu ý những gì?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
19. Làm sao tránh render lại thừa do global store?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
20. Deep link mở màn hình cần auth thì xử lý thế nào?
Bạn nên bắt đầu từ luồng dữ liệu: dữ liệu đến từ đâu, ai sở hữu, khi nào cần cache, khi nào cần invalidate và UI phản ứng ra sao khi loading, lỗi hoặc mất mạng. Điểm cộng là nêu được rủi ro stale data và cách đo/quan sát lỗi production.
Performance và rendering
21. Bạn bắt đầu profiling performance từ đâu?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
22. FlatList tối ưu bằng những cách nào?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
23. memo, useMemo, useCallback dùng khi nào?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
24. Bridge bottleneck là gì?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
25. Bạn xử lý animation bị giật như thế nào?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
26. Startup chậm thì kiểm tra gì?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
27. Ảnh làm app chậm vì sao?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
28. Memory leak thường đến từ đâu?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
29. Bạn tối ưu form lớn như thế nào?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
30. Bạn đo hiệu năng trước và sau tối ưu ra sao?
Câu trả lời tốt phải có tư duy đo lường. Hãy nêu triệu chứng, công cụ profiling, giả thuyết, cách cô lập nguyên nhân và metric trước/sau. Middle không nên tối ưu theo cảm giác hoặc rải memo khắp nơi mà không chứng minh lợi ích.
Native, build và release
31. Autolinking là gì và khi nào bị lỗi?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
32. CocoaPods đóng vai trò gì trong iOS React Native?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
33. Gradle lỗi thì bạn debug thế nào?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
34. Flavor hoặc scheme dùng khi nào?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
35. Permission camera hoặc location nên xử lý ra sao?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
36. OTA update có giới hạn gì?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
37. Release checklist mobile gồm những gì?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
38. App size tăng thì kiểm tra gì?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
39. Build staging và production nên khác nhau ở đâu?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
40. Khi native dependency conflict version thì xử lý thế nào?
Hãy chứng minh bạn không sợ phần native/build. Trả lời nên có các bước đọc log, khoanh vùng dependency, kiểm tra config theo môi trường, test trên thiết bị thật và chuẩn bị rollback khi release có rủi ro.
Testing, CI/CD và teamwork
41. Testing pyramid cho React Native nên như thế nào?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
42. React Native Testing Library nên test điều gì?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
43. Detox hoặc Maestro dùng khi nào?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
44. CI mobile nên có những bước nào?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
45. Bạn review PR React Native chú ý gì?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
46. Bạn estimate task mobile như thế nào?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
47. Khi design và API lệch nhau, bạn làm gì?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
48. Khi nào nên refactor?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
49. Bạn onboard junior vào project như thế nào?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
50. Một câu trả lời Middle tốt khác Junior ở đâu?
Ở nhóm câu này, nhà tuyển dụng muốn thấy bạn làm việc được trong team. Hãy nhấn mạnh giao tiếp sớm, review có lý do, test phần quan trọng, estimate kèm assumption và biết chọn phạm vi refactor vừa đủ để không làm trễ feature.
Cách luyện tập
- Chọn 15 câu khó nhất và tự trả lời thành tiếng trong 2 phút mỗi câu.
- Với câu tình huống, dùng format: bối cảnh, lựa chọn, trade-off, kết quả.
- Chuẩn bị một project nhỏ có navigation, gọi API, form, list, loading, error state, test và README rõ ràng.
